I realized how involved this whole process was and am currently reading Brian Komar's book on the subject (which is awsome by the way), but I'm still confused about the basics of certificate revocatation. I googled this, but I am still lost.I know this is a pretty elementary question, but if I have a 3 tier PKI with an offline root and policy CA and an online issuing CA and I want to revoke a certificate that the issuing CA issued to an end user will I be able to do that from the Issuing CA or will I have to bring the root and policy CA online in order to revoke the certificate? If I can do this from the Issuing CA then does the root and policy CA need to know about this? In that they need to see the CRLs of all CAs below them in the hierarchy?Thanks for any responses

> I want to revoke a certificate that the issuing CA issued to an end user will I be able to do that from the Issuing CA or will I have to bring the root and policy CA online in order to revoke the certificate?you MUST perform certificate revocation on the CA that was issued particular certificate.> If I can do this from the Issuing CA then does the root and policy CA need to know about this?no. They maintain only their own CRLs and they can revoke only those certificates that was issued by themselves.> In that they need to see the CRLs of all CAs below them in the hierarchy?still no.For additional info please read this:http://blogs.technet.com/pki/archive/2009/11/07/certificate-revocation-checking-whitepaper.aspx http://www.sysadmins.lv

Awsome thanks for the quick response. I got it now.

I have another question about this. Why do I need cdp and AIA extensions in my offline CAs?In virtually all sources I have found for installing an offline stand alone root and policy CA I see something that confuses that ____ out of me.Assuming my stand alone and policy CAs are offline and I have a policy in place to NEVER let them touch the network (all CRL updates are done via sneaker-net) then why do I see in every deployment tutorial something akin to the following script run after I install the root CA: ::Apply the required CDP Extension URLscertutil -setreg CA\CRLPublicationURLs “65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://www.fabrikam.com/CertData/ %%3%%8%%9.crl"::Apply the required AIA Extension URLscertutil -setreg CA\CACertPublicationURLs “1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://www.fabrikam.com/CertData/%%1_%%3%%4.crt"If I am going to do all of my publishing manually for my top tier CAs then why do I have to add these extensions? I'm guess this is because these extensions are required by an RFC or something and prior to installing certificate services CApolicy.inf was configured to exclude them- but I'm pretty sure I'm wrong in thinking that.

To answer this question you need to understand some things. Lets go.For example we have 2-tier CA hierarchy. And some client want to validate any certificate that was issued by 2-nd level CA. At first client tries to build a certificate chain. Client MUST find a CA certificate that issue particular end-certificate. At first it searches this certificate in local store (in Intermediate and Trusted Root CAs container). If 2-nd level CA certificate is not found in local stores client extract URLs from end-certificate AIA extension to download CA certificate from network. In this example we see that if client is unable to find any CA certificate, it uses AIA extensions to locate it. In any certificate AIA extension contain URLs to download parent CA certificate that issued this particular certificate. Because root certificate is last certificate in the chain and is self-signed there is no any parent CAs and root CA never contains AIA extension.The same process occurs when revocation checking is perfomed. CDP extension contains URLs to parent CA CRL file. As sayed each CA maintain their own CRL and CDP extension MUST exist in each CA certificate. However root CA is present as self-signed certificate and due of some reasons cannot revoke himself, therefore root CA certificate never contains CDP extension.In short: CDP and AIA extensions contain URL for parent CA CRL/CRT files respectively. And remember that this doesn't matter if any CA is online or offline, because certificate chaining engine (CCE) don't differ them. In online CAs case there is no additional steps required to publish CRLs and CRT files. However if you implement offline CAs you SHOULD manually turn on servers and manually publish new CRLs or/and (if CA certificate is renewed for any reason) CRT file. And copy these files to any removable media such USB flash or CD-R disks. After this you MUST copy these files to web servers (or network share) to allow clients to download these files using web servers. If you use LDAP URLs, you also MUST to publish them in AD using 'certutil -dspublish' command.Hope this helps. Please let me know if something is still unclear for you.http://www.sysadmins.lv

Ok so I an offline root and intermediate CA and an online issuing CA.I have the following policy in place:Whenever a CRL is published by the root it is to be copied to a usb drive and brought manually to the policy CA.Whenever a CRL is published by the policy CA it is to be copied to a usb drive and brought manually to the issuing CA.The issuing CAs CRLs are automatically published to a directory on a webserver access by client PCs.Why do I need extensions in my policy CAs certificate? A common procedure has you remove CDP and AIA extensions via the CApolicy.inf when installing the root CA, BUT after doing so the script I posted is run add extensions on to the certificates that the root CA issues. Why should I have to do this if my policy CAs (the only certs that the root will be issuing) are going to be offline?Thanks for the response, I still trying to understand this :).

