I've just built a new Enterprise root CA. Both DCs are running 2008R2. For this new enterprise root CA, in the Server Manger - Enterprise PKI menu one server reports what all is OK (CA cert, AIA location, CDP location, DeltaCRL location all OK) and the other tells me: CA certificate : OK AIA location : Unable to download CDP location : Unable to download The URLs are identical, the user account is the same. So I guess it must be a permissions problem. Where do I look and how? CarolChi

Try resetting the Enterprise PKI tool by revoking all CA Exchange certificates issued by your Enterprise CAs. The Enterprise PKI reads AIA and CDP by requesting a CA Exchange certificate from each Enterprise CA as well as reading the enterprise CA certificate to list the AIA and CDP from the Root CA. /Hasain

How do I get these CA Exchange certificates back? Or are they recreated automatically?CarolChi

They will be regenerated when you run the Enterprise PKI tool /Hasain

You are right they are regenerated. However it does not help, I still have "unable to download" for the AIA and CDP ldap locations (there are no http locations) when viewing from one server. from the other servers everything is fine, and I would say everythign is working. CarolChi

Can you please post the result from the commands below on both of your CAs certutil -getreg ca\crlpublicationurls certutil -getreg ca\cacertpublicationurls

Problem DC/CA (shows unable to download im Enterprise PKI) certutil -getreg ca\crlpublicationurls HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\smalldom2CA\CRLPublicationURLs: CRLPublicationURLs REG_MULTI_SZ = 0: 65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl CSURL_SERVERPUBLISH -- 1 CSURL_SERVERPUBLISHDELTA -- 40 (64) 1: 79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10 CSURL_SERVERPUBLISH -- 1 CSURL_ADDTOCERTCDP -- 2 CSURL_ADDTOFRESHESTCRL -- 4 CSURL_ADDTOCRLCDP -- 8 CSURL_SERVERPUBLISHDELTA -- 40 (64) 2: 0:http://%1/CertEnroll/%3%8%9.crl 3: 0:file://%1/CertEnroll/%3%8%9.crl CertUtil: -getreg command completed successfully. certutil -getreg ca\cacertpublicationurls HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\smalldom2CA\CACertPublicationURLs: CACertPublicationURLs REG_MULTI_SZ = 0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt CSURL_SERVERPUBLISH -- 1 1: 3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11 CSURL_SERVERPUBLISH -- 1 CSURL_ADDTOCERTCDP -- 2 2: 0:http://%1/CertEnroll/%1_%3%4.crt 3: 0:file://%1/CertEnroll/%1_%3%4.crt CertUtil: -getreg command completed successfully. Other CA (shows no errors) certutil -getreg ca\crlpublicationurls HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\SmalldomCA\CRLPublicationURLs: CRLPublicationURLs REG_MULTI_SZ = 0: 1:C:\WINDOWS\system32\CertSrv\CertEnroll\%3%8%9.crl CSURL_SERVERPUBLISH -- 1 1: 4:http://%1/CertEnroll/%3%8%9.crl CSURL_ADDTOFRESHESTCRL -- 4 2: 1:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10 CSURL_SERVERPUBLISH -- 1 3: 1:file://%1/CertEnroll/%3%8%9.crl CSURL_SERVERPUBLISH -- 1 CertUtil: -getreg command completed successfully. certutil -getreg ca\cacertpublicationurls HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\SmalldomCA\CACertPublicationURLs: CACertPublicationURLs REG_MULTI_SZ = 0: 1:C:\WINDOWS\system32\CertSrv\CertEnroll\%1_%3%4.crt CSURL_SERVERPUBLISH -- 1 1: 1:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11 CSURL_SERVERPUBLISH -- 1 CertUtil: -getreg command completed successfully.CarolChi

For the first CA, the CRLs (Base and Delta) is published to AD, the other URLs (http and unc) are configured but not used. The config of the CA looks very standard and should work just fine. For the second CA, the CRLs (only base) are published but never used in any certificates. The CDP config of this CA really needs a revision! To troubleshoot the new CA: restart the certification authority service publish the CRL and observe any errors using: certutil -crl if no error occurred in the previous step continue to revoke all CA Exchange issued from the CA and check/refresh the Enterprise PKI status /Hasain

That is very strange because it is the server with first one which shows the errors in Enterprise PKI. I have followed your instructions on the and certutil -crl reports "command completed successfully". However in Server Manager on the server with the first CA (SMALLDOM2CA) I still see "unable to download" for the AIA and CDP locations. In Server Manager on the server with the second CA I see no errors.CarolChi

If you run Enterprise PKI on each server, it should see both your old and new CAs. Can you list what is reported on each of the servers for both CAs example: Ent. PKI on New CA Old CA CDP status = AIA status = New CA CDP status = AIA status = Ent. PKI on Old CA Old CA CDP status = AIA status = New CA CDP status = AIA status = /Hasain

DDC Enterprise PKI (DC which reports PKI problems) CA2 (new) : error CA certificate = OK AIA location @1 = Unable to Download CDP location #1 = Unable to Download CA1 (older) = OK CA certificate = OK VDC (no problem reports) CA2 (new) : OK CA certificate = OK AIA Location #1 = OK CDP location #1 = OK Delta CRL Location = OK CA1 (old) CA Certificate = OK CarolChi

Do you have any replication problems in Active Directory? ADCS store its forest wide PKI configuration in Active Directory and perhaps some objects may not have been replicated to the other site? Run repadmin /showreps /v on a domain controller to check for any problems.// Fredrik "DXter" Jonsson - http://www.poweradmin.se

CarolChi, The problem should be local on your DDC computer as the other DC can locate and download the CDP of the new CA successfully. Just like DXter described it, you only have LDAP/AD based CDP and if CRL publishing is performed correctly and another DC can read it then it is either the Enterprise PKI tool, specific user session or som replication to that specific DC that is not working properly. /Hasain

All replications are shown as successful on both domain controllers. It is only one site. CarolChi

Same user on both systems, single site, no replication errors. I can perhaps try another user. That is why it is so strange.CarolChi