CA Validity Period Extension and CA Certificate Renewal Process

 Introduction

In this article, we will discuss the impact of certificate authority validity period and certificate renewal on issued certificates before and after renewal. Also, I will explain renewal process in detail.

Certificate authority Validity period is the time frame from CA certificate generation date to its expiry date

Certificate Authority cannot issue certificates beyond the expiration date of its own certificate.

The issued certificate validity period depends upon least value of below.

a)     The expiry date of issuing CA certificate

b)    The validity period that is defined in the registry affects all certificates that are issued by Stand-alone and    

        Enterprise CA. For Enterprise CA, the default registry setting is two years.

        For Stand-alone CA, the default registry setting is one year     

c)    The template validity period in case of Enterprise (AD integrated) CA

Basically, there are circumstances where we need to extend CA certificate validity period. Extending CA validity period means renewing existing CA certificate to extend its expiry date

Applicability:

The article applies right from Windows Server 2003 to Windows server 2016

Terminology:

Before we proceed further, we need to understand the basic terminology used here:

• Standalone Root CA – Typically this type of CA remains in workgroup and kept offline for security reasons and certifies / issues Subordinate Enterprise CA certificates
• Enterprise Root CA – Typically this is active directory integrated version of certificate authority. This is published automatically with AD forest and supports template-based certificate distribution
• CDP – CRL distribution point (CDP) is nothing but CRL distribution endpoints and it would be HTTP based most of the times, apart from that it can be LDAP for AD-integrated CA servers. The CDPs are hardcoded with all issued certificates including Subordinate CA except root CA
• CRL – A Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and should no longer be trusted. Client download CRL from CDP endpoint and checks their issued certificates against CRL to make sure the certificate is not revoked and is valid. CDP endpoint is hardcoded in all issued certificates. CA servers publish CRL periodically with updated information
• AIA – Authority Information Access (AIA) is another endpoint where an issuer certificate public key is stored, clients contact this endpoint and download issuer certificate to check issuer certificate authenticity and to build a certificate chain. AIA endpoints are mostly HTTP based, apart from that it can be LDAP based for AD-integrated CA servers. The AIA endpoints are hardcoded with all issued certificates including Subordinate CA except root CA
• SKI – Subject Key Identifier (SKI) is unique hash value generated by certificate public key and assigned to every certificate. Issuer certificate SKI is injected in all certificates it issues as AKI extension based on which client certificate establish trust chain with issuer certificate.
• AKI – Authority key identifier (AKI) is a client certificate extension which points to the SKI of the certificate issuer which in turn helps the client to build a certificate trust chain with issuer certificate
• Thumbprint – This is a hash value generated by certificate key pair to identify certificate itself and remain unique for every certificate. Issuer CA always identify issued certificates based on a thumbprint
• Key Pair – Public key and private key forms a key pair. A private key can identify its corresponding public key and vice versa. Public keys can be distributed to recipients of encrypted data and the private key remains with the owner. The data encrypted by a private key can be decrypted by a corresponding public key and vice versa. When the public key is signed by CA certificate, the key pair is converted into an x.509 certificate.
• CA Version - CA Version extension is a two-digit value separated by dot only found in root certificates / subordinate certificates to keep track of certificate revisions caused by CA certificate renewal.
  
  1^st digit represents CA Certificate renewal number (index) and 2^nd digit represents CA Key pair number (Index) used to renew a certificate. 1^st root / subordinate certificate always has 0.0 as CA version value.
  
  Each time when 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.
  
  If the certificate is renewed with the same key pair, CA Key Index value is not changed.
   
  If the certificate is renewed with a new key pair, CA key number index value will be set to the same as CA certificate renewal index, resulting CA version value would be 0.0, 1.1, 2.2, 3.3 and so on.

• Previous CA certificate hash – This extension would be generated every time when root / subordinate CA certificate is renewed (with existing key pair / new key pair). It contains a thumbprint of the last CA certificate to keep track of the certificate revision chain

Issue Statement:

Organisations that deploy two tier / three tier CA architecture, during installation of Root CA (Enterprise / Standalone), they deploy it with a default validity period (5 Years) as shown below

After that, they deploy Subordinate CA server which would be having a validity of one year in the case of standalone Root CA or two years in the case of Enterprise Root CA by default and this cannot be changed during installation unless we do additional pre-configuration

