Test lab PKI - The revocation function was unable to check revocation because the revocation server was offline
Hi all, I've installed a lab PKi but am having the following error when I try and start the certificate services service after installing the subordinate CA. "The revocation function was unable to check revocation because the revocation server was offline" Heres how I installed my PKI: installed a standalone root CA installed an enterprise subordinate CA. During installation the certificate request was sent to the root CA using the wizard.On the ROOT CA I approved the certificate requestOn the ROOT CA I exported the certificate to a removable drive. The certificate was exported as a P7B file and had "Include all certificates in the certification path if possible" On the SUBORDINATE CA I right clicked the CA name and selected Import CA certificateTried to start the service. The above error is received. According to my book (The 2008 MCTS self paced training kit) this is enough to start the service however in reality this is not the case. I am running 2008 R2 and not 2008 as the book was written for. Can anyone tell me what is wrong here?
October 17th, 2012 10:12am

You need to provide the subordinate CA with access to the Root CA CRL so it can determine its revocation status. Did you define CDP or AIA references in the subordinate CA to allow for this? If not, have a look here for a good overview: http://blogs.technet.com/b/askds/archive/2009/10/13/designing-and-implementing-a-pki-part-ii.aspx Cheers JJ Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
Free Windows Admin Tool Kit Click here and download it now
October 17th, 2012 2:30pm

Thanks for the reply. I haven't done anything other than what I have described as that's what the book says to do. The book seems to think that those instructions are enough to get the service started however that's clearly not the case. SO I know a very little about CRLs and nothing about AIA. I'm assuming that comes later in the book but as the practice says i should start the service but I can't so i am trying to understand from other means what the correct way is. If I'm looking in the right place, by default the CRL is stored in the file system of the ROOT CA. If I'm meant to take the root CA offline for security, how can the subordinate get the CRL from the root? Not sure if it matters but when I imported the subordinate CA's certificate that I exported form the ROOT CA I got a message as follows: The root certificate is untrusted. Do you wish to trust the root certificate on this machine and complete the installation? A certificate chain processed but terminated in a root certificate which is not trusted by the trust provider. I assume that's because the subordinate doesn't have any information on whether the root is a trusted source.... but how do I make it trusted? I'm very confused!
October 17th, 2012 5:06pm

I would ditch the book and follow the Ask DS Implementing PKI series, it is a great overview and an easy read. As part of implementing the subordinate CA, you define locations where the Root CA certificate and Root CA CRL can be found so the subordinate CA and other machines can check revocation. You then move these elements from the offline Root CA to an online location where it can be network accessed. This is usually a http or ldap location This guide is also a good overview: http://technet.microsoft.com/en-us/library/hh831348.aspx Cheers JJJason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
Free Windows Admin Tool Kit Click here and download it now
October 17th, 2012 5:15pm

Many thanks for your help so far. I've been fighting with certificate services trying to understand them for a week now without really understanding. Now i think I'm getting somewhere. I'll give these links a good read tomorrow but to help me sleep tonight can i just run one thing by you... In a crude manner, these are the steps you would take? Install Root CAInstall Subordinate CA.Create a root CRL and copy the file it generates to a location that is accessible to clients when the root CA is offline.Configure the subordinate CA CRL locations to point to the location (probably a http) where the crl files are kept for the offline Root CA.Start the subordinate CA service. Does that sound about right? One thing I don't know is how the structure of the locations is built. For example, the default CA location for http says http://<serverdnsname>/certenroll. There's no system variable called "serverdnsname" so I only assume its a certificate services specific variable... but what does it mean? How the clients know what to replace that variable with? Finally, there is not a web service installed by default so should i just create an IIS installation to host the CRLs and then create a virtual directory path that matches whatever is set in the extensions tab to point at the CRL location? Still confused... but getting better :)
October 17th, 2012 5:38pm

Did you configure/modify the CDP and AIA locations on the Root CA before you issued the SUB CA certificate?
Free Windows Admin Tool Kit Click here and download it now
October 17th, 2012 8:59pm

No, i left it at whatever was default (as per the book... although there is no mention of configuring these until after installing the subordinate CA). So I'm stuck at how to configure the CRL. You can see a post i made earlier asking questions relating to this.
October 18th, 2012 3:19am