You have a very common misconception. When you configure the capolicy.inf on the root CA, you are defining that there is no AIA or CDP extension in the **Root CA Certificate**. In you post installation script, you do define what the AIA and CDP path are for the **certificates issued by the root CA**. (If you have not, many applications, including smart card logon will never work).So, the missing parts in your description.Whenever a CRL is published by the root it is to be copied to a usb drive and brought manually to the policy CA. It is also manually copied to a directory on a webserver access by client PCs and referenced in the AIA and CDP extension of the certificate issued *to* the policy CA.Whenever a CRL is published by the policy CA it is to be copied to a usb drive and brought manually to the issuing CA. It is also manually copied to a directory on a webserver access by client PCs and referenced in the AIA and CDP extension of the certificate issued *to* the issuing CA.The issuing CAs CRLs are automatically published to a directory on a webserver access by client PCs.If you look at the output of certutil -verify -urlfetch leaf.crt where leaf.crt is a certificate issued by the issuing CA, you will see this process in full.Hope this helps.Brian

Ah, yeah I think I got this now. I know I must have read an explaination of this before, but it never stuck. After reading Vadmins post I reviewed how the CCE works again too and I understand why these extensions are nessesary. What confused me was how the whole heirarchy worked with regards to CRL checking. Thanks.

I have a pretty elementary question about some architecture that I was going to post in a new thread, but I figured it would make more sense just to include it here... I would like to implement the following architecture and I'm curious if its not a poor design. As I stated before what I would like to setup up is a 3 tier PKI with offline root and policy CA and then an online enterprise CA- BUT because the enterprise CA will also be the web server hosting the CDP and AIA extensions, which will be using AD integrated DNS, the offline CAs won't be able to publish to it so the extensions will have to point to a non-networked directory. Essentially I don't want a externally execessable webserver hosting the extensions because all certs will be private use only. So my question then is if I do all of the CRL publishing to removable media and then bring it manually to the online CA will CRL checking be a problem for clients?

no, there shouldn't be any problems, because AD clients automatically search and download all PKI objects in Certification Authority, CDP and AIA containers to local stores. Since clients tries to search necessary certificates and CRL in local stores first, revocation check for clients will be pretty quick. However this just works for internal (within your forest) clients only.http://www.sysadmins.lv

no, there shouldn't be any problems, because AD clients automatically search and download all PKI objects in Certification Authority, CDP and AIA containers to local stores. Since clients tries to search necessary certificates and CRL in local stores first, revocation check for clients will be pretty quick. However this just works for internal (within your forest) clients only. So this isn't quite correct. The only thing that clients will download automatically from AD are root certs. Anything else will be downloaded as needed. So it is imperative that your AIA and CDP locations for the root and policy CA be correct. Which means, if you're publishing them to AD then the AIA and CDP locations need to be pointing to AD, and of course the web server, which given your design should be listed first.Paul Adare CTO IdentIT Inc. ILM MVP

I have a pretty elementary question about some architecture that I was going to post in a new thread, but I figured it would make more sense just to include it here...I would like to implement the following architecture and I'm curious if its not a poor design.As I stated before what I would like to setup up is a 3 tier PKI with offline root and policy CA and then an online enterprise CA-BUT because the enterprise CA will also be the web server hosting the CDP and AIA extensions, which will be using AD integrated DNS, the offline CAs won't be able to publish to it so the extensions will have to point to a non-networked directory. Essentially I don't want a externally execessable webserver hosting the extensions because all certs will be private use only. So my question then is if I do all of the CRL publishing to removable media and then bring it manually to the online CA will CRL checking be a problem for clients? Why 3 tiers? What is the business driver for doing a policy layer?Paul Adare CTO IdentIT Inc. ILM MVP

no, there shouldn't be any problems, because AD clients automatically search and download all PKI objects in Certification Authority, CDP and AIA containers to local stores. Since clients tries to search necessary certificates and CRL in local stores first, revocation check for clients will be pretty quick. However this just works for internal (within your forest) clients only. So this isn't quite correct. The only thing that clients will download automatically from AD are root certs. Anything else will be downloaded as needed. So it is imperative that your AIA and CDP locations for the root and policy CA be correct. Which means, if you're publishing them to AD then the AIA and CDP locations need to be pointing to AD, and of course the web server, which given your design should be listed first. Paul Adare CTO IdentIT Inc. ILM MVP does this mean, that if I publish CRL from VeriSign in my AD, clients will never find it (none of VeriSign certificate contain CDP extensions with my AD forest LDAP URLs)?http://www.sysadmins.lv

