Certificate server will not start

Check this artikel: http://technet.microsoft.com/en-us/library/bb331963.aspx

What is the revocation server is the CA?

The revocation function was unable to check revocation because the revocation server was offline.   This status message indicates that the revocation server for the certificate could not be reached. In some cases, this is a temporary error because the revocation server is malfunctioning. Otherwise, make sure that this computer can access the revocation server. If there is a firewall or proxy server in between this computer and the revocation server, make sure that your computer is configured to traverse the obstacle.
For more information, see How to Enable PKI on the Edge Transport Server for Domain Security

The ca service will not start

I suggest getting the pkiview tool to check the health of your PKI.  This  
tells you about the accessibility of the CA chain elements.  It's in one of  
the resource kit tools bundles.  You can download the bundle from MS.  See  
the following link:


http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

The pkiview tool can not find the ca chain becauase the ca service will not start

I presume this a subordinate CA?  Sounds like it is having trouble finding the CRL from one of the CAs above it.  Its own CRL would only affect the certs that it issued.

Since the root CA (and any middle-tier / intermediate CAs, e.g. Policy server) tends to be offline, it is not unheard of to forget to cut a new CRL and push it to the appropriate CDP locations.  View the details tab of the CA cert and look for the CRL Distribution Point and check that the CRL at all those locations is current - normally only one needs to be valid, however.  Usually it gets to all or none with the offlines (i.e. it was done or it wasn't).

If this is a 3+ tier PKI, make sure to check other non-root CA certs for the same as I mentioned above as well - if it cannot properly verifiy the entire chain, including higher tier CAs, then the validation will fail the same regardless of which tier is having the issue.  The root CA normally will not have a CDP defined in its own certificate since it is self-signed.

Hi Paranormastic,

Thanks for the information, I am very new at the CA, this was bulit by a person who has left us.

what is a subordinate CA and what do you mean to forget to cut a new CRL and push it to the approritate CDP locations? does this need to be done on occasion?


I folowed your instructions and i see 3 entries

i attached a scrren shot, is this the proper format?


Thanks

as you can see, not much experiance in this area.

All - I had to remove this attachment because it displays sensitive information from the Asker.
 
Vee_Mod

Select allOpen in new window

Hi Paranormastic,

I was able to get the service started by editing the registry Ca loglevel from 3 to 2, when i run pkview i see 2 CDP errors(attached)
When i open these certs it does read certificate revocation list information.

Thanks

All - I had to remove this attachment because it displays sensitive information from the Asker.  Vee_Mod

Select allOpen in new window

any thoughts?

Try accessing each of the CRL Distribution Points (CDP).  Check the date on the CRL.

If pkiview is showing errors, it can be for one of two reasons:
1) The CRL is expired.
2) The CDP is unavailable from the location that you are checking it from (internal vs. external link)

If the CRL is expired, you need to make a new one from each of the CA servers.  

Alternatively, you can open up Certification Authorities MMC on your workstation - accept the error message since you aren't running a CA on your desktop - Right click certification authority - retarget certification authority - browse - the list here will show you the names of all the online CAs in your infrastructure.  Select one and repeat the following for each.

You can view the existing CRLs if you expand the CAName listing - right click Revoked Certificates - properties - View CRLs tab.  Note the expiration dates are shown here.

You can create a new CRL by right-clicking the same Revoked Certificates folder - All Tasks - Publish.  This will create a file with .crl extension in %systemroot%\system32\certsrv\certenroll directory.  You will need to copy this to all the CDP locations that you can see in PKIview.

Back within the Cerification Authorities MMC, right-click the CAName - properties.  On the default General tab click View Certifiate button.  This will show you the CA's own certificate.  On the Certification path tab, you will see if there are any CAs above it.  If this is the only certificate listed, double check on the Details tab by verifying that the Subject name and the Issuer name match exactly.

If there is another CA cert above it on the Cert Path tab, then double click that - see if it matches any of the other listings from above when we browsed to list all the CA's when retargeting the CA MMC - if so, go to that one next and repeat above - also copy these higher CA CRLs physically into the same certenroll folder on the lower CA server.  Repeat again in case there are multiple tiers.

In a PKI, there is always a Root CA - this is the top and needs to be trusted by any software that deals with certs.  This should be kept offline (off the network, usually not joined to the domain) for security reasons, but often it is online unfortunately.  In smaller companies it is common for the root CA to issue certs directly to users, so it would be online, but in a proper PKI it would only handle signing the certificates of subordinate CA servers.  The root/subordinate relationship is something like a parent/child relationship.  The sub CA will usually be online and usually joined to the domain except in certain cases.  

You can also create a .bat script to run under scheduled tasks so this doesn't happen again.  The command you need in the .bat file is 'certutil -crl'  then map a drive to each CDP location and copy *.crl from the certenroll directory path to each CDP.


