![\"\"](\"http:\/\/www.bussink.ch\/wp-content\/uploads\/\/2017\/05\/HomeDC-PKI-Lifecycle.jpg\")
<\/a><\/p>\nYou can find the original diagram on this Microsoft PKI Certificate Lifecycle article<\/a>. So instead of having a Root CA that is valid for 20 years and an Issuing CA that is valid for 10 years, I went with smaller validity periods, like 8 years for the Root CA and 4 years with the Issuing CA.<\/p>\n I use two different set of Generation PKI Infrastructure. The G1 on which this article is written is using a Root CA with a RSA (4096 Bits) Public Key<\/strong> and a sha512RSA Signature Algorithm<\/strong> for my G1 tier and the same for my Issuing CA. The G2 that you will see on some of the screenshots is based on a Root CA with a Elliptic curve cryptography (ECC)\u00a0P521 and a sha512ECDSA Signature Algorithm.<\/p>\n Since my infrastructure is now running since 2015, I’m now closing in to the half-time of the Issuing CA validity period. What I decided to do is the following renewal:<\/p>\n When you do a certificate renewal, the new version has a (1) behind it. The certificate request would now be called Issuing CA G1(1).req<\/p>\n Let’s have a look at the original Issuing CA certificate on the Root CA.<\/p>\n And the Issuing CA detail is<\/p>\n This is now impacting me when I attempt to sign new certificates with a validity of over 24 months. Because those are now limited in their validity until the 4th December 2019.<\/p>\n The first step on the Issuing CA is to Stop Service<\/strong> of the PKI and launch the Renew CA Certificate<\/strong> process. I decided to generate a new public and private key, so my new Issuing CA request file is now named Issuing CA G1(1).\u00a0Take the certificate request to the Root CA. On the Root CA, \u00a0 I need to export<\/strong> the signed certificate (I used the PKCS #7 .p7b with certificate path format), move it to the Issuing CA and Import CA Certificate<\/strong>.<\/p>\n In the following steps I’m doing a few more operations on the Root CA. Now that I have Revoked (Yeah with insight I might better have not revoked the original Issuing CA… might need to update this article if I run into issues…) it’s time to do the annual publish<\/strong>ing of the Certificate Revocation List (CRL).<\/p>\n I can see in my Root CA CRL now the old revoked Issuing CA certificate serial number.<\/p>\n Moving along on the Issuing CA in the Active Directory, I’m publishing the update Root CA CRL using certutil -dsPublish RootCA.crl RootCA<\/strong><\/p>\n For the computers and operating systems that are not in the Active Directory and that cannot check the state of the Certificates from the AD, I have a Windows server with the IIS Web server running that publishes the CRLs. This server while having the FQDN of pki-web.bussink.org is also referred by the alias pki.bussink.org on my network. I copied the updated Issuing CA(1) certificate and the Root CA CRL on the directory mapped by the IIS server.<\/p>\n On the Issuing CA in the Enterprise PKI tab, you can ensure that all paths to the Certificates, Certificate Revocation List and Delta CRL work. As you see in the top part of the following screenshot I had not yet copied the Issuing CA(1) certificate. That is corrected in the bottom part of the screenshot.<\/p>\n\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nRevoke<\/strong> the current Issuing CA certificate as it’s Supersed<\/strong>ed<\/strong> and<\/del> Submit new request <\/strong>of the Issuing CA(1) request file. Issue<\/strong> the new SubCA certificate. We now have a Issuing CA certificate with two fields.<\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n