It means that your clients won't find the Verisign CRL by going to your directory to get it, they will go to whatever CDP location is listed in the certificate they've been presented with. In the case of Verisign, this will be an HTTP location on the web.Paul Adare CTO IdentIT Inc. ILM MVP

thanks. I have missed this point.http://www.sysadmins.lv

Looking to Brian's book (p.406) the only containers that are automatically downloaded by clients are:1) root CAs (Certification Authorities)2) Cross CAs (certificates with filled crossCertificatePair field in AIA container)3) NTAuthCertificatesis this correct?http://www.sysadmins.lv

Yes.Paul Adare CTO IdentIT Inc. ILM MVP

Well again awesome responses. I had no idea how professional and helpful the community forum was. First to answer Paul's question of why I chose to put together a full blown three tier PKI- well its defiantly NOT suitable or appropriate for our environment. This is actually a lab I'm setting up to test and learn on. I felt it'd be a good learning experience to understand various deployment options- I'm also a geek so I'm interested in the complexity involved. My main problem was that I wanted to get around having to setup another externally accessible web-server, that's not on my windows domain, to use as a dedicated host for CRTs and CRLs. I already have a web-server that is on the domain and not accessible by computers which are not on the domain and would prefer to use this one (I no this is not very scalable). Is there an elegant way to do this or is it just not possible/never a good idea? When I try to publish CRLs on the root CA (which has extensions pointing to the internal web-server) it fails and I assume this is because it is trying to access the internal web-server (which it cannot). I though it would just skip over the inaccessible locations in the extensions and just publish to the local HDD, but it appears that it fails completely. I would assume this is by design? Thanks for answering all of my dense questions!

> My main problem was that I wanted to get around having to setup another externally accessible web-server, that's not on my windows domain, to use as a dedicated host for CRTs and CRLsthis would be a good idea. Because you can maintain your HTTP urls for both domain and non-domain users and is accessible from internet.> When I try to publish CRLs on the root CA (which has extensions pointing to the internal web-server) it failscan you show error message? Windows CA cannot publish physical files to web server directly using HTTP urls. There are only supported types for file publishing:1) using absolute local path, such: c:\windows\system32\certsrv\certenroll\file.cer2) using network share, such: file://fileserver/share/file.cer3) using LDAP publishing, such LDAP://{ldap_path}physical file publishing points are not necessary to appear in certificate extensions. Therefore for file publishing you MUST use any supported way and directly accessible by CA (by selecting Publish CRL and Publish Delta CRL to this location). And make sure if these paths are directly accessible by CA server.> I though it would just skip over the inaccessible locations in the extensions and just publish to the local HDD, but it appears that it fails completely. I would assume this is by design?please, can you show your CDP extensions? Looking at http://msdn.microsoft.com/en-us/library/cc226710(PROT.10).aspx (section 8), server MUST try to publish Base CRL to each specified location. the only exception is for Delta CRLs: If, for a delta CRL and a location that begins with "file://", the publishing of the corresponding base CRL has resulted in the CPF_FILE_ERROR flag value being set, do not attempt to publish the delta CRL to the file:// location. Generate an error instead.<48> If, for a delta CRL and a location that begins with "ldap:///", the publishing of the corresponding base CRL has resulted in the CPF_LDAP_ERROR flag value being set, do not attempt to publish the delta CRL to the ldap:/// location. Generate an error instead.<49> but I assume that this is not your case. http://www.sysadmins.lv

The error message I get when trying to publish is: The specified server cannot perform the requested operation. 0x80070003a (WIN32: 58) --------------------------------------------------------------------------------------- In event viewer: Event Type: Error Event Source: CertSvc Event Category: None Event ID: 65 Date: 12/31/2009 Time: 2:19:57 PM User: N/A Computer: CAROOT Description: Certificate Services could not publish a Base CRL for key 0 to the following location: ldap:///CN=LAB Industries,CN=caroot,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=LAB,DC=com. The specified server cannot perform the requested operation. 0x8007003a (WIN32: 58). For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. ------------------------------------------------------------------------------------------------- The script I'm using (from Komar's book). I looked it over many times so if this is a fat finger problem I'm going to feel very stupid: ::Declare Configuration NC certutil -setreg CA\DSConfigDN CN=Configuration,DC=LAB,DC=com ::Define CRL Publication Intervals certutil -setreg CA\CRLPeriodUnits 26 certutil -setreg CA\CRLPeriod "Weeks" certutil -setreg CA\CRLDeltaPeriodUnits 0 certutil -setreg CA\CRLDeltaPeriod "Days" ::Apply the required CDP Extension URLs certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://cdp.LAB.com/CertData/%%3%%8%%9.crl" ::Apply the required AIA Extension URLs certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://cdp.LAB.com/CertData/%%1_%%3%%4.crt" ::Enable all auditing events for the LAB Corporate Root CA certutil -setreg CA\AuditFilter 127 ::Set Validity Period for Issued Certificates certutil -setreg CA\ValidityPeriodUnits 10 certutil -setreg CA\ValidityPeriod "Years" pause

