none
Multiple Windows 2012 R2 subordinate issuing CAs, how do I make one preferred issuing CA? RRS feed

  • Question

  • Hello,

    A while back I posted a question on another discussion thread regarding re-issuing new root CA with FQDN - http://social.technet.microsoft.com/Forums/windowsserver/en-US/c3d88348-f4e6-456f-b319-e60a38febdcb/possible-to-reissue-rootca-certificate-to-change-a-few-settings-in-capolicyinf?forum=winserversecurity#858918e4-f8ac-42b8-9e30-0c01d6fabbc8

    Needless to say, I'm not a PKI expert and there was a concern with our two two-tier hierarchy PKI servers having shortnames in the certificates instead of FQDNs. Granted, the root CA is NOT domain-joined and wouldn't have had a FQDN to begin with because its not part of Active Directory but I ended up creating new pair of servers for a new two-tier hierarchy anyways. 

    So now, I have two offline root CAs in a workgroup and two domain-joined issuing CAs. I have already added the additional new root CA's certificate to AD and a quick glance at "PKIVIEW.MSC" shows an "OK" status - no errors. I logged on to one of our domain controllers, opened the Local Computer CERTIFICATE store and saw under PERSONAL that there's 4 certs with the DCs name all issued by the first issuing CA.

    How do I make the new issuing CA the preferred issuing CA? The plan is to decommission the current (first) issuing CA and delete he current (first) root CA since I create a whole new pair. 


    • Edited by Rock07 Friday, August 8, 2014 7:56 PM correction
    Friday, August 8, 2014 7:55 PM

