How to debug missing enterprise root ca certificate?

10,418

Solution 1

A few things to check:

  • Has certificate autoenrollment been disabled on this client? Lack of autoenrollment would explain lack of import.
  • Is the certificate in the trusted roots store, just not in the enterprise trust container, due to the manual import? Check the Trusted Roots store for the computer account in certmgr.msc.
  • Has it maybe been imported then deleted for some reason? If it thinks it's been imported, then it won't import again; clear out the sub-keys under HKLM\Software\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache, then re-run autoenroll with certutil -pulse.

Solution 2

"I prefer to not use a group policy for simple distribution..."

Why not? That is exactly what GP was designed for - to distribute common settings/configuration to domain PCs. Just import the root cert to a GPO under Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities

Share:
10,418

Related videos on Youtube

Jonathan
Author by

Jonathan

By Day: Work as a DevOps Engineer at allcloud.io By Night: Drumming along, playing with smart devices

Updated on September 18, 2022

Comments

  • Jonathan
    Jonathan almost 2 years

    We have a openssl offline root CA with a Windows 2008 R2 AD-integrated SubCA.

    The Openssl Root CA was published to ldap CN=ROOTCANAME,CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=DOMAIN using certutil -dspublish -f root.cer RootCA

    Everything works ok, except for one thing. So far two clients (both XP) showed up which did not import the Root CA Cert to the trusted enterprise root certificate authorities store.

    On my working workstation, I get the following output:

    C:\>certutil -store -enterprise root
    402.203.0: 0x80070057 (WIN32: 87): ..CertCli Version
    ================ Certificate 0 ================
    Serial Number: f818516373f917e8
    Issuer: E=hostmaster@DOMAIN, CN=ROOTCA, O=Organisation, L=Location, S=State, C=DE
    Subject: E=hostmaster@DOMAIN, CN=ROOTCA, O=Organisation, L=Location, S=State, C=DE
    Signature matches Public Key
    Root Certificate: Subject matches Issuer
    Cert Hash(sha1): a6 ed 80 59 04 80 c7 1f 4e cb aa e1 8d e7 77 4a 2a 98 43 97
    No key provider information
    No stored keyset property
    CertUtil: -store command completed successfully.
    

    On a workstation which does not import the root CA cert. The output is:

    C:\>certutil -store -enterprise root
    CertUtil: -store command completed successfully.
    

    Even after importing the certificate manually. This particular machine was even rejoined to the domain. To no avail.

    Questions now are:

    • where to look for errors or debugging information?
    • how to identify machines with this problem?
    • how to manually trigger the import of ldap certificates?
    • Is this the right approach to distribute the root ca cert? I prefer to not use a group policy for simple distribution but on the other side can not find much information regarding the ldap distribution process.
    • Jonathan
      Jonathan over 12 years
      No, looks pretty standard to me. But both Clients get the same Policies. I just verified that. One just does not seem to load the enterprise root settings from the ldap tree but I don't know why and have no clue how to debug this process.
  • Jonathan
    Jonathan over 12 years
    As I understood, the ldap pki tree is the preferred way of setting up a enterprise ca. Why would Microsoft add the certificates to the ldap pki tree themself if the preferred way where using GPOs? See technet.microsoft.com/en-us/library/cc737834(WS.10).aspx for a checklist for setting up a offline root ca which just uses certutil -dspublish -f root.cer RootCA and no GPOs. So it just seems not the best way.
  • Jonathan
    Jonathan over 12 years
    With autoenrollment disabled you mean the gpo setting. No not disabled. Cert is in trusted root store. (On both PCs) Definitly not deleted after import.
  • ravi yarlagadda
    ravi yarlagadda over 12 years
    So it's in the trusted roots? Wasn't the issue that it wasn't being trusted?
  • Jonathan
    Jonathan over 12 years
    It is in trusted roots. The issue was, that it was not imported automatically to trusted enterprise roots on so far two out of 1000 pcs. Most PCs have simpliy imported it. Two definetly didn't. And I want to know why, how to fix it and most importend, is it two or is the dark number two hundered PCs.
  • Jonathan
    Jonathan over 11 years
    The cleanup of the registry key did help on one PC. Had to copy certutil to this PC for it to work. Would a cleanup and reboot work too?