Update 22.10.2017: updated use-case recommendations based on best practices.

Update 27.06.2018: added commands


In this article I will discuss about Root CA certificate renewal with new and existing key pair. At first we discuss about CA certificate renewal with existing key pair.

Renewal with existing key pair

When you renew CA certificate with existing key pair, nothing important in certificate is changed. The certificate will contain the same public and private key. As the result all previously issued certificates will chain up to new CA cert without any changes. You just replace old CRT file in AIA download locations. In addition, new CA cert ValidFrom (NotBefore) field will contain the value when existing CA key pair was generated. For example, old CA cert has ValidFrom (NotBefore) = 08.10.2000 and ValidTo (NotAfter) 08.10.2010. When you renew CA cert with existing key pair new certificate will have following values: ValidFrom (NotBefore) 08.10.2000 and ValidTo (NotAfter) 08.10.2020. In other words this renewal just increases current CA certificate validity period. In addition new CA cert introduces one new extension: Preious CA certificate hash that will contains preious certificate Thumbprint extension value. And changes another extension: CA Version. Let's take a look to a CA Version extension.

CA Version extension allows to build correct chains in the case when particular CA has more than one certificate. This extension consist of two values: CA Certificate Index and CA Key Index. These values are separated by dot, for example: 0.0, 2.1, 3.3, etc. Each time you renew CA certificate (regardless with existing or new key pair), CA Certificate Index is increased by 1: 0.0, 1.0, 2.0, etc. Since the key pair remains the same, the CA Key Index value is not changed. In that case CA will maintain the same CRL's and clients will be able to chain previously (prior to CA cert renewal) and newly (after CA cert renewal) issued certificates up to new CA certificate. This is because all these client certificates was signed by the same CA signing key and both CA certs produces the same signature for the identical data.

After CA cert renewal, new CA cert will not replace previous CA cert, but is another file and adds a certificate index in parenthesises in the file name. For example old cert has a name: TestCA.crt, and new cert will have the following name: TestCA(1).crt. The number and parenthesises are controlled by <CertificateName> variable in AIA location settings and the number always equals to certificate CA Version extension CA Certificate Index value (except when you setup new CA. In that case <CertificateName> is ignored).

As you see, this renewal is quite simple. However, this method is not suitable when one or more of the following cases occur:

  • CA signing (existing CA key pair) is compromised;
  • You have a program that requires a new signing key to be used with a new CA certificate;
  • The current CRL file is too large and you want to move some revocation information to a new CRL file.

Run the following command on CA server to renew CA certificate and reuse existing key pair:

certutil -renewCert ReuseKeys

Renewal with new key pair

As we have discussed previous scenario is Ok for most scenarios. However there might be a requirement to renew CA certificate with a new key pair. This renewal type is more complex. Since new key pair is generated many things in the CA cert are changed. For example new public key will produce different Subject Key Identifier (the hash of public key). When CA issues new certificate it places own certificate Subject Key Identifier value to a issued certificate Authority Key Identifier extension. Actually these extension comparison is used by certificate chaining engine (CCE). As the result previously issued certs will chain up to previous CA cert and newly issued certs will chain up to new CA cert respectively. In addition new CRL is generated. New CRL will contain only those revoked certificates that were signed using renewed CA cert (or signing key) and new CRL file will contain CRL suffix. For example, old CRL has TestCA.crl name and new CRL will have new name: TestCA(1).crl. This CRL suffix is controlled by <CRLNameSuffix> variable in CDP location settings and the number always equals to certificate CA Version extension CA Key Index value.

Unlike CA Certificate Index value, the CA Key Index is not always increased by 1, but is set to CA Certificate Index value. For example, previous CA cert has CA Version extension as 2.0 and new CA cert CA Version extension will have the following value: 3.3.

To address this issue (when you use new root CA cert, but it is not deployed to all clients yet) Windows CA generates two cross-certificates. First cross-certificate is signed by previous CA signing key and certifies new CA certificate. Certification direction is determined by numbers in parenthesises. In our case one cross-cert will have (0-1) suffix. Here is an example how this works during certificate chain building:

1) PreviousCACert
            LeafPreviousCertificate

2) PreviousCACert
            cross-cert(0-1)
                        LeafNewCertificate

As you see in these example, by using cross-certificate CCE will be able to construct certification paths for previously and newly (after CA cert renewal) issued certificates, so both paths chains up to only previous CA certificate (because new CA cert is not deployed yet). In order to chain both paths to a new CA certificate (when new CA cert is deployed and you are ready to remove old CA cert from clients) additional cross-certificate is generated. In that case new CA cert certifies previous CA cert (reverse direction). This direction is shown in the file name parenthesises: (1-0). And here are examples how this works:

3) NewCACert
            LeafNewCertificate

4) NewCACert
            cross-cert(1-0)
                        LeafPreviousCertificate

As you see by using these cross-certificates you can maintain only one root CA certificate with ability to build correct chains for any certificate issued by this CA (before and after CA cert renewal with new key pair).

In order to use these cross-certificates you must publish them in you Active Directory forest by running the following commands:

certutil –dspublish –f <CAName(0-1).crt> CrossCA
certutil –dspublish –f <CAName(1-0).crt> CrossCA
Replace <CAName(#-#).crt> with actual file names.

Once you have deployed new CA certificate to clients (it MUST be published to Trusted Root CAs container on client computer) you may remove previous CA certificate from clients if they are not required to validate digital signatures.

If you are able to deploy new CA cert to all client computers very quickly, you may ignore these cross-certificates or instruct CA server to not generate them by running the following command:

certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS

Run the following command on CA server to renew CA certificate and create new key pair:

certutil -renewCert

Recommendations

Although key reuse is simple from maintenance overhead perspective, it can cause unpredictable and unfortunate flaws in certificate chain building, because existing certificates will now produce two separate chains: one chain through previous CA certificate and second through renewed CA certificate. Certificate chaining engine will have to do an extra work to select the best chain. Different cryptographic libraries have different metrics and rules used when selecting best chain. However these metrics are not compatible between libraries and behavior may be truly unpredicted. Also, there might be an issue within a single crypto library: KB329433​, KB2639180 and KB2831004 are examples of such issues in Microsoft CryptoAPI certificate chaining engine.

As the result, modern best practices dictate that CA keys SHALL NOT BE REUSED to avaoid potential issues when wrong chain is selected. New key pair ensures only single certification path for each certificate and eliminates the issue with multiple chains and guarantees expected behavior.


Share this article:

Comments:

Mike Elliott
Mike Elliott 19.03.2018 12:58 (GMT+2) Root CA certificate renewal

Hi Vadims,

Thanks you for the detailed description on cert renewal, very useful.

I have a circumstance where I'll be renewing a root CA cert, but have no reason to renew the key pair as the PKI is planned for a major replacement in near future.  In the first paragraph you mentioned that a new CA cert can simply be published to the various AIA locations to replace the old, but then later you mention that the root CA will generate and publish multiple certs (e.g. rootcart.crt and rootcert(1).crt.  

Could I just clarify that in these circumstances with no new key pair, I can take the new cert file (e.g. rootcert(1).crt), rename it to remove the parathesis and index number, and then publish to the AIA locations replacing the old one?  So no need to retain the original cert in the AIA locations, no need to change anything in the extensions tab on the root CA properties etc?

Mike

Mahesh
Mahesh 30.05.2018 18:44 (GMT+2) Root CA certificate renewal

Hi Vadims, If you could please give real test cert example how would cross certs would work Unable to understand how cross cert works

Mohan
Mohan 19.07.2018 14:56 (GMT+2) Root CA certificate renewal

Hi Mike,

We were also under same confusion whether to rename the file or not, however, we have done this excercise recently, to observe that the 'cACertificate' attribute (which is a multi-valued attribute) of the 'certificationAuthority' object under AIA and/or CertificationAuthorities containers, will get appended with the new certificate rather than overwriting the existing certificate. So resulting in both old and renewed certificates available for clients.

Happy renewing.. 

 

 

Mike Elliott
Mike Elliott 06.09.2018 11:04 (GMT+2) Root CA certificate renewal

Thanks Mohan, so it sounds like you published both the old and new certificates to AD and to the AIA locations?

Jiri Benes
Jiri Benes 09.01.2020 10:53 (GMT+2) Root CA certificate renewal

Hi Vadims,

thanks for your article, very useful for us as well!

Just to correct a small typo: at the end of the "Renewal with new key pair" section there is a typo in the text which says "Run the following command on CA server to renew CA certificate and reuse existing key pair:", should state "with new key pair".

+1 here for always renewing Root CA with new key pair. We ran into an issue where Linux/NetApp NAS clients failed to validate server certificate (LDAP server in our case) issued by by Root CA with renewed certificate using an existing key pair, where both the "old/previous" Root CA and "new/renewed" Root CA certificate were present in the root CA trust store on the Linux/NetApp side and the "old" Root CA expired - the Linux/NetApp validated a valid server certificate (issued from the new/renewed Root CA) against the expired "old" Root CA, thus failing the validation due to "expired root CA cert" reason and effectively disrupting connection to LDAP server. Fixed by removing the "old" Root CA from the Linux/NetApp clients.

Vadims Podāns
Vadims Podāns 09.01.2020 11:13 (GMT+2) Root CA certificate renewal

Fixed typo in text.

Rene
Rene 01.07.2020 22:29 (GMT+2) Root CA certificate renewal

Hi Vadims,

thx for you article here. :-) One qeustion:

I renewed our 2 IssuingCAs last december and deploy them through AD to the clients and servers. NT Auth and AIA Cert contains now both certs. Now, at 08.07.20, the issuing CAs are going to expired. My question is, should i remove the old CA cert with PKIVIEW BEFORE this date or should i let this entry like it is and not deleting it? I have read in the web, if you use 802.1x Auth for LAN an WLAN, it could be happend, that the Windows Radius choose the wrong chain certificate and then the auth of the clients will fail. For Radius Auth, i used a new NAP Cert with is valid to 2022. So the new chain is in place and working. We have MAC and Windows 10 Clients here.

So i think its required to delete this old NT AUTH Cert and AIA Certs. But im not sure to do this. Can you tell me, what i should do? I would not break th INF, so i do testing in a lab. Cloneing the DCs on ESXi and delete those certificates with PKIView. No issue happend, auth works, gpupdate and ssl validation of websites etc... I still have recreated the OCSP check on production INF with the new Issuing CA cert...this works fine. But testing and production are 2 pairs of shoes...and we all know Mr. Murphy... :-)

Im scared about the 08.07.20, when the CA is going to expired... What are you doing in a case like this? 

BR

Rene´

Vadims Podāns
Vadims Podāns 02.07.2020 20:31 (GMT+2) Root CA certificate renewal

> should i remove the old CA cert with PKIVIEW BEFORE this date or should i let this entry like it is and not deleting it?

It depends, but my recommendation is to leave them as is.

> I have read in the web, if you use 802.1x Auth for LAN an WLAN, it could be happend, that the Windows Radius choose the wrong chain certificate and then the auth of the clients will fail.

NEVER reuse keys during CA renewal to avoid this. Check Recommendations section in this blog post.

Rene
Rene 03.07.2020 15:26 (GMT+2) Root CA certificate renewal
Hi, thx for you answer. OK, leave them as it is sounds good, but what i have to do on 08.07 when its expired? Delete them or not? In my lab, everything works. But 802.1x its not possible to test in my local LAN without any GW and routing. I inspected the EAPOL frames with wireshark. This showed me, that the new CA Certs will be used to validate. The server hello and the client hello showed the right issuing ca cert to me... so i think it have to work.I rollout all new certs to the clients and servers with gpo... on our MACs during Catalina upgrade, we deleted all old certs and recreated the computer cert. This works fine, 802.1x and cert based vpn auth. have no issues. NPS Server cert is also in place with a new cert... so it should be working... everthing... on 08.07. i will see it :-) BR Rene´
Igor
Igor 14.08.2020 11:54 (GMT+2) Root CA certificate renewal

Hi Vadims,

Thanks, your blog very useful.

 I'm trying to renew CA certificate and reuse existing key pair. After runnig command certutil -renewCert ReuseKeys on CA server I get the following error:
CertUtil: -renewCert command FAILED: 0x80090016 (-2146893802)
CertUtil: Keyset does not exist

When I try to create backup with command certutil -v -backup c:\bkpca I get error also:
CertUtil: -backup command FAILED: 0x80090008 (-2146893816)
CertUtil: Invalid algorithm specified.

CA server was migrated from win 2003 to 2008R2 KSP and SHA2. There is one current and two expired CA certificates in CA General tab.
Expired CA certificates has Siganture algorithm sha1RSA. The oldest one has CSP provider and shows Encryption test FAILED when I run certutil -store my.

Is it possible that certutil -renewCert ReuseKeys trying to check old CA certificates as well and fails ? How can I point CertUtil to renew only current CA certificate ?

 

Vadims Podāns
Vadims Podāns 14.08.2020 18:44 (GMT+2) Root CA certificate renewal

First of all, reuse of existing keys is NOT a recommended practice. Even if you use HSM.

I'm not sure about exact behavior of '-renewCert', but I would expect it to take the most recent CA certificate and its key to be used as template. What I suspect is that your transition from SHA1 CSP to SHA2 KSP wasn't that successful and there are pending issues. I would suggest to address this issue in PKI forum on TechNet Q&A.


Post your comment:

Please, solve this little equation and enter result below. Captcha