Hello everybody, And again I’ve encoutered a problem with CA hierarchy. The hierarchy is show in the picture below: http://img525.imageshack.us/img525/2021/cahierarchy.jpg Everything with RootCA and Enterprise CA (which is Domain Controller simultaneously) is OK. In Enterprise CA I have certificate template which is duplicate of a User template but it is only for Central Office Users (read/enroll/auto-enroll). There is also a GPO which configure certificate auto-enrollment -http://technet.microsoft.com/en-us/library/cc731522.aspx So if a user from Central Office Users group logs in to domain, it gets a certificate. In Enterprise CA I’ve created duplicate of SubCA template with 10 years validity length. Then I’ve installed SubEnterprise CA and Enterprise CA automatically issued a certificate for SubEnterprise CA. Then, on SubEnterprise CA I’ve checked Certificates Snap-in (for Local Computer). There, in Trusted Root Cert Authoritites/Registry/Certificates the cert of the Root CA is listed. Certificate of the Enterprise CA is listed in the Intermediate Cert Authorities/Registry/Certificates. Everything seems to be OK, so I’ve created a new group for Branch Office Users in DC. On SubEnterprise CA I’ve made a new cert template (on the basis of User template) for Branch Office Users – read/enroll/auto-enroll. But there is a problem with issuing certificates. When user from Branch Office Users group logs in to domain it doesn’t get a cert. In CertSrv.msc in SubEnterprise CA in Failed Requests section, there are requests from users who logs in with “The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614)” message. What is wrong? Unfortunately I have no idea. Please help Best.

Hi, Are clients in Branch Office able to ping the SubCA (certutil -config <sub ca config string> -Ping) Thanks, John

Hi, John, thanks for your response. Unfortunately yes... I can ping SubEnterprise CA by: IP, Computer Name and certutil command Here is a listing: C:\Users\janKowalski>certutil -config SRV-02 -Ping Connecting to SRV-02 ... Server "pki-SRV-02-CA" ICertRequest2 interface is alive CertUtil: -ping command completed successfully janKowalski account is a member of Branch Office Users group. Maybe sth wrong with CRL lists?

make sure if CA server is able to determine its own CA certificate revocation status. Run PKIView.msc MMC snap-in and check it.http://en-us.sysadmins.lv

Thanks for your response For me, everything seems to be OK, but maybe you can indicate a problem here. http://b.imagehost.org/0225/pkiview1.jpg http://b.imagehost.org/0526/pkiview2.jpg http://d.imagehost.org/0652/pkiview3.jpg http://b.imagehost.org/0283/pkiview4.jpg

http://b.imagehost.org/0526/pkiview2.jpg your Root CA don't issue CRTs and CRLs??? http://en-us.sysadmins.lv

The same in PKView.msc on EnterpriseCA. I imported Root's crt and Root's crl manually to EnterpriseCA (Root CA has been never connected to the network) and they are shown only in physical certificate stores on EnterpriseCA. And it works fine. But when Vadims have found a fault, I imported only a Root's crl to SubEnterprise and... it works. So now I cannot understand the mechanism of automatic requesting & issuing certificate for SubCA. SubEnterprise get a Root's crt automatically, Enterprise's crt and crl automatically but without a Root's crl?! I'd rather say that I made a mistake somewhere, but I do not know where. Can you point it out? :) A lot of questions, I know. But please, be patient :)

> Root CA has been never connected to the network and? This don't mean that CA must not publish CRLs. If CA is offline, you may extend CRL publishing periods for them (for example, 3, 6 or 12 months) and configure retrieval points (CDPs that will appear in issued certificates). If CA is offline you may copy CRLs to removal drive (USB flash or CD-R) and distribute to publically accessible locations. Your Enterprise CAs are configured to publish their CRLs to AD, so AD forest users will be able to retrieve them. Though, you will have to issue new certificates to all CA's (except Root CA) with configured CDP and AIA extensions.http://en-us.sysadmins.lv

In this situation when SubEnterprise CA gets RootCA cert, EnterpriseCA cert and CRL, configuring extensions CDP and AIA (which will indicate EnterpriseCA) for RootCA CRL wouldn't be enough? Best, P.S I don't want to change everything in my real network so in that case importing a Root CRL to SubEnterprise will be a sufficent solution?

> In this situation when SubEnterprise CA gets RootCA cert, EnterpriseCA cert and CRL, configuring extensions CDP and AIA (which will indicate EnterpriseCA) for RootCA CRL wouldn't be enough? no, because your Root will still not issue CRL's. To publish CDP/AIA locations to certificates issued by root, you must configure these extensions and reissue these certificates. > I don't want to change everything in my real network so in that case importing a Root CRL to SubEnterprise will be a sufficent solution? still no, because certain applications will fail authentication if some of certificates in hte chain could not be verieifed. All applications that are strict to revocation checking (IPSec, RDP-TLS, L2TP/SSTP VPN, etc) will fail authentication. Applications that are not strict for revocation checking (Internet Explorer, smart card logon in Vista and higher, digital signature checking processes) may ignore revocation checking errors and continue to use these certificates.http://en-us.sysadmins.lv

You have made an error very high in the CA hierarchy. Unfortunately, the only way to fix this to work with all clients (strong or weak CRL checking) is to do what Vadims has stated. 1) Fix the CDP and AIA extensions for issued certificates at the root CA 2) Re-issue the subordinate CA certificate 3) Re-issue all certificates issued by the subordinate CA. You must re-issue the sub-CA certificate because you cannot modify the sub-CA certificate to reflect the new CDP/AIA without invalidating the signature on the certificate. HTH, Brian

Thank you all for your response. OK, let me get this straight. Now my PKI infrastrucutre... is not good. Earlier, without SubEnterpriseCA everything seemed to be OK. I did RootCA and EnterpriseCA according to instructions in a book. As in the step by step guide, at off-line RootCA I removed 'ldap', 'http', 'file' extensions for CDP and AIA. There are only 'C:\Windows\System32\CertSrv\CertEnroll\<CAName>...' left. At Enterprise CA I imported RootCA cert and CRL list from USB drive. And it worked fine for me. But I'm not sure if I uderstand well - that solution is wrong? Now, if I make my SubEnterprise subordinated only to RootCA (as the second Enterprise CA) with manually importing Root CA and CRL it will be ok? After what you said, I think not really (but it will be 100% example from this book) Maybe for that 2layers hierarchy it is OK? -------- The second scenario. I want to have: RootCA - EnterpriseCA - SubEnterpriseCA. You told me that first I have to fix CDP/AIA extensions at RootCA. OK, on TAB extenstions I will add ldap entry to CDP and AIA (I'm not sure if http and file are required). But should I use: ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass> or indicate particular CA - Enterprise CA in that case? (Why I think so? Because Enterprise CA will be on-line and have idea about the network).

> Earlier, without SubEnterpriseCA everything seemed to be OK this is because clients are configured to not check Root CA certificate for revocation, because it is self-signed and explicitly trusted. > I did RootCA and EnterpriseCA according to instructions in a book. Do you refer to Brian's book? I believe you have misinterpreted this point. Brian adviced to remove CDP/AIA extensions from *Root CA own certificate*! After CA installation you had have to configure CDP/AIA locations. > But I'm not sure if I uderstand well - that solution is wrong? definitely. Because only SubCA server has this CRL. Other computers will haven't it. > Now, if I make my SubEnterprise subordinated only to RootCA (as the second Enterprise CA) with manually importing Root CA and CRL it will be ok? Technically this is not required. Though you will have to publish Root CA CRLs to corresponding CDP locations prior to SubCA installation. And SubCA will examine his own certificate, retrieve CDP URL and determine his own certificate status. > The second scenario. I want to have: RootCA - EnterpriseCA - SubEnterpriseCA. You told me that first I have to fix CDP/AIA extensions at RootCA. OK, on TAB extenstions I will add ldap entry to CDP and AIA (I'm not sure if http and file are required) this really depends. Personally I use only HTTP URLs and publically accessible web server.http://en-us.sysadmins.lv

OK, so what's about temporary solution like manually importing Root CRL to every computer in the network? Then it'll be fine I guess. I know that is a brute force solution, but I don't feel like I know how to reconfigure all this stuff, so I need time to some review about CAs.

OK, so what's about temporary solution like manually importing Root CRL to every computer in the network? Then it'll be fine I guess. I know that is a brute force solution, but I don't feel like I know how to reconfigure all this stuff, so I need time to some review about CAs. >> But I'm not sure if I uderstand well - that solution is wrong? >definitely. Because only SubCA server has this CRL. Other computers will haven't it. OK, and publishing in AD by certutul -dspublish -f [CRT/CRL] command woulnt't work? //Edited - Yup, I checked it. It's impossible without configuring extensions which we talk about. > Do you refer to Brian's book? I believe you have misinterpreted this point. Brian adviced to remove CDP/AIA extensions from *Root CA own certificate*! After CA installation you had have to configure CDP/AIA locations. I used book in my national language which is for sure unknown aborad. I think of reinstalling RootCA. Then I will be able to generate new Cert and CRL with extensions (now I have problem with new CRL). New cert request from EnterpriseCA I would move in USB. And then at EnterpriseCA i would add to local store these files and publish them in AD. Will it work (reinstalling Root CA for my convenience, and leaving alone EnterpriseCA but issuing new cert for it)? Best,

> OK, and publishing in AD by certutul -dspublish -f [CRT/CRL] command woulnt't work? you can publish CRLs to AD, but no one will download them until appropriate path is published in the certificate CDP extension. CRLs are not downloaded automatically by clients (unlike as AIA, RootCA, NTAuthCA certificate AD containers). > I think of reinstalling RootCA you don't need to reinstall RootCA. Just configure CDP and AIA extensions and renew certificates on subordinate CAshttp://en-us.sysadmins.lv