Hi I am trying to implement a 2 tier MS PKI. The offline root CA is on Windows 2008 standard x86. The enterprise CA is on Windows 2008 standard R2 x64. For some reason I cannot install the CA cert issed by the Root CA on the enterprise CA. It gives me an error 0X8007000D (win32: 13). Could it be the fact that the CA cert is issued by a Windows 2008 R1? Thanks

No, the fact that the root is 2008 and the SubCA is 2008 R2 won't be the issue here. Can you run certutil -verify subca.cer rootca.cer (change the names of the certificate files as appropriate) and post your results? Paul Adare CTO IdentIT Inc. ILM MVP

it looks like your subordinate CA cannot validate his own certificate, because there is no CRLs.http://www.sysadmins.lv

Hi Vadims, The Root CA's CRL are published on a web server that is accessible from the Subordinate CA. I am not sure why the ADCS it still complain there is no CRL. Thanks

This looks important: ERROR: CA did not issue CRL: Signature check failed So, not only does the CA sign each certificate it issues, it also signs each CRL it publishes. It is a requirement that, when validating a certificate, the private key the CA used to sign the certificate must be the same private key used to sign the CRL being published. This is why, if a CA has multiple keys, ie, if the CA has been renewed with a new key pair, the CA will publish multiple CRLs. Each CRL is signed with a different key pair. The CA will continue this behavior until the certificate associate with that private key expires (which means that every certificate signed with that key has also expired; it doesn't matter if expired certificates are revoked or not.) The Windows CA differentiates each of these CRLs by including in the file name the index of the key pair used to sign the CRL. When the CA signs a certificate it includes in the certificate the location of the CRL against which applications can check the certificate's revocation status -- this is the CDP. That error message probably indicates that the CRL referred to by the SubCA's isn't signed with the same key used to sign the SubCA certificate. This can happen if you modify the default CDP extension on the CA -- which you have -- and you fail to include the Key Index replaceable parameter in the CRL filename. The default HTTP URL is http://CAserverFQDN/certenroll/%3%8%9.crl. %3 is the name of the CA %8 is the CA Key Index %9 is the little "+" sign that indicates the CRL is a delta rather than base You can see your current settings with the following command: CDP extension: certutil -getreg CA\CRLPublicationURLs AIA extension: certutil -getreg CA\CACertPublicationURLs The actual registry key where those values are located is HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>. So, if you modify the CA's CDP extension and you hardcode the CRL filename file name rather than use the replaceable parameters, and you renew the CA's key at some point, rather than publish two CRLs -- each denoted with a different key index value -- you'll get only one CRL file. That's because the CA is still creating multiple CRLs, and signing them with each different key, but they'll all have the same file name. Each new CRL will overwrite the one previously created an infinitessimal moment earlier. What you will notice, however, is that suddenly a possibly large swath of certificates signed with a previous CA key will suddenly fail revocation checks. Much like you're seeing now with your SubCA. What you'll need to do is correct the CDP and AIA extensions on your CA, restart the service, and then re-issue your certificates. You'll have to re-issue them because it is impossible to modify the CDP and AIA of certificates you've already issued. So, if you correct the configuration on the CA and then re-install the CA role on your SubCA, the new certificate you get should have a correct CDP, and then the SubCA should start. Hope this helps. Jonathan Stephens

Thanks Jonathan for your detailed response. The thing I found strange is that I have not renew the private key of my Root CA, I have republish a CRL and the ADCS service in the Subordinate Issuing CA still will not start. I end up solving the problem by rebuilding the Root CA and the subordinate CA. One thing that I was looking for is to generate a new certificate request from the Subordinate Issuing CA, but I could not find it. Am I oblige to rebuild the rebuild the Subordinate Issuing CA in order to generate a new certificate request? Andrew

hi there, follow this steps: 1. configure CRL Settings on Root CA 2. configure CRL Settings on SUB CA 3. configure ISS for CRL Usage 4. import .req file in Root CA (to generate certificate for SUB CA to make start) 5. import generated certificate on Root CA in Sub CA 6. make Root Certificate trusted for Sub CACosta Curta

??????, you did see that this was asked an answered back in April 2010, right? <G> Brian

??????, you did see that this was asked an answered back in April 2010, right? <G> Brian so..?Costa Curta