Certificate Revocation in conjunction with GPO Autoenrollment
- Given:
We have an old Enterprise CA and a new Enterprise CA. The old CA used a 4096 bit key for the Root and Issuing CA and IBM Websphere doesn't support it so we had to redo our PKI with 2048 bit key lengths.
250 certs were issued from the old CA. We need to decommision the old CA and issue from the new CA going forward.
Certificate Templates are only published via the new CA.
We have GPO Autoenrollment with all options checked for the domain in question.
The Template has rights for Autoenrollment and it works.
If we revoke a Computer Certificate and publish a new CRL from the old CA we noticed that nothing happens with the computer cert on the local computer store. We rebooted the computer, tried a gpupdate -force, yet the old certificate remained.
What mechanism do we need to trigger to get the old issued cert out of the local computer cert store and get the Autoenrollment to put in a new cert?
In playing around, we deleted the old cert from the local computer, rebooted it, and Autoenrollment did install a new computer cert from the new CA. However, in our minds it seems we should be able to revoke the old computer certs, publsih a new CRL, and Autoenrollment should take care of deleting the old cert from the local store and reissuing a new cert from the new CA.
What am I missing?
Answers
- You need to create a new certificate template (v2) that supercedes the old certificate template
This will issue the new certificate, and archive the previously issued certificate.
The new certificate template should be issued to the same group with the same Read, Enroll and Autoenroll permissions
Brian- Marked As Answer bythoar500 Wednesday, November 04, 2009 3:35 PM
V1, V2, and V3 templates are all defined by RFCs. The version number you see in the Certificates Template console are a Microsoft construct and don't relate to the RFC defined versions, but can be used to track modifications to certificate templates. If you make a change to a certificate template you'll see that the version number for that template is incremented. The easiest way to determine whether you're dealing with V1, V2, or V3 templates is to sort the console display on the Minimum Supported CAs column:Mr. Komar, thanks for the response. Our Premier Field Engineer recommends your book and speaks of it highly. I saw that it was 592 pages and wondered if you made a shorter book called PKI for Dummies.
All kidding aside, our templates were Windows 2003 compatible templates created by a Windows 2008 Enterprise CA. They create V3 certificates and the version of the template says 100.5, according to the CA. What do you mean by v2 templates?
We were happy to note the templates existed in AD and when we stood up our new PKI, pleased with the fact that all we had to do was remove them from the old CA and issue them through the new CA, which is also a Windows 2008 Enterprise CA.
But as you mention above we still need to create new V2 templates that supercede the old templates. Does this mean that we just need to duplicate the existing template, give it a new name, then add the old template to the Superceded list of the new template, then issue the new template and remove the old template from the "Issued Templates"list?
Windows 2000 - V1
Windows Server 2003 Enterprise - V2
Windows Server 2008 Enterprise - V3
The answer to your final question is yes, that's what you need to do.
Paul Adare CTO IdentIT Inc. ILM MVP- Marked As Answer bythoar500 Wednesday, November 04, 2009 3:36 PM
All Replies
- You need to create a new certificate template (v2) that supercedes the old certificate template
This will issue the new certificate, and archive the previously issued certificate.
The new certificate template should be issued to the same group with the same Read, Enroll and Autoenroll permissions
Brian- Marked As Answer bythoar500 Wednesday, November 04, 2009 3:35 PM
- Wouldn't the reenroll option on the old template speed things up or will the new template not kick in?
Mr. Komar, thanks for the response. Our Premier Field Engineer recommends your book and speaks of it highly. I saw that it was 592 pages and wondered if you made a shorter book called PKI for Dummies.
All kidding aside, our templates were Windows 2003 compatible templates created by a Windows 2008 Enterprise CA. They create V3 certificates and the version of the template says 100.5, according to the CA. What do you mean by v2 templates?
We were happy to note the templates existed in AD and when we stood up our new PKI, pleased with the fact that all we had to do was remove them from the old CA and issue them through the new CA, which is also a Windows 2008 Enterprise CA.
But as you mention above we still need to create new V2 templates that supercede the old templates. Does this mean that we just need to duplicate the existing template, give it a new name, then add the old template to the Superceded list of the new template, then issue the new template and remove the old template from the "Issued Templates"list?
V1, V2, and V3 templates are all defined by RFCs. The version number you see in the Certificates Template console are a Microsoft construct and don't relate to the RFC defined versions, but can be used to track modifications to certificate templates. If you make a change to a certificate template you'll see that the version number for that template is incremented. The easiest way to determine whether you're dealing with V1, V2, or V3 templates is to sort the console display on the Minimum Supported CAs column:Mr. Komar, thanks for the response. Our Premier Field Engineer recommends your book and speaks of it highly. I saw that it was 592 pages and wondered if you made a shorter book called PKI for Dummies.
All kidding aside, our templates were Windows 2003 compatible templates created by a Windows 2008 Enterprise CA. They create V3 certificates and the version of the template says 100.5, according to the CA. What do you mean by v2 templates?
We were happy to note the templates existed in AD and when we stood up our new PKI, pleased with the fact that all we had to do was remove them from the old CA and issue them through the new CA, which is also a Windows 2008 Enterprise CA.
But as you mention above we still need to create new V2 templates that supercede the old templates. Does this mean that we just need to duplicate the existing template, give it a new name, then add the old template to the Superceded list of the new template, then issue the new template and remove the old template from the "Issued Templates"list?
Windows 2000 - V1
Windows Server 2003 Enterprise - V2
Windows Server 2008 Enterprise - V3
The answer to your final question is yes, that's what you need to do.
Paul Adare CTO IdentIT Inc. ILM MVP- Marked As Answer bythoar500 Wednesday, November 04, 2009 3:36 PM
Wow, superceding templates in conjunction with Autoenrollment doesn't waste any time. It is issuing computer certs based on our v2 template. I'm not sure about its criteria for issuance...my guess is anything with a cert based on the old template is getting replaced with a cert based off the new template.
After this completes I will tackle user certs. We have yet to turn on the GPO for users (Allow Autoenrollment on the User Template) as we still need to decide if we issue to all users per domain, or do we create groups (VPN Users, Wireless Users, etc) and then have the GPO work according to group.
Thanks again for your help in this.I have a philosophical question on this subject. Does Autoenrollment understand the different types of revocation and act accordingly?
- Autoenrollment never performs revocation.
Autoenrollment, will, at best, mark a certificate as archived after the renewal process (if renewing).
If you want to revoke a certificate replaced by autoenrollment, you need to manually revoke it.
Because you are planning to decommission a previous CA, the easier step is to revoke the CA (after the last certificate is replaced from the new CA by autoenrollment and superceding)
Brian - What I meant was, if I manually revoke a cert, lets say for Security concern, yet that machine remains in our domain, will Autoenrollment know not to issue another valid cert because of the reason for revocation? Its a far fetched situation, for sure. If we are revoking a machine cert we would likely delete it from the domain as well.
This is all a side note to the discussion on this forum. It was just a thought that popped into mind when discussing PKI...
Creating the new template and putting the old template in the "superceded" list fixed our issue above. Now that all of the computer certs have been issued based off the new template we can proceed with revoking all of the old certs.
We were thinking of the process backwards. We thought, revoke the certs, and let Autoenrollment issue new ones. But as you suggested, supercede the old template with a new one will trigger new certs to get issued, then revoke the old ones. - No, this isn't how autoenrollment works.
Paul Adare CTO IdentIT Inc. ILM MVP Just properly decommission the old root CA. This will remove it as a trusted root (and NTAuth) CA. the certificate is no longer valid then
Also revoking it would be pointless, since you are decommissioning the CA that has to be available to publish updated CRLs <G>.
You are creating a chicken and the egg issue
Brian- You are creating a chicken and the egg issue
is there any issue? If root CA certificate is revoked, it will unable to publish CRL's :) so there is no mechanisms to create this issue :)
http://www.sysadmins.lv - Actually, you cannot revoke a root CA certificate (not exposed as an issued certificate of the root CA).
Check it out for yourself. You can, as I stated earlier, just decommission the root CA.
Another good reason not to deploy certificates to users/computers from a root CA
Brian I'm able to revoke Root CA cert, not through certsrv.msc, but using PowerShell :). I have posted about behaviour at my blog (in Russian, so if you're interesting in that you may use translator):
http://www.sysadmins.lv/PermaLink,guid,b3521905-4696-4e23-a2d8-1f6fafbfa030.aspx
this message appears in CA DB:
Request Status Code: 0x0 (WIN32: 0) -- The operation completed successfully.
Request Disposition: 0xf (15) -- CA Cert
Request Disposition Message: "Revoked by ADATUM\Administrator"
when certifiate is revoked and certificates services are not restarted you may try to publish new CRL's. You will see appropriate message that publish CRL signal was sent to CA in Security eventlog (if Auditing is configured). However CRL files aren't updated. And there is strange behavior. Even CA knows that his certificate is revoked (Application eventlog and General tab in CA properties say us that certificate is revoked), it still may issue new certs. You may submit new requests, enroll via MMC, etc. Certificates will be issued until certificate service will be stopped. When certsvc is stopped it will never started again.
> Another good reason not to deploy certificates to users/computers from a root CA
that's right, because some time after root cert revocation Root CA may issue new certificates, but cannot publish new CRL's.
http://www.sysadmins.lv- I'm all for breaking the cycle of eggs turning into more chickens...and chickens laying more eggs...I just want to be thorough and clean out the roost as best as possible.
We want to get rid of all remants of the old PKI from AD. Here is the article we are referring to: http://support.microsoft.com/kb/889250
I think using PKIView.msc to do much of the work should be on top of the article and command line stuff should be on the bottom but that is my opinion.
The first thing it says to do is revoke all of the outstanding certs issued by the old Issuing CA and publish a CRL that lasts longer than the CA cert itself. That is what sent me down this path.
So much to learn... So if we maunaully revoke a cert for any reason Autoenrollment won't reissue?
