As part of joining PKI Solutions, several blog posts from my old site are re-posted here for visibility and thoroughness.
Hello folks! Today I want to explain in details about Active Directory containers related to ADCS (Active Directory Certificate Services), their purposes and how they work.
All ADCS related containers are stored in configuration naming context under Public Key Services container:
CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain}
Since Public Key Services container is stored in configuration naming context, any it’s content is replicated between all domain controllers in the current forest (not only current domain) and are available to any client in the forest. This means that there is no way to limit PKI containers only to specific domain or domains.
Here is a screenshot from ADSIEdit.msc tool:
Under Public Key Services container you find the following subcontainers:
and the following entry (not a container):
Sections below describe the purpose of each container.
This container is used to store intermediate CA certificates and cross-certificates. This container may contain entries of certificateAuthority type. CA certificates are written to cACertificate attribute and cross-certificates are written to crossCertificatePair attribute.
When you install new Enterprise CA, it’s certificate is automatically installed to AIA container.
you can programmatically install CA certificate to this container by running the following certutil.exe command:
certutil –dspublish –f <PathToCertFile.cer> SubCA
Replace <PathToCertFile.cer> with actual path and certificate name file.
All certificates from this container are propagated to each client as a part of group policy processing to client’s Intermediate Certification Authorities container.
This container is used to store certificate revocation lists (CRL). To differentiate CRLs a separate container is created for each CA. Typically CA host NetBIOS name is used. For example, if CA server runs on a computer ca01.company.com, the following path is created for that CA:
Schedule a DemoCN=ca01, CN=CDP, CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain}
And this container may contain records of cRLDistributionPoint type. Base CRL is written to certificateRevocationList attribute. Delta CRLs (multiple delta CRLs are allowed) are written to deltaRevocationList attribute.
When you install new Enterprise CA, it automatically publishes first CRLs to CDP container.
you can programmatically install certificate revocation list to this container by running the following certutil.exe command:
certutil –dspublish –f
Replace with actual path and certificate name file. And replace with required name. Usually subcontainer name is CA host short (NetBIOS) name.
CRLs from CDP containers are NOT propagated to clients and is used only when a certificate refers to a particular cRLDistributionPoint entry in CDP container.
This container contains enterprise certificate templates used by Enterprise CAs. You should not edit templates directly. Consider to use Certificate Templates (certtmpl.msc) MMC snap-in for template management.
This container is used to store trusted root certificates. This container may contain entries of certificateAuthority type. CA certificates are written to cACertificate attribute.
When you install Enterprise Root CA, it’s certificate is automatically installed to Certification Authority container.
you can programmatically install Root CA certificate to this container by running the following certutil.exe command:
certutil –dspublish –f <PathToCertFile.cer> RootCA
Replace <PathToCertFile.cer> with actual path and certificate name file. Note that a copy of root CA certificate is also installed in AIA container too.
All certificates from this container are propagated to each client as a part of group policy processing to client’s Trusted Root Certification Authorities container.
This container is used to store Enterprise CA objects. Clients use this container to locate Enterprise CAs in the forest.
When you install new Enterprise CA, a new record in the Enrollment Services container is created.
All certificates from this container are propagated to each client as a part of group policy processing to client’s Intermediate Certification Authorities container. Also, this container is enumerated during certificate enrollment process.
This container is used to store key recovery agent certificates for each Enterprise CA. When Enterprise CA issues a certificate based on Key Recovery Agent template, it automatically adds it to a corresponding entry. If this is first KRA certificate, CA creates a record for itself and writes KRA certificate to userCertificate attribute.
Certificates from KRA container are exposed only when you assign new key recovery agent to CA server.
This container is used to store object identifiers (OID) registered in enterprise. OID container can hold object identifier definitions for custom Application Policies, Issuance (Certificate) Policies and certificate templates. When client is a member of the Active Directory forest, it uses OID container to resolve object identifiers along with local OID database.
New OIDs should be registered via Certificate Templates (certtmpl.msc) MMC snap-in by adding new Application or Issuance (Certificate) Policy in certificate template Extension tab.
Alternatively, you can use PowerShell PKI module which contains commands to add or remove OID from Active Directory: Get-ObjectIdentifierEx, Register-ObjectIdentifier and Unregister-ObjectIdentifier.
This entry is used to store certificates for CAs that are eligible to issue smart card logon certificates and perform client private key archival in CA database.
you can programmatically install CA certificate to this container by running the following certutil.exe command:
certutil –dspublish –f <PathToCertFile.cer> NTAuthCA
Replace <PathToCertFile.cer> with actual path and certificate name file.
When you install new Enterprise CA, its certificate is added to NTAuthCertificates entry. Note that a copy of CA certificate is also installed in AIA container as well.
All certificates from this container are propagated to each client as a part of group policy processing to client’s Intermediate Certification Authorities container.
Although, ADSIEdit.msc allows you to view and edit extended details of the Public Key Services container, it is not very user-friendly and cannot render binary data (certificates and CRLs) in UI. To view container contents in UI you can use PKI Health Monitor (PKIView.msc) tool.
In this window you can view and delete entries for all containers, except Certificate Templates and OID.
Also, this tool allows you to add CA certificates only to NTAuthCertificates containers. To add certificates or CRLs to other containers (AIA, CDP, Certification Authorities) you should use certutil.exe tool as described above.
By default only members of Enterprise Admins group have permissions to modify the contents of the Public Key Services. If necessary, you can delegate appropriate permissions to other user or group (must be either global or universal) via ADSIEdit.msc tool.
Senior PKI Developer
Hi
I have setup a 2 tier Microsoft certificate authority with an offline root.
I published the offline root certificate to Active Directory and it was pushed to the trusted root certificate authority store on the clients
When I introduced the enterprise issuing certificate authority my root certificate is now also being published to the enterprise certificate store along with the issuing certificate.
Do you have any idea why this is happening and how I resolve it.
Thanks
John
When you say “enterprise certificate store”, which store is that? Are you referring to “Enterprise Trust” or the Intermediate Certification Authorities store. I assume the latter as that is where Isusing CAs go. If that is the case, it’s possible there was an error in your publishing command. Did you run “certutil -f -dspublish XXXX.crt RootCA” where XXX.crt is your Root CA certificate? Did you also happen to run it without the trailing RootCA? If you were to do that, the CA would be published as an intermediate CA and be placed into the Intermediate Certification Authorities store. So I am just speculating that is what happened there.
Hi thank you for responding so quickly and sorry I wasn’t clear
I did mean the Intermediate Certification Authorities store. I have just gone back over my install notes and I am missing the rootca part from the end of my certutil command. So looks like you have found the issue straight away. 🙂
Is it just a case of removing the certificate and republishing it and adding rootca to the end this time?
Just out of interest if i missed the rootca part from the command, how is it also being added to the Trust Root Authorities store on the client machines??
Hi, this article is really awesome!
Now I am stucking at the same problem as ‘JD’.
How did you success to add the certificate to the Trust Root Authorities store on the client machines?
Thanks
Did you read the article? The answer to your question is clearly presented in the post. Read “Certification Authorities” section for answer.
Hi
I have my offline root listed in the Certification Authorities Container and the AIA Container in active directory.
Which one should I remove to stop it showing in the Intermediate Certification Authorities store on the clients??
Sorry after reading your article again its clear which one to remove
Great article! thanks a lot!
For permissions on this container . If I don’t want the PKI team to be part of the Enterprise Admins group, is there a guide I can follow or can you provide the proper permissions needed for them to be able to perform their work. Please let me know if its best to leave the PKI team as part of the Enterprise Admins.
Hi. Great post and very useful. I have a question though. I have just build a new 2-tier PKI system using an offline non-ddomain joined Root CA and then an online domain joined Sub CA. We still have an existing Enterprise CA in place. This doesn’t seem to be a problem at the moment and I will make steps to remove the old CA soon.
My issue is that the new Sub CA isn’t appearing in the Certification Authorities section of AD Sites and Services. It is appearing in AIA, CDP, Enrollment Services and KRA though. Is this going to cease an issue and should I take an steps to fix it?
Thanks
This is covered by the blog post you are commenting. Please refer to the section “Certification Authorities” in this blog post.
Subordinate CAs are only designed to go into the Enrollment Services object (if an Enterprise CA). Root CAs go into Certification Authorities. So what you are seeing is exactly what is supposed to happen.
We had a problem with a server that hosts the offline root CRL while I was out on vacation. One of our admins set a flag on the two CA issuers so they would not check revocation as a quick workaround. Now that the sick server is back online we changed the flag back to its previous setting and the AD CS services will not keep running and an event ID 100 is getting logged. I get this when running CERTUTIL -URLFETCH -VERIFY .
The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)
I have verified the URL listed in the CDP field is valid and does return the current CRL.
When checking the AIA entries in AD Sites and Services, I found a reference to a server that was decommissioned two or three years ago. When I run PKIView, I see a number of errors for this server on the AIA, CDP, and Certification Authorities Container tabs. If I run the “certutil” command on the issuer servers, “Entry 0” references this server.
Is it a simple matter of just deleting the entries for this server via PKIView, or is there a different method I should follow?
The old CAs in AD will not cause this problem to occur. Most likely the CDP information hasn’t been properly published in all the locations needed in the CDP for the Root. You should make sure the AD and HTTP based locations are properly published. PKIView, selecting the Root CA should show you the status for these locations. Alternatively, it could be that the subordinate CAs lack the permissions or ability to access your CDP locations.
I have 2 windows server 2019. e.g. server1 and server2.
server1 is the domain controller. server1 has below roles installed: ADDS, ADCS, DNS, FILE STORAGE, IIS.
server2 is connected to that domain controler. server1 has below roles installed: ADCS, FILE STORAGE, IIS.
I have setup PKI on server1 and everything works fine. I am able to use CRL as well as OCSP feature for certificate validation.
I made server2 as subordinate CA of server1(root CA), and installed corresponding roles(ADCS) and able to distribute user certificate and its working fine. But I am not able to test CRL functionality on server2 as it required ldap binding with server2.
As I debugged it further, I found that LDAP server is not running on server2. When I checked port 389 is listening on server1 but not server2.
So how to enable ldap service on server2 ? I am not able to test CRL functionality of PKI, because CDP url is ldap address.
LDAP refers to active directory. So you should be trying to bind to your DC to do an ldap query, not server 2.
Also, you don’t need to verify checking manually, you can use pkiview.msc on your CA to get the status of the PKI and crl.
When you sync AD objects between forests (e.g. from abc.example.com to people.example.com) (in order to issue certificates in the forest that does not contain, but does trust the PKI in the other): how can you view the certificates in the different containers in the people AD Services containers – without having access to a domain member machine in the people forest?
I can use Sites & Services and point to the people domain from a abc domain member – but it is not an easy way to extract and view the certificates. Can I somehow point pkiview.msc to the other forest? Or the Manage AD Containers part of it? Is there another way withy powershell or certutil (certutil -dc dc1.people.example.com -ADCA gives me failed: E_POINTER)?
PKIView.msc does not support cross-forest browsing. It operates in current forest only. If you need to view certificates in another forest — you have to develop your own tool.
Vadims, thank you for the quick response. I now managed to do it like this (very simple actually)
$dsAIA = get-adobject -server DC.people.example.com “CN=…,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC={…}” -Properties cacertificate
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 @(,$dsAIA.cACertificate[0])
yes, it is an option
How do domain member computers decide which intermediate CA from the Enrollment Services container they should use to obtain an auto-enrollment certificate? Especially if there are multiple intermediate CAs there which come from two or more different roots?
They pick issuing CA arbitrarily unless client site awareness is configured. And even then if you have multiple CAs in same site, arbitrary CA in this site will be chosen.
Hi ,
We built a new CA setup in Windows and published RootCA cert and CRL to AD. We could view all the required certs/crls in AD Containers from PKIView. But PKIView is not populated with newly built CA setup. CAExchange cert is auto generated.
Please help in resolving this issue. Thanks in advance.
First of all – massive thanks to you all as you are the definite guide regarding Windows CA.
My question, I renewed an issuing CA certificate (using existing key) – it all went well. I can see the new certificate in NTAuthCertificates but if I go to a member server I do not see the certificate in the Intermediate Certification Authority store, I do see the previous one (it is still valid). I have done a few renewals in other environments and not had faced this issue. The member is set to auto enroll although I do not think that is valid as the certiifcate is not obtained via a template.
Any idea where I can look? I thought there was a relationship between the NTAuthCertificates area and the local machine Int CA Store?
Thanks
You may need to wait up to 8hrs before certificate is propagated from AD to client machine. Or call ‘certutil -pulse’ to trigger AD store propagation.
Thanks Vadims,
It has been a week and ran the command but no joy. Just trying to understand how the NTAuthCertificates area is linked to the computer’s local machine store. Are you able to shed some light so I can look in the right areas.
I have waited 8 hours, well a week and no joy.
How do I correlate the blobs on the registry, ntauth to the certificates seen in the gui?
Hi not sure why my comments do not appear. I did wait for nearly a week and ran that command. What makes a client pull down certs from the ntauth tab into their local store.
Another question I have is – I can see blob entries on the member server HKLM\Software\EnterpriseCertificates\NTAuth\Certificates. I am trying to correlate this with the NTAuthCertificates Tab in the AD Container GUI. I just want to know if the certificates I see in the GUI are the ones in the registry?
Yes, they should be the same.
I have, been a week.
How do I correlate the blobs in the registry to the certs in the gui?
I’ve got a better understanding now. When I renew the Issuing CA certificate, the newly issued certificate would appear (in Manage AD Containers) in the AIA Container Tab as well as the NTAuthCertificates Tab. My issue is that it has not appeared in the AIA container tab. So just wondering why?
@Vadims, I can see you wrote a great article on converting Binary to HEX to PEM using certutil. Do you know if there is a way to convertthe certificate that is stored in the registry (BLOB = REG_BINARY) to a BASE64 version so I can open and view the contents. I just want to verify what I see in the registry matches what I see in the AD Containers GUI and vice versa.
> My issue is that it has not appeared in the AIA container tab.
you may need to check Application event log on CA (if it is domain-joined).
> Do you know if there is a way to convertthe certificate that is stored in the registry (BLOB = REG_BINARY) to a BASE64 version so I can open and view the contents.
I don’t remember if certificate in registry is stored as raw certificate or is enveloped. You can try to read REG_BINARY value into byte array and save into a file (using binary encoding) and open the file.
Hi Vadims, through your library can i implement certificate auto enrollment using .net core.
Thanks,
Sanjeev
Hello Vadims, you guys are awesome.
i have a question about PKI in multiple forest Active Directory.
My users are in say Company Domain. My PKI servers are in say ForestRoot domain.
When i look at my AD containers for PKI is see very different contents if i am logged in as say user@company.com when compared to login as user@forestroot.com.
Shouldn’t these AD containers for PKI be synced using a script from Microsoft? It seems i remember something about a sync script.
For example the Enrollment Services Container for both the ForestRoot domain and the Company domain should both contain the same list of Issuing CAs however they do not.
if your CA sits in another forest than clients, then AD PKI containers should be synced from CA forest to account forest.
Hi. Thanks for the great article, very useful.
At the weekend we did an in-place upgrade from 2012R2 to 2016 and everything seemed to go well apart from one thing. Computer certificates only seem to renew (through the Windows 10 MMC Certificates Snap-in, choosing “Request New Certificate”) when logged on as a domain administrator. When logged on as a standard user, I get “An error occurred while obtaining certificate enrollment policy Url:ldap: Error Access is denied”. This is just before the screen that lists which certificate templates are available to use.
Our environmant is a Two Tier PKI, made up to 1 Root CA (off-line), 2 subordinate CAs and 2 ocsp servers.
I cant see anything in Event viewer on either the Windows 10 PC or a domain controller, or on the subordinate CA.
Thankyou for ay advice you can offer, it will be most appreciated.
Tony
Hello Vadims,
I have a 2 Tier Enterprise PKI. I have an offline Root CA on a 2012 r2 server. An online Issuing CA on a 2012 r2 server. I am going to upgrade to 2022 next year. But I have an immediate need for a second online Issuing CA. Is it possible to have the second CA on 2022 with a 2012 r2 root ca?
Thanks
Not a problem at all
Hi. I have an issue that I hope you can address. The CA was updated from SHA1 to SHA2 but caused log in issues so we restored it back to SHA1. Now we have two certificates, with the same name appearing in the Trusted Root Certification Authorities but with different expiration dates. How do we remove the newer one and have it stop being issued. We ran a script to remove it but it returns. This certificate is what allows our wireless devices to connect and now our Windows11 workstation will not connect without selecting the SSID.
Hi,
This question is only indirectly related to this blog post, can’t find a more appropriate place to ask at this stage.
Appreciate any advice you may have.
The question is: in a SHA2 environment, if an ADCS issuing CA certificate is mistakenly reissued with a SHA1 signature (same key pair as previous certificate), what options do you think there are to tidy it up?
My thoughts are:
1) Reissue the CA certificate with a SHA2 signature
2) Revoke the SHA1 CA certificate. I have read in various posts that it is not a good idea as need CRL creation continuity even for expired certs, not to mention the fact that existing leaf certs could be invalidated, however if the CA certificate that is generated in step 1 continues with the same key pair, would this still be an issue?
3) Prevent the SHA1 CA certificate from being distributed by removing it from the AD containers (pkiview.msc – manage AD containers)
I can’t find much supporting documentation validating the last two steps.
I’ve already done some testing in a lab and steps 1) and 2) so far have not caused issues (certs previously issued under the SHA1 CA certificate validate correctly, i.e. chain up to the newer SHA2 CA certificate. The SHA1 cert is also validated as revoked via Certutil. Step 3) had mixed results as the SHA1 cert can be removed from the AIA container but then reappears.
Hello
I have just renewed the Offline Root Cert, using a new key pair. I have published the cert and CRLs in to AD and I can see them in the PKIView containers.
However in PKIView the CA Certificate still appears as the old one and the AIA and CDP lookups are still for the old cert.
I also have new Issuing certs that were signed after the Root was renewed. Do I need to apply those before before PKIView will show the new locations (they display in the details of the new issuing certs)