This gets a little technical and isn't common, so you can probably skip this unless you are really interested...  Sometimes there is a 3rd tier that is inbetween that is technically still another subordinate, but is usually referred to as the Intermediate CA or Policy CA - this is for higher end PKI where they have extensive documentation and tend to be cross-certified - the cross-certification tends to occur at the Policy level. This Policy CA is normally kept offline as well.  Cross certification is similar in concept to transitive forest trusts.  For larger commercial organizations such as banking, and governments will tend to do this more where there is a hub and spoke style system where there is a centrally managed hub known as the bridge authority that declares the rules that all trusted CAs need to adhere to - the various agencies, etc. will then declare their own policy with the minimum rules of the bridge in mind (sometimes there may be multiple governing documents) and are audited to show that they are in compliance, then the bridge will sign the agency's cert with their policy CA and the agency will sign the bridges cert with their policy CA.  Since there are multiple agencies that all trust the bridge, they now trust each other.

Hi Paranormastic,

Not much luck PKIView still shows the ROOT CA CDP Location #1 expired(htp), CDP location #2 (ldap) unreacheable.
Shoud a root CA be reachable? The subordinate CA shows okay.

Thanks

Hi Paranormastic,

When i look in the revoation list it is empty should it be?
If the ROOT Ca is off line as it should be would it show to be disabled using Pkview?
thie red X's, expired is only the 2 CDP locations for the ROOT CA is this normal?

Thanks

also how do i do this(below)
Since the root CA (and any middle-tier / intermediate CAs, e.g. Policy server) tends to be offline, it is not unheard of to forget to cut a new CRL and push it to the appropriate CDP locations.  View the details tab of the CA cert and look for the CRL Distribution Point and check that the CRL at all those locations is current - normally only one needs to be valid, however.  Usually it gets to all or none with the offlines (i.e. it was done or it wasn't).

Hi Paranormastic

any thoughts on the above?

Thanks

The root CA should normally be offline - however its CRL and certificate must be available.

Unless you have actually revoked any certs from your root, the CRL should be empty aside from next publication date, etc. type info relating to the CRL itself.  Normally you would have an online issuing CA and that would probably have some things in its CRL since it is issuing more so you would maybe revoke some certs here and there from that.  It is normal for the root CRL to be empty unless you retired a sub CA.

So you have the CDP locations from PKIview - ignore the thing you were wondering about.  Take the locations from pkiview and copy the root's CRL to these locations.

to issue a new CRL, on the root CA issue the cmd:
certutil -crl

Then browse to %sytsemroot%\system32\certsrv\certenroll
and copy *.crl
Since is offline you probably want to copy this to floppy, flash drive, etc.

Copy the CRL from the removable media onto the sub CA into the same directory (certenroll)
Then you can copy from the sub CA to the CDP locations from PKIview.  For the LDAP one, use this command:
certutil -dspublish FILENAME.crl

May take a few minutes for it to replicate throughout AD for the LDAP one.

Hopefully you know how to track down the location to copy the CRL to the other URL to - it should be on a web server somewhere.

Paranormastic

I have the root.cer on removable media not the .crl. How do i convert this to a crl and cdp?


If it is even posible.

thanks

You cannot convert a .cer to a .crl or a CDP.

The .crl is the CRL (Certificate Revocation List) file that is generated from the CA.  I gave instructions above (cerutil -crl) on how to do this.

The CDP is the CRL Distribution Point - this is a network location (or multiple locations) where the CRL is expected to reside (the CDP is not a file, it is a location).  PKIView.msc will show you the path(s) to where the CRL is supposed to be.  Determine what server that is and the file location to the path specified and copy the .crl file there.  For the LDAP location, see my previous post.

When i create the CRL from the root .cer using the command (cerutil -crl)  it has the same expired date on the CRL April 18th.

Do i need to do this on a seaparte Ceritificate Server that the root ca was created, on to do this, seaprate from the sub ca certifacte server?

If this does not work i will award the points and recreate the certificate server if i can not get the CDP location to be unexpired.


thanks

Also note that the newfilename.crl will need to end up with the exact same name as the original CRL, typically including capitalization, before copying to the CDP locations.

Hi Paranormastic,

Finally Success, We ended up getting the ROOT Ca(VM) from the ex staff member. When we started it we then copied the CRL from the root on to a cd om. Then we copied it to the Sub CA server and now the PKI shows the http is fine, the ldap is stil showing not able to download, but per your instructions you only need one to work i believe.

Thaks for you help and patience

Excellant, thanks again

yes, only one needs to work, but if something is only able to access LDAP then you may need that.  Anyways, the base command to do that is 'certutil -dspublish filename.crl'

great, i will do that also.

thanks again