Home > Security, Windows > Problem with enterprise certificate distribution

Problem with enterprise certificate distribution

Once upon the time I played with enterprise certification authority at one of our customers. I’ve created new certificate for certification authority. And then problem begun.

In default setup all certificates from enterprise certification authorities, that are in active directory domain, are propagated to clients. All certificates in AD are stored at NTAuth store, which represents following LDAP path:

CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=Domain,DC=local

All of these certificates are copied during updating GPO policies to computer. One of those CREs are responsible for this job (we will discover which one later on). These certificates are stored locally in registry key

HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\EnterpriseCertificates\\NTAuth\\Certificates

This is normal behaviour. But when I was at the customer none of this was working. Registry key mentioned above was empty and we had problem when we wanted to request for a new personal certificate. When I checked NTAuth store in domain I could see all certificates valid. So problem was that computers didn’t copy certificates from domain NTAuth to local registry keys.

You can import certificates into registry key using command:

certutil -enterprise -addstore NTAuth CA.cer

where CA.cer is certificate for CA to be inserted into registries.

After couple minutes of looking for help at Internet I found out little message on official KB site which states:

This registry key should be automatically updated to reflect the certificates that are published to the NTAuth store in the Active Directory configuration container. This behavior occurs when Group Policy settings are updated and when the client-side extension that is responsible for autoenrollment executes. In certain scenarios, such as Active Directory replication latency or when the Do not enroll certificates automatically policy setting is enabled, the registry is not updated.

So what that means is if you disable autoenrollment on client machines, they will not update their registry key with certificates from NTAuth store. And of course client did have autoenrollment turned off.

I don’t see any logic behind this. Autoenrollment doesn’t have anything with updating NTAuth store. One friend, Ondrej Ševeček, told me that those two different things can be handled by one DLL library and therefore when you disable one thing, second one is not working either.

Thank you Microsoft for a hard time at the customer site 🙂

  1. Mary
    August 21st, 2012 at 11:27 | #1

    Thanks!
    You saved me some time on troubleshooting very messy PKI GPO settings (over 20 GPOs overlapping) configured at customer site.
    For years now I’ve administered couple of MS PKI environments, and am costumed to surprises, but this would be real time-consuming if not for you.

  1. No trackbacks yet.