Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Introduction

Beyond initial certificate enrollment it is necessary to implement proper certificate update in CMPv2 use case. Nowadays it is possible to get new certificate either by restarting K8s workload (to re-run CertService client init container) or if CMPv2 and CertManager integration is enabled, by waiting for CertManager to re-issue certificate which is about to expire. In both cases new CMPv2 Initialization Request (IR) is sent underneath. From K8s workload perspective everything is fine as it gets valid X.509 certificate. But current solution has a lot of drawbacks looking from CMPv2 server and operator perspectives:

  • Policy on CMPv2 server may disallow multiple Initialization Requests (IR) for the same end entity (EE) identified by the same Subject DN
  • CMPv2 server may be overloaded by multiple active certificates for the same EE, while in case of proper certificate update it stores just two certificates (e.g. new and old) per EE
  • If external CMPv2 server is used operator may pay for every new certificate, which is a case when consecutive Initialization Requests are sent


Certificate update may happen in two different flavors and both should be supported:

  • when end entity certificate data has been changed (e.g. Subject DN and/or extensions)
  • when end entity certificate data hasn't been changed at all

Underneath different CMPv2 message is sent: Certificate Request (CR) and Key Update Request (KUR) respectively. 

Solution

Overview

Following diagram presents needed changes:

API (server) side

New endpoint on CertService API should be available to trigger certificate update use case. Internally (based on sent Certificate Signing Request (CSR), private key (PK) and current certificate (question)) it should distinguish if KUR or CR request should be created and sent to CMPv2 server. Message sent to CMPv2 server should be protected by RV/PSK (as Initialization Request nowadays)  or by sent certificate (question)

Client side

CMPv2 external issuer for Cert-Manager has to be extended by logic which detects which CertService API endpoint should be called depending if certificate was already issued or not. It should collect needed data and send REST based request to API.

CertService client (used by K8s workloads as init container) won't support proper certificate update and is planned to be deprecated soon.


Integration

Certificate update ill be tested with open source CMPv2 server - EJBCA.

  • No labels