When you create a CA structure you need to make sure everyone consuming certificates (including sub-ca:s) can find AIA and CDP information (AIA = root ca cert, CDP = revocation information) in every certificate issued (except root ca cert). After installing the root but before issuing any certificates you go into Properties -> Extensions on the root CA and define the CDP and AIA extensions. In practical terms you define the places where clients can go to find the root CA certificate and revocation data - a file/HTTP/LDAP URI. Then you need to actually publish the cert and crl to these locations you defined. It's somewhat involved to define them, so I can't practically tell you exactly how to set it up for your environment. But some tips: 1. If your clients are mainly AD-machines define an LDAP path where you publish the data (see the last link below), and make sure this is the first entry clients see in the CDP/AIA fields. AD is fast and highly available by default, but only works for AD clients. 2. If you expect to have many non-AD machines use a HTTP or SMB (file://) URI that is accessible to everyone who needs it. 3. The AIA and CDP fields are not used in CA certs. You should not configure these until after you have issued the root CA cert, and don't be confused when these fields are absent in the root CA cert. http://blogs.technet.com/b/askds/archive/2009/10/13/designing-and-implementing-a-pki-part-ii.aspx http://technet.microsoft.com/en-us/library/jj125369.aspx http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=36 http://beccabits.com/2011/06/06/how-to-publish-rootpolicy-cas-in-active-directory/
Free Windows Admin Tool Kit Click here and download it now
October 19th, 2012 5:03pm

When you create a CA structure you need to make sure everyone consuming certificates (including sub-ca:s) can find AIA and CDP information (AIA = root ca cert, CDP = revocation information) in every certificate issued (except root ca cert). After installing the root but before issuing any certificates you go into Properties -> Extensions on the root CA and define the CDP and AIA extensions. In practical terms you define the places where clients can go to find the root CA certificate and revocation data - a file/HTTP/LDAP URI. Then you need to actually publish the cert and crl to these locations you defined. It's somewhat involved to define them, so I can't practically tell you exactly how to set it up for your environment. But some tips: 1. If your clients are mainly AD-machines define an LDAP path where you publish the data (see the last link below), and make sure this is the first entry clients see in the CDP/AIA fields. AD is fast and highly available by default, but only works for AD clients. 2. If you expect to have many non-AD machines use a HTTP or SMB (file://) URI that is accessible to everyone who needs it. 3. The AIA and CDP fields are not used in CA certs. You should not configure these until after you have issued the root CA cert, and don't be confused when these fields are absent in the root CA cert. http://blogs.technet.com/b/askds/archive/2009/10/13/designing-and-implementing-a-pki-part-ii.aspx http://technet.microsoft.com/en-us/library/jj125369.aspx http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=36 http://beccabits.com/2011/06/06/how-to-publish-rootpolicy-cas-in-active-directory/
October 19th, 2012 5:03pm

Thanks for the reply. Thats a very easy to understand way of putting it. You say the AIA and CRL information is not issues in a root certificate but how do you have control of that? Is that not automatically created during installation?
Free Windows Admin Tool Kit Click here and download it now
October 22nd, 2012 10:54am

No, they only get in there if you specify them in capolicy.inf. If you wanted information in a CA Cert, you'd set it like so: [AuthorityInformationAccess] URL=http://pki.wingtiptoys.com/Public/myCA.crt [CRLDistributionPoint] URL=http://pki.wingtiptoys.com/cdp/WingtipToysRootCA.crl If you want them empty you can do this: [AuthorityInformationAccess] [CRLDistributionPoint] And in 2008 you can omit them entirely, and AIA & CDP will not be present.
October 22nd, 2012 5:26pm

Got it. So another point the book failed to mention then is that the CAPolicy.inf is essential to get a correctly working PKI. What I cant find out is whether this file is only there for the root CA or if you would create one for each issuing CA or not. I assume you would and woudl specifcy the issuing CA's CDP and AIA information.
Free Windows Admin Tool Kit Click here and download it now
October 23rd, 2012 4:43am

It is read whichever type of CA you install. You can control CRL publication intervals etc using CAPolicy.inf, so it's useful for a sub-CA as well. When you install a sub-ca you will get a certificate from the root, and if you've defined AIA and CDP on the root CA they will be added to the sub-ca:s certificate. That's why you should add the AIA and CDP extensions on the root CA after you've set it up. That means the extensions will be present in any issued certificates, but not the root certificate.
October 23rd, 2012 5:19am

Got you. Finally then, What takes precedence? the settings I set in the GUI or the settings details in CAPolicy.inf? Unless I;m getting confused again, the publication intervals are also set in the GUI are they not?
Free Windows Admin Tool Kit Click here and download it now
October 23rd, 2012 5:47am

The CAPolicy.inf settings are read at installation. Anything done in the GUI or through certutil commands take precedence as they are performed after initial installation Whatever is configured in the GUI/registry currently wins Brian
October 23rd, 2012 5:51am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics