The operations article says this hierarchy has exactly two dates that matter. It then gives you a rehearsed procedure for one of them and nothing at all for the other. This article is the other one.
That omission was not deliberate and it is worth naming, because the missing procedure is the one that needs writing down most. The annual revocation list comes round often enough that somebody builds a habit. A renewal arrives once every few years, will be performed by whoever is holding the role at the time rather than whoever built it, and requires getting the offline root back out of the safe to sign something. Those are precisely the conditions a document exists for.
Prerequisites. The hierarchy from [P 2.1] through [P 6.1], running. Access to ROOTCA, which means the safe, the hypervisor, and whatever your process is for powering on a machine that is deliberately unreachable. A tested backup of both authorities taken immediately before you start, per [P 6.1] Build Sheet: Trust Distribution, Backup, and the Maintenance Calendar. A file transfer path in and out of the root. The maintenance calendar, because the date you are acting on came from it and the date you write back goes into it.
Do this at half life, not near expiry. On the estate in this series the issuing authority holds a five-year certificate and the calendar in [P 6.1] puts its renewal in 2028 against a hard date of 1 August 2031. The gap between those two is the entire point. An authority approaching expiry cannot issue a certificate that outlives its own, so from early 2031 it would begin quietly shortening everything it signs, and the first symptom would be certificates with strange end dates rather than an error anybody notices.
Step 1. Decide which renewal this is
Every renewal produces a new certificate. The only real decision is whether it also produces a new key, and the two outcomes are not close to equivalent.
| Question | Existing key | New key |
|---|---|---|
| What already chains | Everything, to either certificate, because both carry the same key and produce the same signature | Old certificates chain to the old certificate, new ones to the new certificate. The chaining engine matches on the key identifier. |
| Revocation lists | One, unchanged. The existing list carries on. | A second list is created, carrying only what was signed by the new key. |
| Cross-certificates | None | Two, generated automatically, so both old and new paths validate while the new certificate is being distributed. |
| Disruption | Close to none | Real, and it lands on relying parties rather than on you |
| Choose it when | The routine case. The certificate is approaching half life and nothing else is wrong. | The key is compromised, something external requires a new signing key, or the revocation list has grown large enough that starting a new one is worth the disruption. |
Unless one of the three conditions in the last row applies to you, this is an existing-key renewal and the rest of this article assumes it until the final step.
Step 2. Back up first, and mean it
Backup-CARoleService -Path E:\SUBCA-pre-renewal -KeyOnly -Password (Read-Host -AsSecureString)
Backup-CARoleService -Path E:\SUBCA-pre-renewal -DatabaseOnly
reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration E:\SUBCA-pre-renewal\config.reg
certutil -CAInfoExpected result: three artefacts on a volume that is not this machine, and the authority reporting its current certificate. Note the CA version it prints, in the form of two numbers separated by a dot. The first is the certificate index and the second is the key index, and comparing that pair before and after is how you confirm afterwards that the renewal did what you intended rather than what you clicked.
Step 3. Renew the issuing authority, producing a request
In the certification authority console, right-click the authority, choose All Tasks and then Renew CA Certificate. It offers to stop the service, which it must; accept. It then asks whether to generate a new public and private key pair. Answer no.
certutil -shutdown
# reuse the existing key
certutil -renewCert ReuseKeys
# omitting ReuseKeys renews with a NEW key pair. The argument is the whole decision.
Get-ChildItem C:\ -Filter "*.req" | Select-Object FullName, LastWriteTimeExpected result: a request file written to the system volume, named for the authority. Move it to the transfer medium.
The failure mode that hits this build specifically. If you answer no to the new key pair question and are never asked where to save the request, and the service simply restarts and the renewal has failed, the cause is a key specification mismatch. An authority using a key storage provider expects that property to be zero, and when it is two instead, an existing-key renewal cannot complete. This build uses RSA#Microsoft Software Key Storage Provider, so it is squarely in the affected population. The symptom is distinctive because nothing errors visibly: you get no prompt, no file, and a running service.
Discover that on the day of the renewal and it is an unpleasant surprise on a change window. Discover it two years earlier by rehearsing this procedure once, as [P 6.1] tells you to rehearse the revocation list procedure, and it is an afternoon.
Step 4. The root ceremony
Everything in this step is the same ceremony as the annual revocation list, with one extra action in the middle, and it is worth doing both while the machine is on rather than powering it up twice.
# on ROOTCA, after powering on and correcting the clock
w32tm /query /status
certutil -CAInfo
certreq -submit -config "ROOTCA\CatSnackJack Root CA" D:\RootCA\CSR\SUBCA-renewal.req D:\RootCA\Certs\SUBCA-renewal.cer
# take the request ID from the output if it did not issue immediately
certutil -resubmit <RequestId>
certutil -retrieve <RequestId> D:\RootCA\Certs\SUBCA-renewal.cer
# publish this year's revocation list while you are here
certutil -CRL
Get-ChildItem D:\RootCA\CDPExpected result: a signed certificate for the subordinate, and a fresh revocation list with a new next-update date. The clock check at the start is not ceremony for its own sake; a root that has been switched off for a year has drifted, and a certificate signed against a wrong clock is valid from a date that has not happened.
Carry back two files: the signed certificate and the revocation list. Then power the root off, and record the date you did it against the calendar entry.
Step 5. Install it, and confirm what changed
certutil -installCert C:\temp\SUBCA-renewal.cer
net start CertSvc
certutil -CAInfo
certutil -ca.cert C:\temp\subca-current.cer
certutil -dump C:\temp\subca-current.cer | Select-String "NotAfter|CA Version|Subject Key"Expected result: the service starts, and the certificate index in the CA version has advanced by one while the key index has not moved. That pair is the whole verification. If both numbers moved, you renewed with a new key, and you should stop and read the last section of this article before issuing anything.
The published files change name, and this is where the token discipline from [P 2.1] Build Sheet: The Offline Root CA pays off. The certificate file gains an index in parentheses, so what was SUBCA_CatSnackJack Issuing CA.crt becomes SUBCA_CatSnackJack Issuing CA(1).crt, because the filename carries a renewal suffix token rather than a literal. The revocation list filename does not change, because that suffix is tied to the key index and the key did not change. Two tokens, two different behaviours, and the difference is exactly the distinction the root build sheet explained.
The old certificate is not replaced. Both exist, both are valid, and everything issued under either chains correctly because the key is the same.
Step 6. Republish, everywhere it was published before
A renewed authority whose new certificate reaches nobody is a renewal that has not happened. There are three destinations and the third is the one people forget.
# the directory
certutil -dspublish -f C:\temp\subca-current.cer SubCA
certutil -viewstore -enterprise NTAuth
# the web servers, both of them, for the certificate and the root's new list
Copy-Item C:\temp\subca-current.cer \\PKI-WEB01\PKI\ -Force
Copy-Item C:\temp\subca-current.cer \\PKI-WEB02\PKI\ -Force
Copy-Item D:\RootCA\CDP\*.crl \\PKI-WEB01\PKI\ -Force
Copy-Item D:\RootCA\CDP\*.crl \\PKI-WEB02\PKI\ -Force
# and prove it from outside
certutil -URL "http://pki.catsnackjack.com/pki/"The third destination is the authority’s own published copy under the file name the certificates point at. Every certificate this authority has issued carries an authority information access URL built from the renewal suffix token, which means older certificates point at the file without an index and newer ones point at the file with one. Both files have to be served. Deleting the old one because it looks superseded breaks chain building for everything issued before today, which is most of the estate.
Step 7. The root’s own renewal, at year twelve
The same console action on the root, with no request to carry anywhere because a root signs its own. On a twenty-five year certificate this lands around 2038 and there is a reasonable chance nobody currently employed will perform it.
With the existing key, the behaviour is more forgiving than people expect. A new certificate file appears with an index appended and the old one remains. Everything already issued chains to the new certificate as well as the old, because the key is unchanged. And the new certificate keeps the same valid-from date as the original while carrying a later end date, so a root issued in 2026 and renewed in 2038 reads as valid from 2026 to 2063. The renewal extends the period rather than starting a fresh one.
With a new key it is a different exercise and the cross-certificates are the mechanism that makes it survivable. Two are generated automatically: the old key certifies the new certificate, and the new certificate certifies the old one in the reverse direction. Between them, chains build correctly in both directions while the new root certificate is still being distributed. A new revocation list is also created, carrying only what the new key signed, and its filename gains an index where an existing-key renewal would not have changed it.
Before the root goes back in the safe, confirm its revocation schedule survived its own renewal. This is the one check in this article with no second chance, because the next time anybody logs on to this machine is a year away at best. Renewing a root reads CAPolicy.inf again, since that file is consulted when a CA is renewed and not only when it is installed, so the schedule is live during this procedure in a way it never is during ordinary operation.
# on ROOTCA, still powered on, immediately after the renewal
certutil -getreg CA\CRLPeriod
certutil -getreg CA\CRLPeriodUnits
certutil -getreg CA\CRLOverlapPeriod
certutil -getreg CA\CRLOverlapUnits
# publish from the renewed certificate and read the dates back
certutil -CRL
certutil -dump D:\RootCA\CDP\*.crlExpected result: Weeks and 52 for the period, Weeks and 6 for the overlap, and a NextUpdate sitting roughly fifty-eight weeks out. That is the same arithmetic the root build sheet ran at installation and it should read the same here. If NextUpdate has collapsed to days or hours the schedule did not survive, and the list you are about to carry out of the room expires long before anybody intends to come back. Renew with a new key and the wildcard returns two lists, the old one and the new index; the new one is the one whose dates matter.
The overlap is the half worth watching. CAPolicy.inf understands CRLPeriod and CRLPeriodUnits, so those are values the renewal has an opinion about, and matching the file to the registry in [P 2.1] Build Sheet: The Offline Root CA is what keeps them from disagreeing. The file has no overlap key at all, so CRLOverlapPeriod and CRLOverlapUnits exist only in the registry and only because step 5 of that build sheet wrote them there. Whether the file’s period actually overwrites what is already in the registry is not worth taking on trust either way, and these four lines are how you learn it on the day rather than by reasoning about it beforehand.
Distribution afterwards is the ordinary trust distribution problem from [P 6] Operating a PKI, not a special case. Domain members receive the renewed root through policy. Everything else is on your list, and if that list has rotted since the build this is the moment you find out.
Do not remove the previous root certificate from clients afterwards. It costs nothing to leave it and it is still needed to validate signatures made while it was current, which for anything signed rather than merely authenticated can matter for years.
The end-to-end test
Two halves, and the second is the one that proves the renewal rather than the installation.
# first: a certificate issued after the renewal validates
certreq -new C:\temp\test.inf C:\temp\test.req
certreq -submit -config "SUBCA\CatSnackJack Issuing CA" C:\temp\test.req C:\temp\test.cer
certutil -verify -urlfetch C:\temp\test.cer
# second: a certificate issued BEFORE the renewal still validates
$old = Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.NotBefore -lt (Get-Date).AddDays(-1) -and $_.Issuer -like "*CatSnackJack Issuing CA*" } |
Select-Object -First 1
certutil -verify -urlfetch (Export-Certificate -Cert $old -FilePath C:\temp\pre.cer).FullNameExpected result: both verify with every revocation check succeeding, and the new certificate’s validity runs a full year rather than stopping short. A shortened end date on the first test means the renewal did not take and the authority is still working from its old certificate.
The second test is the one worth running from a machine that is not the authority, because it exercises the published files rather than the local copies, and the published files are what step 6 could have got wrong.
Rollback
An existing-key renewal has almost nothing to roll back, which is most of the reason to prefer it. The old certificate still exists, still validates, and the authority can be pointed back at it from the backup taken in step 2 if the new one turns out to be wrong.
A new-key renewal cannot be undone in any meaningful sense. The key exists, the cross-certificates exist, and certificates have been issued under it. If you got there by omitting an argument rather than by deciding to, stop before issuing anything, restore from the step 2 backup, and start again.
Completion checklist
A backup of the key, the database and the registry configuration exists on a volume that is not the authority, taken before anything changed. The renewal was performed with the existing key unless a stated reason required otherwise, and the CA version confirms it: certificate index advanced, key index unchanged. The root was powered on once, signed the request, published this year’s revocation list in the same session, and was powered off again. The renewed certificate is installed, the service is running, and a newly issued certificate runs its full validity rather than a shortened one. The new certificate is published to the directory and to both web servers, and the previously published file is still being served alongside it. A certificate issued before the renewal still validates from a machine that is not the authority. The maintenance calendar records the renewal as done, and carries the next one at half the new certificate’s life, with the hard date written next to it in the words somebody who has never done this will understand.
On-Prem PKI
‹ Previous: [P 6.1] Build Sheet: Trust Distribution, Backup, and the Maintenance Calendar
Next: [P 7] Where the On-Prem Estate Meets Cloud PKI ›