Answers

  • There is no such thing as a "preferred issuing CA". I guess you would consider the "preferred" one the one issuing certificates to DCs "in the first place", correct?

    Issuance of certificates is governed by: Permissions on templates, publication of templates to CAs, permissions on the CA (Enrollment Object, to be configured in certsrv.msc, Security) and (W2K12 only) site-awareness of the CA.

    If the same template is published to 4 CAs - as it happens per default if you set up CAs without removing the default templates - than the DCs will pick "any CA". There might be some order based on names of the CAs but there is not published, documented way to assign priorities to CAs - other than via those permissions mentioned before.

    So you should remove all templates you don't want to issue from particular CAs from those CAs, and only keep the DC certificate template at the remaining CA. Then re-enroll all DCs by deleting the existing certificates (certutil -dcinfo deleteall) or renewing the existing ones (right-click template, re-enroll all certificate holders - only works with Domain Controller Authentication or Kerb. Authentication, not with Domain Controller).

    Removing templates from the CA to be retired and publishing them to a new CA instead is the recommended way to migrate PKI clients to a new CA.

    Elke

    • Marked as answer by Rock07 Monday, August 11, 2014 10:51 PM
    Saturday, August 9, 2014 7:29 AM
  • Re 1: Yes, delete the templates from the CA which you do not want to issue those in certsrv.msc. This is just something like a hyperlink: The templates as such reside in AD (Don't delete them with certtmpl.msc or AD Sites and Services!) - so you just remote point to these templates from the old CA.

    Re 2: Yes, they will try to enroll with "any" CA for DC certificates. If there is just a single CA there is no ambiguity. A PKI client (such as a DC) makes LDAP queries to gather information about the templates it has Enroll permissions to and the CA(s) that offer those.

    DC will enroll for Domain Controller Authentication (built-in automatic process) or DC Authentication if an Autoenrollment policy is enabled. Note that certutil -dcinfo deleteall needs to be run in any domain, Re-Enroll all certificates holders might be quicker (for DC Authentication only)

    BTW do you actually use the DC certificates? Unless you do smartcard logon or LDAPs against DCs these certificates are not really utilized.

    Elke

    Monday, August 11, 2014 8:07 PM
  • Yes, it is sufficient to do it at some machine in the domain, as a domain admin. It is like "remotely wiping" all the DC certificates from the stores of the DCs in that domain.

    Monday, August 11, 2014 10:57 PM
  • Auto-enrollment should be triggered by the next GPO refresh so you could run gpupdate /force so speed the re-enrollment up at the local DC. 

    Which template are you using / plan to enroll now? Domain Controller or Domain Controller Authentication? Only the second one needs an Autoenrollment GPO, the first one uses a hard-coded mechanism (Automated Cert. Request Settings via registry key).

    If both templates are published DCs would go for DC Authn as this supersedes the Domain Controller templates.

    If your DCs have Domain Controller Authentication certificates now you could also use the second method I have described above which does not leave the DC without a certificate for any time: Right-click the existing certificate and select Re-Enroll all certificate holders.

    If you haven't used Domain Controller Authentication with the old CA before - when you just publish this template to the new CA and have the AE GPO in place then DCs should enroll for it even if you do not delete existing Domain Controller certificates.

    Some things to check to troubleshoot (auto-)enrollment at the DCs - can be done before deleting certificates:

    • Do all DCs in the forest have Read, Enroll permissions - and Autoenroll permissions for DC AuthnN.
    • If you try to enroll for a certificates from the new CA manually with the MMC at one DC - does that work? If not - indicating missing permissions or template not replicated yet, templates not published, new CA not visible in AD as Enrollment Object not present... (The latter "should not happen")
    • Does enrollment of some other certificate from the new CA work - e.g. a user certificate like Authenticated Session (just to rule out issues with the CA rather than the templates).
    • Has the AE policy been applied successfully (DC AuthnN only) - see registry to check here.

    Edit as you said you use LDAPs: If you would like to switch from Domain Controller to Domain Controller Authentication. I'd recommend using a copy of Domain Controller Authenticationthat has the Subject Name populated. Third-party LDAP browsers sometimes cannot deal with the empty SN in Domain Controller Authentication. If you have used Domain Controller Authenticationbefore with your LDAP apps. you don't have to worry.

    Elke




    • Edited by Elke Stangl Thursday, August 14, 2014 7:35 AM Edited info on LDAPs and using either template
    • Marked as answer by Amy Wang_Moderator Friday, September 12, 2014 1:35 AM
    Thursday, August 14, 2014 7:27 AM

All replies

  • There is no such thing as a "preferred issuing CA". I guess you would consider the "preferred" one the one issuing certificates to DCs "in the first place", correct?

    Issuance of certificates is governed by: Permissions on templates, publication of templates to CAs, permissions on the CA (Enrollment Object, to be configured in certsrv.msc, Security) and (W2K12 only) site-awareness of the CA.

    If the same template is published to 4 CAs - as it happens per default if you set up CAs without removing the default templates - than the DCs will pick "any CA". There might be some order based on names of the CAs but there is not published, documented way to assign priorities to CAs - other than via those permissions mentioned before.

    So you should remove all templates you don't want to issue from particular CAs from those CAs, and only keep the DC certificate template at the remaining CA. Then re-enroll all DCs by deleting the existing certificates (certutil -dcinfo deleteall) or renewing the existing ones (right-click template, re-enroll all certificate holders - only works with Domain Controller Authentication or Kerb. Authentication, not with Domain Controller).

    Removing templates from the CA to be retired and publishing them to a new CA instead is the recommended way to migrate PKI clients to a new CA.

    Elke

    • Marked as answer by Rock07 Monday, August 11, 2014 10:51 PM
    Saturday, August 9, 2014 7:29 AM
  • Elke Stangl, thank you so much for your response and feedback. I really appreciate it.

    So, just to reiterate your proposed plan of action:

    1. To make the newly created issuing CA the "preferred" one, delete all templates (including default templates) from the current "preferred" (or original) CA? I'm looking at the "Certificate Templates" on the CA MMC on both issuing CAs and I do see a disparity between the two - some custom templates do not appear on both sides. But, I do see the default templates as common on both issuing CAs. 

    I'm assuming that any custom templates that were created on the "current preferred" issuing CA will need to be re-created on the newly created issuing CA, correct? We only have 3 custom templates. 

    2. If I do a "certutil -dcinfo deleteall" on all my DCs, will they re-enroll with newly created issuing CA? I'm assuming the DCs will contact the issuing CA who still has templates (after I deleted all templates from the original current one). 

    Thanks again!

    Monday, August 11, 2014 7:33 PM
  • Re 1: Yes, delete the templates from the CA which you do not want to issue those in certsrv.msc. This is just something like a hyperlink: The templates as such reside in AD (Don't delete them with certtmpl.msc or AD Sites and Services!) - so you just remote point to these templates from the old CA.

    Re 2: Yes, they will try to enroll with "any" CA for DC certificates. If there is just a single CA there is no ambiguity. A PKI client (such as a DC) makes LDAP queries to gather information about the templates it has Enroll permissions to and the CA(s) that offer those.

    DC will enroll for Domain Controller Authentication (built-in automatic process) or DC Authentication if an Autoenrollment policy is enabled. Note that certutil -dcinfo deleteall needs to be run in any domain, Re-Enroll all certificates holders might be quicker (for DC Authentication only)

    BTW do you actually use the DC certificates? Unless you do smartcard logon or LDAPs against DCs these certificates are not really utilized.

    Elke

    Monday, August 11, 2014 8:07 PM
  • Elke

    We do have applications that do LDAPs against DCs but not sure if they've been configured to do via SSL 443. If so, I know we'll have to renew those certs.

    So, the "certutil -dcinfo deleteall" just needs to be executed from a DC (or domain-joined workstation with elevated privledges) and not every DC, correct? 

    Thanks again!

    Monday, August 11, 2014 10:50 PM
  • Yes, it is sufficient to do it at some machine in the domain, as a domain admin. It is like "remotely wiping" all the DC certificates from the stores of the DCs in that domain.

    Monday, August 11, 2014 10:57 PM
  • Elke

    Before I executed "certutil dcinfo deleteall", my understanding is that command would delete all certificate info from all my DCs so was told by my manager to test DC auto-reenrollment with the new issuing CA. We have 6 AD sites and 12 DCs total. So, as a test to see how long or when a domain controller would re-enroll, I backed up and then deleted all the certificates in the Personal store of the domain controllers in my local site. I did a manual sync of Active Directory, went back to the Personal store of my local DCs and nothing.

    Of course, local application servers in the site started complaining of authentication issues so I restored the previous certificates.

    I checked the DEFAULT DOMAIN CONTROLLER policy and AUTO ENROLLMENT is configured and set. I believe that group policy setting is by default, hence, DEFAULT DOMAIN CONTROLLER policy. So, is it just a matter of allowing AD propagate that change and giving the DC enough time to auto enroll with the new issuing CA? I had already removed all templates from the original issuing CA.

    Thursday, August 14, 2014 2:30 AM
  • Auto-enrollment should be triggered by the next GPO refresh so you could run gpupdate /force so speed the re-enrollment up at the local DC. 

    Which template are you using / plan to enroll now? Domain Controller or Domain Controller Authentication? Only the second one needs an Autoenrollment GPO, the first one uses a hard-coded mechanism (Automated Cert. Request Settings via registry key).

    If both templates are published DCs would go for DC Authn as this supersedes the Domain Controller templates.

    If your DCs have Domain Controller Authentication certificates now you could also use the second method I have described above which does not leave the DC without a certificate for any time: Right-click the existing certificate and select Re-Enroll all certificate holders.

    If you haven't used Domain Controller Authentication with the old CA before - when you just publish this template to the new CA and have the AE GPO in place then DCs should enroll for it even if you do not delete existing Domain Controller certificates.

    Some things to check to troubleshoot (auto-)enrollment at the DCs - can be done before deleting certificates:

    • Do all DCs in the forest have Read, Enroll permissions - and Autoenroll permissions for DC AuthnN.
    • If you try to enroll for a certificates from the new CA manually with the MMC at one DC - does that work? If not - indicating missing permissions or template not replicated yet, templates not published, new CA not visible in AD as Enrollment Object not present... (The latter "should not happen")
    • Does enrollment of some other certificate from the new CA work - e.g. a user certificate like Authenticated Session (just to rule out issues with the CA rather than the templates).
    • Has the AE policy been applied successfully (DC AuthnN only) - see registry to check here.

    Edit as you said you use LDAPs: If you would like to switch from Domain Controller to Domain Controller Authentication. I'd recommend using a copy of Domain Controller Authenticationthat has the Subject Name populated. Third-party LDAP browsers sometimes cannot deal with the empty SN in Domain Controller Authentication. If you have used Domain Controller Authenticationbefore with your LDAP apps. you don't have to worry.

    Elke




    • Edited by Elke Stangl Thursday, August 14, 2014 7:35 AM Edited info on LDAPs and using either template
    • Marked as answer by Amy Wang_Moderator Friday, September 12, 2014 1:35 AM
    Thursday, August 14, 2014 7:27 AM
  • Elke,

    I figured out the auto-enroll issue with my domain controllers. On the newly-built issuing CA, I had set the issuing CA with, "SET THE CERTIFICATE REQUEST STATUS TO PENDING. ADMINISTRATOR MUST EXPLICITLY ISSUE THE CERTIFICATE". This setting was one of the post actions I did after I finished configuring the new issuing CA. We have a renewed initiative to be more "security-centric" and implemented that setting. I looked at the issuing CA "PENDING REQUESTS" and low and behold - all of the certificate requests from the two domain controllers in my site! For now, I reverted to the original default setting and the DCs can now auto-enroll. 

    But, before I can delete all certificate info from all our DCs in the forest, we discovered that certain applications need the new root certificate imported or else authentication will break and lock us out. The test I conducted with my local site DCs illuminated this fact when our admins couldn't login to our VMware Vcenter server. Also, other web-based applications were affected too. I've already imported the new root cert in Active Directory but most of web-based apps (like Vcenter) are linux based and require an import of the root certificate. 

    Friday, August 15, 2014 3:19 PM
  • Thanks for your update!

    Auto-enrollment works on principle with requiring approval - it's just not auto-issuance but a three-step process: You could on principle keep the "pending setting" and approve the certificates for the DCs manually. They will retrieve the issued certificates then during the next GPO refresh.

    When the DCs can now auto-enroll a new certificate the old certificate will then be archived and the DCs will use the new one for LDAPs - so you need to have all the dependent apps. ready for the new certificate chain.

    As you have so many non-Windows apps. validating the chain I better recommend once to use either

    • the template Domain Controller or
    • a copy of Domain Controller Authentication that has a non-empty Subject CN.

    It is common that such applications don't work with the default Domain Controller Authentication certificates that have empty Subject Names.

    Friday, August 15, 2014 3:55 PM
  • Thanks Elke!

    On another but related note, one of my colleagues noticed that the new issuing CA website isn't connecting via TLS 1.2. The old issuing CA site does connect via TLS 1.2. I can verify that the new issuing CA has the neccessary reg keys and TLS 1.2 is enabled but complains that, "An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

    If I enable SSL 3.0 or TLS 1.1 in the registry, I can connect via those protocols but it won't connect via TLS 1.2. Both the old issuing CA and new issuing CA are running Windows 2012 R2. Another point of interest is that the old issuing CA, doesn't have those reg keys in the registry and yet I can connect to its "certsrv" site via TLS 1.2. 

    Any thoughts on this? I know this is a bit out of the scope of this discussion thread. Or I can just create another discussion thread specifically on this. Thanks!



    • Edited by Rock07 Wednesday, August 20, 2014 6:36 PM correction
    Wednesday, August 20, 2014 6:28 PM
  • Elke

    Disregard my last question on TLS. Seems that there is an issue with generating certs with the sha512 hash that isn't supported by TLS 1.2 :(

    http://blog.datacenterfromhell.net/2014/02/iis-web-server-does-not-support-tls-12.html

    I verified that the cert used on the old issuing CA has the signature hash algorithm sha1 and the new issuing ca SSL cert has sha512. Is there a way to sign certificates with a different hash? When I installed the issuing CA, I choose sha512 for its hash algorithm. Is there a way to change that without re-installing the issuing CA? 

    Would I be able to follow this for the 2012 R2 new issuing CA:

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/91572fee-b455-4495-a298-43f30792357e/is-it-possible-to-change-the-hash-algorithm-when-i-renew-the-root-ca?forum=winserversecurity

    • Edited by Rock07 Wednesday, August 20, 2014 7:39 PM Correction
    Wednesday, August 20, 2014 7:28 PM
  • And the plot thickens:

    SHA512 is disabled in Windows when you use TLS 1.2 - http://support.microsoft.com/kb/2973337/en-us

    But unfortunately, Microsoft has removed the update rollup because of bugs in the update:

    http://support.microsoft.com/kb/2975719/en-us

    So, I think we'll stick with TLS 1.1 until Microsoft fixes those bugs in the update. I would hate to do un-neccessary work in reverting back to SHA1. 


    • Edited by Rock07 Wednesday, August 20, 2014 8:18 PM correction
    Wednesday, August 20, 2014 8:06 PM
  • Thanks - I just uninstalled that update right now because of bluescreens :-)

    Just for completeness - as you ask: I choose sha512 for its hash algorithm. Is there a way to change that without re-installing the issuing CA?

    On principle yes - there is a registry key that determines the hash algorithm the CA uses (CSP/CNGHashAlgorithm, CertSvc service config).

    Changing it and restarting the CA would make it sign all certificates and CRLs issued in the future with another algorithm. Changing the algorithm used with the CA certificate would require renewing it. So with a two-tier hierarchy you would have to renew both.

    Friday, August 22, 2014 8:41 AM