In this case, the validity of certificates issued by this subordinate CA would be mostly less than one year

Now, what if we want to issue client certificates with an expiration of more than 1 year (say 2 years)?

OR

An organization where 1000's of certificates got issued with one-year validity and you wanted to renew them with 2+ year’s validity?

OR

If you only have Enterprise Root CA and wanted to increase its validity period?

Resolution:

Ideally, this situation should be avoided by carefully planning your PKI infrastructure. At the start, Root CA should be installed with a 20 year validity period and Sub CA should be installed with a 5 to 10 years validity. If we did not configure CA during the initial install with high validity periods, then we need to extend Root CA validity followed by Sub Enterprise CA so that they can issue certificates with extended validity.

For Example; extend Root CA validity to 10 years, extend Sub Enterprise CA validity to 5 years so that Sub Enterprise CA can issue certificates with more validity period such as 2 years

This scenario needs extra configuration in addition to certificate renewal to extend CA validity period for both (Root and subordinate) certificate authorities. We have the option to renew CA certificate with existing key pair or new key pair. I will explain both options here.

To explain above process in detail, I have setup lab with few virtual machines

• 1 x Standalone Root CA (Windows Server 2008 R2)
• 1 x Domain Controller (Windows Server 2012 R2)
• 1 x Enterprise Root CA (Windows Server 2012 R2)
• 1 x SubCA - pointing to Standalone Root CA (Windows Server 2012 R2)
• 1 x Enterprise SubCA - pointing to Enterprise Root CA (Windows Server 2012 R2)
  
  
  

Option 1 - Extend Standalone / Enterprise Root CA Validity Period (Existing Key Pair)

Step 1.1 – Configure CAPolicy.inf 

We are telling CAPolicy.inf to extend the Root certificate validity to 10 years upon root CA certificate renewal. Existing certificate validity cannot be extended, hence renewal is mandatory so that the extended validity period would be reflected in a new certificate

a)    Login to Root CA server with a local administrator/domain administrator account

b)    Create / modify (existing) CAPolicy.inf  file under %systemroot% directory

c)    Put the lines shown below in the file:

[Version]
Signature="$Windows NT$"

[Certsrv_Server]
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10

d)    Ensure that file is saved with ANSI encoding with file extension as “inf”

The contents of CAPolicy.inf file are self-explanatory and only used during root certificate renewal. While renewing certificate CA server looks for this file and if found act on it.

Step 1.2 - Renew Standalone / Enterprise Root CA Certificate (Existing Key pair)

Root CA certificate will be renewed with an existing key pair, hence renewed certificate SKI extension remains the same as the previous certificate. Certificates issued before renewal contain an AKI extension value which points (match) to SKI value of the certificate issuer.

As a result, all previously issued certificates will chain up to new CA certificate. Once the renewed certificate is available with a client trusted root store, you may remove the previous certificate before it expires. It is as good as increasing current CA certificate validity period.

The screenshot below shows Root CA renewal process with an existing key pair

Right-click Root CA and click “All tasks\Renew CA Certificate” as shown above

Certificate services must be stopped before certificate renewal, click yes

Accept default value of “No” and click OK

Certificate got renewed

 

We can see that Root CA cert validity is extended for the next 10 years until 2028, also the “valid from” date is the same with both certificates

More Information

CA Index

We can see that the new Certificate index is increased by 1 as shown above. This is useful to keep the certificate's versioning track.  SRCA_RootCA.crt (Certificate #0) is previous certificate and SRCA_RootCA(1).crt (Certificate #1) is a new certificate. When you renew a CA certificate with an existing key pair, the renewed certificate will be generated with the existing certificate public and private key and existing CRL will be continued (RootCA.crl). 

Subject Key Identifier (SKI)

Since the certificate is renewed with an existing key pair, the renewed certificate “Subject Key Identifier” (SKI) value remains same as the previous certificate as shown below.

Ultimately the renewal process increases the existing certificate validity period in terms of a renewed certificate. Certificates issued before and after renewal would validate and chain up with the new certificate

CA Version

1^st certificate which was created during CA installation, have CA version no 0.0 as shown above.

Post renewal with existing key pair, CA version number got increased by 1.0 as shown above.

Here 1 represents the CA certificate index and 0 represents the certificate key index, since we used an existing key, the key index value did not change. Every time you renew CA certificate (regardless of existing or new key pair), CA certificate index would be increased by 1 as shown below

CA version keeps track of certificate revisions. The CA Version extension allows building correct chains in the case when a particular CA has more than one certificate because of renewal.

Step 1.3 – Configure AIA and CDP Extensions

• When you configure Root CA (Enterprise / Standalone), Sub CA for 1st time, http based AIA and CDP points should be configured as appropriate to avoid issues later point. This is a one time process and must be completed before you start issuing certificates. If you have already done that, you can ignore this step

• I have given steps here to configure AIA and CDP extensions for those who may be unaware about them and not configured yet so that they can configure those post certificate renewal and before start issuing new certificates

1.3.1 - AIA Extension

Authority Information Access (AIA) is endpoint where the issuer certificate public key is stored, clients contact this endpoint and download issuer certificate to check issuer certificate authenticity. AIA endpoints are HTTP and LDAP based, we will focus on HTTP based endpoints. The AIA endpoints are hardcoded with all issued certificates including Subordinate CA

1.3.1.1 - Standalone Root CA

Root CA by default publish its certificate and CRL under Certenroll shared folder on the same server. In case of Standalone Root CA, since it remains offline most of the time, we need to publish HTTP based AIA point on some other IIS server or alternatively on Sub CA server. 

On IIS server, need to create a virtual directory (Say its name is Certenroll) with everyone read permissions under default website and need to copy Root CA certificate from CA server.

AIA URL

http://MyServer/CertEnroll/<ServerDNSName>_<CAName><CertificateName>.crt

In above URL, Replace "MyServer" with your IIS server hostname / FQDN, Maybe you can create some ALIAS in DNS and point it to IIS server.

Add the above URL as http AIA extensions on CA server as shown below and click OK. CA service will be restarted automatically to make changes effective. This is variable based URL and always resolves to latest renewed CA certificate and URL get hardcoded to all certificates issued by Root CA henceforth.

Whenever CA certificate gets renewed, you need to copy renewed root CA cert manually at this location

Sample certificate with HTTP based AIA endpoint pointing to latest valid Root Certificate

1.3.1.2 - Enterprise Root CA

AIA URL

http://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CAName><CertificateName>.crt

The above extension (URL) in the form of a variable already present on CA under AIA extensions; It is pointing to certenroll share folder on CA server itself. This folder contains Root CA certificate (public key). CA automatically copy updated Root Certificate to the CertEnroll folder.

If the extension is not present, we need to add it and enable it as shown below. By enabling this URL, CA service will be restarted automatically to make changes effective.

The process will ensure that latest / renewed CA certificate would be added (hardcoded) as HTTP based AIA endpoint to all certificates that Root CA will issue henceforth.

Sample certificate with HTTP based AIA endpoint pointing to latest valid Root Certificate.

1.3.2 - CDP Extension

CRL distribution point (CDP) is nothing but CRL distribution endpoints and it would be HTTP and LDAP based. The CDPs are hardcoded with all issued certificates including Subordinate CA. We will be focusing on HTTP based extensions

1.3.2.1 - Standalone Root CA

CA server by default publish CRL files under CertEnroll share folder on same server

For Standalone root CA servers, CRL changes are rare as it is used to issue certificates to issuing / Sub CA servers only

Since Standalone Root CA remains offline, we should keep CRL publishing interval at least one year as shown above so that CRL remains valid for a year and clients (Sub CA) can check revocation function.

Now we need to publish HTTP based CRL Distribution Point (CDP) point on some other IIS server or alternatively on Sub CA server as a Standalone root CA will turned OFF (remain offline).

On the IIS server, you need to create a virtual directory (Say its name is CertEnroll) with everyone read permissions under default website and need to copy CRL from CA server

CDP URL

http://MyServer/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl

Replace "MyServer" with your IIS server hostname / FQDN, Maybe you can create some ALIAS in DNS and point it to an IIS server

Add the above URL as http CDP extension on CA server as shown below and click OK. CA service will be restarted automatically to make changes effective. This is variable based URL and always resolved to the latest CRL file and URL gets hardcoded to all certificates that CA issues henceforth

Whenever you publish/update CRL, you need to copy updated CRL manually to above location. We don't need delta CRL for standalone Root CA servers

Sample certificate with HTTP based CRL endpoint pointing to latest valid CRL file

1.3.2.2 - Enterprise Root CA

For Enterprise CA servers, CRL validity/publishing interval should normally be configured to 7 days

CDP URL

http://<ServerDNSName>/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl

The above extension (URL) in the form of a variable is already present in CA CDP extensions; It is pointing to certenroll share folder on CA server itself. This folder contains Root CA CRL file. CA automatically copy updated CRL file to the CertEnroll folder.

If the extension (URL) is not present, we need to create it and enable it as shown below. By enabling this extension, CA service will be restarted automatically to make changes effective.

This process will ensure that CRL extension (URL) would be added (hardcoded) as HTTP based CDP endpoint to all certificates that Root CA will issue henceforth. 

Sample certificate with HTTP based AIA endpoint pointing to latest valid Root Certificate. CA automatically copy Root Certificates to CertEnroll folder

1.3.2.2.1 - Allow Delta CRL download

This is one time step/process and should be done when you install Enterprise Root CA servers along with IIS based web enrollment. If you have already done this step, ignore it.

Enterprise CA servers also contain delta CRL which have a "+" sign incorporated in its name.

Example: http://EnterPriseRCA.testlab.com/CertEnroll/ENTPRISERootCA+.crl

IIS 7 and above by default blocks download of delta CRL files, we need to allow them. You must enable Double-Escaping for the virtual directory that will host the delta CRL file. In our case, it is the CertEnroll virtual Directory on CA server. Start elevated cmd on CA server and navigate to %systemroot%\system32\inetsrv folder and enter the command shown below

appcmd.exe set config "Default Web Site/CertEnroll" -section:system.webServer/security/requestFiltering -AllowDoubleEscaping:true

Command completed successfully. We can verify from GUI as shown below

Step 1.4 – Publish Root CA Certificate and CRL to Active Directory

1.4.1 - Publishing Root Certificate to Active Directory

This step is not required in case of enterprise CA servers, renewed CA certificates are automatically published to active directory for clients to identify and trust the root certificate

If this is Standalone Root CA, we need to publish renewed Root certificate to the active directory manually
we can use group policy to distribute Root CA certificate to all clients to trust with

OR

On Enterprise Sub CA server (Standalone Root CA alone cannot service active directory, you must deploy Subordinate Enterprise Root CA) logon as a member of domain admins and Enterprise admins of the root domain and copy the renewed root CA certificate from root CA.

Now run the below command from an elevated command prompt. The command will publish root certificate with AIA container in active directory, once published in AD, clients can download those automatically

certutil -dspublish -f "C:\RootCACertificate.crt" RootCA  ------- (If it is Standalone Root CA) 

Replace certificate path and name with actual one

Published certificate location (AIA container) in active directory

1.4.2 - Publish updated CRL to active directory

If root CA certificate (Standalone / Enterprise) is renewed with existing key pair, no new CRL is generated

When you install enterprise Root CA, CRL is published with Active Directory automatically every time

When you install Standalone root CA, 1st CRL needs to be published manually with active directory. If you have missed this step, then only follow the steps as mentioned below

Run the command below on a Standalone Root CA with elevated command prompt followed by CA service restart:

Certutil.exe -setreg ca\DSConfigDN "DC=configuration,DC=domain,DC=com"

Replace "domain" name and "TLD" with yours

Command completed successfully

Since the Standalone RootCA is not part of a domain, the above registry gets added/hardcoded in the .crl file with an extension as "Published CRL Locations"

Based on this info, "Certutil -dspublish" command publish CRL within active directory configuration container under the Services\Public key services\CDP container, In order to run the command, we must copy Root CA CRL on Enterprise Sub CA. The command would be:

Certutil -dspublish -f C:\RootCA.crl RootCA

Command Completed Successfully. below screenshot shows Root CA CRL published with active directory

Published certificate location (CDP container) in active directory

Option 2 - Extend Standalone / Enterprise Root CA Validity Period (New Key Pair)

While the 1^st option sounds best, there are few reasons as shown below that you need to renew Root CA certificate with a new key pair

1.    CA signing (existing CA key pair) is compromised;

2.    You have a program that requires a new signing key to be used with a new CA certificate; (this requirement I have seen written everywhere and even with CA renewal dialogue box as well, but I never see this is a requirement kept by any applications as of now)

 

3.    The current CRL file is too large and you want to move some revocation information to a new CRL file.

Renewal Process would be same as previous option 1 except little change in step 1.2 and step 1.4, rest of the steps (1.1 and 1.3) are same.

Step 2.1 – Configure CAPolicy.inf (Same as Step 1.1)

Step 2.2 - Renew Standalone / Enterprise Root CA Certificate (New Key pair)

 

While you renew Certificate, you need to tell the wizard to renew certificate with the new key pair as shown below.

 

Select “Yes” and click “OK” and certificate would be renewed.

Certificate got renewed successfully

More Information

• (Certificate #0) SRCA_RootCA.crt is the original certificate generated when we deploy CA
• (Certificate #1) SRCA_RootCA(1).crt is the certificate generated after renewal with existing key pair
• (Certificate #2) SRCA_RootCA(2).crt is the certificate generated after renewal with new key pair

CA Version Extension

When you renew a  CA certificate with a new key pair, many things in the CA certificate are changed.

The 1^st certificate which was created during CA installation has a CA version no 0.0 as shown above. Post renewal, CA version number got changed to 1.0

Here 1 represents CA certificate index and 0 represents certificate key index, since we used an existing key pair, the key index value did not change. Every time you renew CA certificate, CA certificate index would be increased by 1

After that we have renewed CA certificate again with a new key pair, CA version number got changed to 2.2

Here the first 2 represents CA certificate index (increased from 1 to 2) and another 2 represents certificate key index, since we used a new key pair, the key index value is set same as certificate index. If we further renew this certificate with a new key pair, CA version would be set to 3.3

CA version keeps track of certificate revision. CA Version extension allows building correct chains in the case when a particular CA has more than one certificate because of renewal

SKI Extension

New SKI value is generated with renewed certificate. Renewed Certificate “valid from” date would be current date and time.

SKI extension of the previous certificate (Certificate #1)

SKI extension of the renewed certificate (Certificate #2) - its different from the previous certificate (Certificate #1)

When CA issues new certificate it injects own certificate SKI value to issued certificate AKI extension. The client compares the issued certificate AKI value with issuer certificate SKI extension and if matched, builds a certificate chain. SKI extension of the new certificate (Certificate #2) is different from Certificate #1 as the certificate is renewed with a new key pair, previously issued certs will chain up to previous CA cert and newly issued certs will chain up to new CA cert respectively.

Certificate Revocation List (CRL)

In addition, a new CRL is generated with appending renewed Certificate index value such as “RootCA(2).crl” against previous CRL (RootCA.crl). This CRL will contain only those revoked certificates that were signed using renewed CA certificate. The Old CRL contains certificate revocation list before certificate renewal.

Problem Statement

The Client Certificate chain validation would face a problem if either a previous or renewed CA certificate is not available with the client or it cannot download it from AIA locations.

Resolution

To deal with this problem, Windows automatically generates two additional cross-certificates when you renew a root CA certificate using a new key pair: one cross-certificate that's signed by the old CA that certifies the new CA certificate, and one cross-certificate that's signed by the new CA that certifies the old CA certificate. You can find these cross-certificates under CertEnroll share folder on root CA server as shown below:

• SRCA_RootCA.crt is the original Certificate generated when we installed Root CA (Certificate #0)

• RootCA.crl is the original CRL file generated when we installed root CA

• SRCA_RootCA(1).crt is the renewed certificate generated with existing key pair (Certificate #1)

• SRCA_RootCA(2).crt is the renewed certificate generated with a new key pair (Certificate #2)

• RootCA(2).crl is the new CRL file generated when we renew CA cert (Certificate #2) with a new key pair

• SRCA_RootCA(1-2).crt is the 1^st cross certificate having same SKI as SRCA_RootCA(2).crt (Certificate #2) and signed by SRCA_RootCA(1).crt (Certificate #1)

• SRCA_RootCA(2-1).crt is the 2^nd cross certificate having same SKI as SRCA_RootCA(1).crt (Certificate #1) and signed by SRCA_RootCA(2).crt (Certificate #2)

Now these cross certificates can be used *only* if they are available with the client machine under intermediate store and either Certificate #1 or Certificate #2 certificates are not available with the client trusted root store or the client cannot download them from AIA locations to establish trust validation chain

Consider Leaf1 is the client certificate issued before CA certificate renewal by Certificate #1 as issuing Root Certification authority. The available certificate chains are as below

1. Leaf1-----> Certificate #1 [SRCA_RootCA(1).crt]
2. Leaf1 ----->SRCA_RootCA(2-1).crt [Cross Certificate] -----> Certificate #2 [SRCA_RootCA(2).crt]

If leaf1 finds Certificate #1 as direct parent under trusted root store, the chain will be completed and then there is no question of Cross certificates, however, if Leaf1 did not find Certificate #1 but find Cross Cert “SRCA_RootCA(2-1).crt” under intermediate store, then due to matching AKI field of Leaf1 with SKI field of cross cert “SRCA_RootCA(2-1).crt”, it establishes chain with that cert and eventually with Certificate #2 (Leaf1 – Cross certificate “ SRCA_RootCA(2-1).crt” – Certificate #2)

Consider Leaf2 is the client certificate issued post CA certificate renewal by Certificate #2 as issuing Root Certification authority. The available certificate chains are as below

1. Leaf2-----> Certificate #2 [SRCA_RootCA(2).crt]
2. Leaf2 ----->SRCA_RootCA(1-2).crt [Cross Certificate] -----> Certificate #1 [SRCA_RootCA(1).crt]

If leaf2 finds Certificate #2 as direct parent under trusted root store, then the chain will be completed and there is no question of Cross certificates, however, if Leaf2 did not find Certificate #2 but find Cross Cert “SRCA_RootCA(1-2).crt” under intermediate store, then due to matching AKI field of Leaf2 with SKI field of Cross Cert “SRCA_RootCA(1-2).crt”, it establishes chain with that cert and eventually with Certificate #1 (Leaf2 – Cross certificate “ SRCA_RootCA(1-2).crt” – Certificate #1)

The above scenario would work until the previous root certificate expires, once it expired, Cross Certificates are not required anymore. In fact, when the previous root certificate is about to expire or has expired, all certificates issued by this cert would also expire or already have expired and meantime the new root certificate would already have deployed on all clients

Step 2.3 - Configure AIA and CDP Extensions (Same as step 1.3)

Step 2.4 – Publish Root CA Certificate and CRL to Active Directory

2.4.1 - Publishing Root Certificate to Active Directory (Same as step 1.4.1 with the addition of Cross CA certificate)

This step is not required in case of enterprise CA servers, renewed CA certificates including cross certificates are automatically published to active directory for clients to identify and trust root and cross-certificates

If this is Standalone Root CA, we need to publish renewed Root certificate and Cross Certificates to the active directory manually.

we can use group policy to distribute Root CA certificate to all clients to trust with

OR

On an Enterprise CA server logon as a member of domain admins and Enterprise admins of the root domain and copy renewed root CA certificate and cross-certificates. Now run the command below from an elevated command prompt. Command will publish root cert with AIA container in the active directory

 

Certutil –dspublish –f C:\Certs\SRCA_RootCA(2).crt RootCA 
Certutil –dspublish –f C:\certs\SRCA_RootCA(1-2).crt CrossCA 
Certutil –dspublish –f C:\Certs\SRCA_RootCA(1-2).crt CrossCA

2.4.2 - Publish updated CRL to active directory

When we renew CA certificate with a new key pair (Standalone / Enterprise), new CRL file would be generated as shown in step 2.2

If it is enterprise CA server, all CRL files (previous and new) are automatically registered with active directory.

If it is standalone CA server, we must publish new CRL with active directory. In case if you never published CRL from Standalone Root CA to the active directory then please follow prerequisites steps mentioned in step 1.4.2

To publish new CRL with active directory, copy new CRL from standalone Root CA to Enterprise Sub CA and run the command below from an elevated command prompt on Sub CA server

certutil.exe -dspublish -f "C:\RootCA(2).crl" RootCA

Command completed successfully

We can navigate to active directory configuration partition and locate old and new CRL locations published under CDP container

---

Extend Sub CA validity period

Option 1 – When the issuer is a Standalone Root CA

In the case of a standalone Root CA, subordinate CA certificate validity will be 1 year only (by default)

To configure SubCA with 5 year’s validity, we first need to ensure that the Standalone Root CA servers have enough validity period configured and their root certificate expiry date is greater than 5 years. If not, then first follow the steps mentioned under "Option 1 - Extend Standalone / Enterprise Root CA Validity Period (Existing Key Pair)" OR "Option 2 - Extend Standalone / Enterprise Root CA Validity Period (New Key Pair)"  and configure your root CA certificate with an appropriate validity/expiry date as CA cannot issue certificates with validity greater than its own certificate expiry date.

Then we need to run the commands below on Root CA server

certutil -setreg CA\ValidityPeriod Years
certutil -setreg CA\ValidityPeriodUnits 5
net stop certsvc && net start certsvc

Above command will ensure that Root CA will issue all certificates with 5 years validity

Command completed Successfully

Once Root CA server is ready, start CA validity renewal process on Sub CA as below

 

Right-click SubCA, navigate to All tasks\Renew CA Certificate

Click yes to stop CA service

Select “No” and click “OK” if you want to use existing key pair. Post renewal old and new certificates SKI extension field value remains same and hence client certificates issued before and after CA renewal, both chain up to new CA certificate without any issues, also existing CRL will be used

OR

Select “Yes” and click “OK” if you want to use a new key pair. Post renewal old and new certificates SKI extensions remain different. Certificates issued before the renewal will chain up to previous certificate and certificates issued post renewal will chain up to renewed certificates, additionally new CRL will be published. New CRL will contain revoked certificates which were signed by new CA certificates and old CRL contains revoked certificates which were signed by previous CA certificate

 

In this case, we need to keep both CA certificates (previous and renewed) and both CRL files to avoid chain validation and revocation checking issues.

Click cancel to generate request file which needs to be sent to standalone Root CA

 

File “RootDC.testlab.com_testlab-ROOTDC-CA(2).req” would be sent to a standalone root CA and he will issue SubCA certificate based on this request and once certificate received, we need to install this certificate on SubCA

Now right click “SubCA” and click “install CA certificate”. Wizard will ask to stop the CA service and then ask for certificate file, supply path containing received certificate file and certificate will get installed.

We can see that Sub CA certificate is renewed with 5 year’s validity period against 1 year of the previous certificate

• RootDC.testlab.com_SubCA.crt is the original CA certificate generated when we installed SubCA
• SubCA.crl and SubCA+.crl are the original CRL files generated when we installed SubCA
• RootDC.testlab.com_SubCA(1).crt is renewed certificate with existing key pair
• RootDC.testlab.com_SubCA(2).crt is renewed certificate with new key pair
• Above files will be automatically published to active directory, We need to ensure that CDP and AIA points are set as appropriate as shown in section 1.3

Option 2 – When the issuer is an Enterprise Root CA

In the case of an Enterprise Root CA, subordinate CA certificate validity will be 2 years only (by default)

To configure SubCA with 5 year’s validity, we first need to ensure that Enterprise Root CA servers have enough validity period configured and their root certificate expiry date is greater than 5 years. If not, then first follow steps mentioned under "Option 1 - Extend Standalone / Enterprise Root CA Validity Period (Existing Key Pair)" OR "Option 2 - Extend Standalone / Enterprise Root CA Validity Period (New Key Pair)"  and configure your root CA certificate with appropriate validity/expiry date as CA cannot issue certificates with validity greater than its own certificate expiry date.

 

Then we need to run the commands below on the Enterprise Root CA server

certutil -setreg CA\ValidityPeriod Years
certutil -setreg CA\ValidityPeriodUnits 5
net stop certsvc && net start certsvc

Above command will ensure that Root CA can issue certificates with 5 year’s validity

Command completed successfully

Further, Enterprise Root CA by default use the “Subordinate Certificate Authority” template to issue SubCA certificate which have 2 year’s validity and we cannot change this validity. Hence we need to create custom SubCA template with the required validity period on Root CA, Create CAPolicy.inf on SubCA with “RequestAttributes” parameter which forces RootCA to issue SubCA certificate based on the custom template

On the Enterprise Root CA, right click Subordinate CA template and click “Duplicate Template”

 

Set template name, validity as required (5 years in our case), click Apply

We have created template, now we must publish it with active directory so that it can service requests

From CA console, right click "Certificate Templates", click new > Certificate Template to issue

Select custom template from the list created earlier and click OK

Now template is available / published with active directory and service requests

On Sub CA server, create/edit the CAPolicy.inf and add the custom template name as shown above and save this inf file under %systemroot% folder

Now on SubCA, start the certificate renew process as shown above

Click yes to stop CA service

Select “No” and click “OK” if you want to use existing key pair. Post renewal old and new certificates SKI extension field value remains same and hence client certificates issued before and after CA renewal, both chain up to new CA certificate without any issues, also existing CRL will be used

OR

Select “Yes” and click “OK” if you want to use a new key pair. Post renewal old and new certificates SKI extensions remain different. Certificates issued before renewal will chain up to the previous certificate and certificates issued post renewal will chain up to the renewed certificate, additionally new CRL will be published. New CRL will contain the revoked certificates which were signed by new CA certificates and old CRL contains revoked certificates which were signed by previous CA certificate

Select Enterprise Root CA from “Browse” button and click OK

Certificate got renewed successfully

The New Certificate is now valid for 5 years

We need to ensure that CDP and AIA points are set as appropriate as shown in section 1.3

In this case, no cross certificates are generated and need to keep both CA certificates (previous and renewed) along with both CRL files until the previous certificate expires to avoid chain validation and revocation checking issues.

Note - If the Enterprise Root CA is already deployed in the organization, I do not recommend to deploying subordinate Enterprise CA servers as both servers must remain online and there is no difference functionality wise unless you have multiple locations with restricted connectivity and if your certificate consumption is high per location. If you are concerned about key compromise, you can use HSM device to store CA private key.

Verdict:

Finally, the question here is whether to use an existing key pair or a new key pair for CA certificate renewal?

Well, Microsoft has not provided any affirmative answer on this and kept both options open for us.

Existing key pair options looks effortless and maintenance free, I don't see any issues unless the existing certificate is compromised. Renewal process creates two separate chains, one pointing to the previous certificate and another pointing to the renewed certificate. Certificate chaining engine (CCE) applies certain rules to select the best chain and may face issues while selecting the best chain as highlighted by Microsoft KB329433, KB2639180 in certificate chaining engine. However, these issues are reported by few previous client operating systems like Windows XP and Vista, did not hear/see any issues from the newer operating systems.

As opposed, new key pair option certain that every certificate would have a single chain and eliminates the issue with multiple chains if any. Although using a new key pair option also generate multiple chains if we use cross certificates and may create issues as highlighted in KB2831004,  however, cross-certificates are used for the time being until previous root certificate along with the previously issued certificates expire and a new root cert populates on client machines. In fact, we can avoid publishing cross certificates by ensuring that old CA certificate is already installed on clients under trusted store and distributing new CA certificate on all client machines ASAP with GPO OR with publishing in AD and publishing as AIA HTTP extension. Once new CA certificate is populated everywhere, the certificate issued post renewal will chain up to new cert only. In fact, in that case we can tell certificate authority to not generate cross certificate during certificate renewal by running the command below

certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS

Ideally, we need to ensure that from start, CA certificates before and after renewal are pushed to all domain-joined clients, are downloadable for non-domain-joined clients if any and are present on all clients in their Trusted Root CA certificate store. To make sure that non-domain-joined clients can download the certificates, we should publish old and new CA certificates to the http based AIA locations automatically or manually and clients can access the associated AIA URLs.

References:

• https://social.technet.microsoft.com/wiki/contents/articles/2016.root-ca-certificate-renewal.aspx
• https://msdn.microsoft.com/en-us/library/windows/desktop/aa376550(v=vs.85).aspx
• http://www.itprotoday.com/security/q-whats-impact-renewing-enterprise-root-cas-certificate-our-existing-pki-clients-and
• https://www.sysadmins.lv/blog-en/how-to-change-ca-certificate-validity-period.aspx

I hope this article would be informative to understand CA validity and renewal concept along with the process

 

If you found this article useful, please click the Thumbs-Up icon below.