> CN=Configuration,DC=LAB,DC=commake sure if LAB.COM is forest root domain.http://www.sysadmins.lv

I not sure what you mean exactly. LAB.COM is the correct domain for my networked computers, but the CA is offline and is not able to access these PCs. This was the problem I thought- because locations in my extensions (LDAP and HTTP) are NOT accessible by this CA (HTTP location is pointing to a web server that is on the LAB.COM domain and DNS is AD integrated) publishing should not work right? Tell me if I am misunderstanding something.

WHat he means is that the Configuration naming context is associated with the forest root domain, and must reference that it in its LDAP path. ALso, you can never automatically publish from an offline CA to the directory. It requires sneakernet. Then from a domain member you would run the certutil -dspublish commands. If you are referencing a child domain (as we suspect), the publication fails. You must reference the forest root domain in the Configuration naming context pathBrian

if you have single forest with single domain and offline CA then there are several things:1) CRL/CRT retrieval points (that are used by clients when they build chains) for particular CA are not necessary to be accessible by this CA. Only file publishing points MUST be accessible.2) in your case you MUST deselect the following check-boxes in CA configuration:'Publish CRLs to this location' and 'Publish Delta CRLs to this location' for LDAP urls. Instead you will HAVE TO publish them manually.3) if your CA publishes LDAP urls in AIA extension of issued certificates you MUST modify registry by following command:certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://cdp.LAB.com/CertData/%%1_%%3%%4.crt"this will prevent CA to attempt to publish CA certificate file to LDAP. Instead you will HAVE TO publish them manually.4) to publish these files you MUST copy each CRL and CRT files to removable media and move them to any domain computer. Log on to domain computer with Enterprise Admins rights and run these commands:certutil -dspublish path\*.crl "CA sanitized name"certutil -dspublish path\file.crt RootCAcertutil -dspublish path\file.crt SubCAcertutil -dspublish path\file.crt NTAuthCAhttp://www.sysadmins.lv

Ok I believe I know where I went wrong in my understanding. But I still have questions about the AIA extensions... Using the following script I changed the CRL publishing location to the local CAs HDD: certutil -setreg CA\CRLPublicationURLs "65:%systemdrive%\CertEnroll\%%3%%8%%9.crl\n14:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://cdp.LAB.com/CertData/%%3%%8%%9.crl" And hey, problem solved, but... AIA extensions are still publishing to the LDAP directory and they don't cause problems: certutil -setreg CA\CACertPublicationURLs "1:%systemdrive%\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://cdp.LAB.com/CertData/%%1_%%3%%4.crt" Why this is still working for me: n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\- in "3:ldap///CN..." the "3" should be 1:"Publish CRLs to this location " and 2:"Include in the AIA extension of issued certificates", the LDAP directory is still not accessible yet publishing goes through ok, shouldn't it fail like it did when I set this flag in the CDP extensions? Also when I look at AIA extensions in the GUI there is no option to "Publish CRLs to this location " AND to ask another question why is this even an option with AIA extensions? Why is there this CRL publishing option when these are AIA extensions? Thanks in advance, I hope I'm not abusing this thread by bloating the heck out of it :)

We deployed a three tier infrastructure with an offline root and offline intermediate (aka policy) CAs, and in hind sight I regret it, we lost our virtual root ca, and had to rebuild the entire thing, also setting up the AIA and CDP paths was a nightmare, not to mention doing manual updates of the CRls every 6 months. The three tier approach sounds great on paper but it is a complete overkill in practice. PKI is such a complex and misunderstood concept that the simpler you keep it the better off you will be and chances are the more use you will get out of it. Think about it you are going from a username/password environment to using certificates, you will have to deal with certificate templates, auto enrollment, etc, etc, why would you want to over complicate things. If I had to do it all over again I would build a single server CA solution, online and AD integrated, and use that for our internal certificates because anything public facing is better off with a commercial certificate such as the ones you can buy from Verisign, if for no other reason than for the simple fact that the Verisign Root CA is already in your trusted root CAs store, and your home grown is not on everyone's computer in the world.