Time by time I read questions about CDP and AIA extensions on Root CA and in Root CA certificate.
Check these articles for better understanding of certificate chaining engine:
Let's see how these are used by certificate chaining engine (CCE). At first application must build a certificate chain. When CCE is processing a certificate it uses AIA extension to retrieve certificate issuer's certificate. Once it is retrieved, CCE set issuer's certificate as current and checks for *current* certificate issuer's certificate. This is normal and expected behavior for non-self-signed certificates. Once a certificate is presented in the self-signed form, there is no issuer. Certificate is issued to itself. As the result if AIA extension exist in the self-signed certificate it will point to itself and will cause loops. To address this issue, it is recommended to *NOT INCLUDE* AIA extension in the self-signed certificate (also referred to Root certificate).
Once certificate chain is built CCE will check each certificate in the chain for revocation. For this it uses CDP extension. Again, CCE will retrieve URL to a CRL of the issuer of the certificate which is being verified. When certificate status is determined (and possible is not revoked) CCE set issuer's certificate as current and retrieves CRL of the *current* certificate issuer. This process continues until it reaches a certificate provided in a self-signed form. Since there is no issuer (certificate is issued to itself), it is not possible to revoke itself (at least in Windows PKI). As the result it is recommended to *NOT INCLUDE* CDP extension in the self-signed certificate (also referred to Root certificate).
The biggest problem here is that many IT admins assumes that CDP and AIA extensions MUST NOT be configured on Root CA servers. This is INCORRECT. When you configure CDP and AIA extensions on CA server (by using Certification Authority MMC snap-in or certutil.exe utility) they affect only to *issued* by this CA certificates (SubCAs or other entity's certificates), but not CA certificate itself. Also many applications are configured to not check Root CA certificate for revocation even if it contains CDP extension.
To avoid mentioned extensions appearance in Root CA certificate you MUST create or edit existing CAPolicy.inf file that MUST have exact name and placed to %windir% directory on CA server *prior* to Root CA service installation. It is not possible to modify Root CA certificate after CA service installation. The following syntax can be used:
[Version] Signature = "$Windows NT$" [AuthorityInformationAccess] Empty = true [CRLDistributionPoint] Empty = true
This configuration is necessary for CA servers based on Windows 2000 and Windows Server 2003. Windows Server 2008 and newer operating systems do not include these extensions in Root CA certificates by default.
Once Root CA is installed you should perform AIA and CDP extension modification to fit your organization and/or network/AD topology requirements. URLs from these configurations will be included in all issued certificates and can be used by applications to built correct chains to this Root CA and perform revocation checking against certificates are issued by this CA.
HTH
Hi Vadims. First of all, great article. It cleared some misunderstandings. Nevertheless, I have a question. I have 2 Tier PKI. Windows 2008 R2 STD is Offline RootCA. I issued one certificate for Subordinate Enterprise CA on Windows 2008 R2 ENT. When I have revoked Subordinate certificate from RootCA, on a Subordinate created a new request and processed it on a RootCA. Installed newly issued certificate to the Subordinate and I copied CRL from offline RooCA to the online location defined using MMC snapin (location is defined on RootCA). When I clikc PROPERTIES on SUBORDINATE CA in MMC, on CERTIFICATES TAB I see two certificates. "Certificate #0" and "Certificate #1". Certificate #0 status says STATUS OK and it should be revoced. I have confirmed that online location of RootCA's CRL can be accessed without errors. Tried to publish RootCA's CRL using "certutil -dspublih -f crlname.crl", but keep getting error "Required CDP extension is missing". I typed this command on Subordinate CA. How to resolve this? TNX
You expereince this issue because your subordinate CA has existing cached CRL. The cached CRL is not updated until it expires. Therefore you need either: 1) install new CRL to the local store (on the Sub CA); 2) instruct Sub CA server to enforce cached CRL update by running the following commands: certutil -urlcache CRL delete certutil �setreg chain\ChainCacheResyncFiletime @now
I've added LDAP line on Offline ROOT CA and reissued CRL (this is my test env). After that I successfully published CRL using "certutil -dspublish -f crlname.crl", but SubCA certificate was still OK. After that I've runned "certutil -urlcache * delete " and it worked. Certificate appeared "Revoked by Issuer" Question: If a client has certificate, on smart card used for logon, signed by SubCa revoked certificate, and he tries to log on and has old (cached) CRL, does that mean it will be able to log on? I think it should be rejected by DC. I would replace revoked certificate in a GPO and import a new one. Am I right?
I've added LDAP line on Offline ROOT CA and reissued CRL (this is my test env). After that I successfully published CRL using "certutil -dspublish -f crlname.crl", but SubCA certificate was still OK. After that I've runned "certutil -urlcache * delete " and it worked. Certificate appeared "Revoked by Issuer" Question: If a client has certificate, on smart card used for logon, signed by SubCa revoked certificate, and he tries to log on and has old (cached) CRL, does that mean it will be able to log on? I think it should be rejected by DC. I would replace revoked certificate in a GPO and import a new one. Am I right?
> If a client has certificate, on smart card used for logon, signed by SubCa revoked certificate, and he tries to log on and has old (cached) CRL, does that mean it will be able to log on? Possible yes. If a cleint is Windows Vista and newer then it will attempt to check if CA server has issued new CRL prior to planned publication date. This really depends from several factors. For more information please sheck this article: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=361c4644-9b1b-41fd-aaf9-370717edcbbc
Hi All, Just wanted to share a scenario and get your experts opinion. I have been working in a 2 tier topology having the root CA as stand alone office. While having the issuing CA as Enterprise Subordinate. The defualt CDP & AIA URL's locations apprears to be a local file path in the subordinate CA certificate. Having a certificate SSL certificate issued for one of my webserver, it gives me error while checking for the chain of trust. Since the root CA's CRL verification locations are not valid. Later i have created new CDP & AIA locations URLs on the ROOT CA pointing toward a share folder on the Enterprise Subordinate CA, and reissued the certificate for the subordinate CA. Now while executing the "certutil -URL C:\SUB_CA_CERT\SUB-CA-Cert.crt" i get the "Failed" stautus against both CDP & AIA URL paths. Whereas, those path are located on the same server under a shared directory and are accessible to all the Authenticated Users in my domain. Any ideas or suggestion please share. Thanks.
For CRL and CRT file retrieval only HTTP and LDAP protocols are supported. Absolute and UNC paths are allowed only for file publishing.
Hi All, Just wanted to share a scenario and get your experts opinion. I have been working in a 2 tier topology having the root CA as stand alone office. While having the issuing CA as Enterprise Subordinate. The defualt CDP & AIA URL's locations apprears to be a local file path in the subordinate CA certificate. Having a certificate SSL certificate issued for one of my webserver, it gives me error while checking for the chain of trust. Since the root CA's CRL verification locations are not valid. Later i have created new CDP & AIA locations URLs on the ROOT CA pointing toward a share folder on the Enterprise Subordinate CA, and reissued the certificate for the subordinate CA. Now while executing the "certutil -URL C:\SUB_CA_CERT\SUB-CA-Cert.crt" i get the "Failed" stautus against both CDP & AIA URL paths. Whereas, those path are located on the same server under a shared directory and are accessible to all the Authenticated Users in my domain. Any ideas or suggestion please share. Thanks.
Yes! it worked for me using the http:// URL location for the CDP & AIA. Thanks A lot. Now the next challenge is to reissue/renew the Enterprise subordinate CA certificate. I have used the newly generated the certificate request file on one node of my certificate services cluster. Got the certificate generated and copied on the first node and have installed it successfully. But!! Question#1. When I export the certificate from the Personal (certificate store) on first node it doesn�t give me option to export the private key with it? Question#2. When I used the same PKCS.7 file (copied from the Offline root CA) and install the certificate on the second node. It is failing stating that the version number for the current CA is higher or that use the new request file copied in the C:\Cert Request\PKIServer02_CA01.req file to issue the new certificate. I am quite sure that I have issued the certificate for the first node, installed and then exported it to use on the second node of the cluster. (While installing the CA 2008 R2 Failover Cluster). Please suggest a work around with you experiences. Thanks.
you should ask your questions in TechNet forums: http://social.technet.microsoft.com/Forums/en-US/winserversecurity/threads
Thanks, this was good info - and with understandable wording. :)
Hi Vadims, I enjoyed your article and it clears lots of doubts, I also have a problem. I have an environment where i have a standalone offline root CA whith one enterprise sub CA. i see these servers have been migrated two times by other folks and now it seems there AIA and CDP points to non existing locations exept LDAP for enterprise. however enterprise server is working fine for issuance and certs are good with LDAP CDP. now when i am trying to install a new Subca in same hirarchy i am facing issue while installing subca cert on new ca and it gives error while installing and says "Certificate chain can not be veified would you like to ignore and continue." when i click yes. it gives error and Gives RPC server is not available and doesn't start CA service and server certificate is not installed.
I think this can be solved by
1. disabling CRL Verification on new subca but, once disabled can it be enabled?
2. creating a web AIA & CDP on subca and publishing CRL and CRT files and reissuing subca cert and installing again.
can you help
Post your comment:
Comments: