Solved

Certificate server will not start

Posted on 2009-05-05
24
2,318 Views
Last Modified: 2012-05-06
Hi Experts,

I can not start our CA service, Windows 2003, we recieve this error.

Certificate Services did not start: Could not load or verify the current CA certificate.  [Admin Edit - actual name removed]  Issuing CA 1 The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).


Thanks
0
Comment
Question by:talltree
  • 14
  • 8
  • 2
24 Comments
 
LVL 4

Expert Comment

by:rslangen
ID: 24306908
0
 

Author Comment

by:talltree
ID: 24307789
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
0
 

Author Comment

by:talltree
ID: 24307925
The ca service will not start
0
 
LVL 4

Expert Comment

by:rslangen
ID: 24313369
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
0
 

Author Comment

by:talltree
ID: 24313672
The pkiview tool can not find the ca chain becauase the ca service will not start
0
 
LVL 31

Expert Comment

by:Paranormastic
ID: 24315458
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).
0
 
LVL 31

Expert Comment

by:Paranormastic
ID: 24315483
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.
0
 

Author Comment

by:talltree
ID: 24317036
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

Open in new window

0
 

Author Comment

by:talltree
ID: 24318619
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

Open in new window

0
 

Author Comment

by:talltree
ID: 24328997
any thoughts?
0
 
LVL 31

Expert Comment

by:Paranormastic
ID: 24369345
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.
0
 

Author Comment

by:talltree
ID: 24380778
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
0
Get up to 2TB FREE CLOUD per backup license!

An exclusive Black Friday offer just for Expert Exchange audience! Buy any of our top-rated backup solutions & get up to 2TB free cloud per system! Perform local & cloud backup in the same step, and restore instantly—anytime, anywhere. Grab this deal now before it disappears!

 

Author Comment

by:talltree
ID: 24478708
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).
0
 

Author Comment

by:talltree
ID: 24499180
Hi Paranormastic

any thoughts on the above?

Thanks
0
 
LVL 31

Expert Comment

by:Paranormastic
ID: 24521548
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.
0
 

Author Comment

by:talltree
ID: 24669568
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
0
 
LVL 31

Expert Comment

by:Paranormastic
ID: 24683894
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.
0
 

Author Comment

by:talltree
ID: 24688208
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
0
 
LVL 31

Accepted Solution

by:
Paranormastic earned 500 total points
ID: 24739051
Two things:
1) Check the expiration date of the root cert... maybe that expired on April 18th?  If so, you can renew using 'certutil -renewcert' note that you will need to re-sign your sub CA cert and reissue all your other certs if the root expired, but then all the other certs would have expired on the same date anyways.

2) Try using this to re-sign the CRL:
certutil -sign filename.crl newfilename.crl 90:00
(the 90:00 is 90 days:00 hours - adjust as desired)
This should be done on the CA that has the private key for signing the CRL.
0
 
LVL 31

Expert Comment

by:Paranormastic
ID: 24739060
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.
0
 

Author Comment

by:talltree
ID: 24796455
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
0
 

Author Closing Comment

by:talltree
ID: 31578105
Excellant, thanks again
0
 
LVL 31

Expert Comment

by:Paranormastic
ID: 24804892
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'
0
 

Author Comment

by:talltree
ID: 24806530
great, i will do that also.

thanks again
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

#Citrix #Citrix Policies #XenDesktop #VDI #POC #Citrix Univeral Printer Driver #Citrix UPD
Technology opened people to different means of presenting information, but PowerPoint remains to be above competition. Know why PPT still works today.
The viewer will learn how to use the =DISCRINV command to create a discrete random variable, use this command to model a set of probabilities and outcomes in a Monte Carlo simulation, and learn how to find the standard deviation of a set of probabil…
How to install and configure Citrix XenApp 6.5 - Part 1. In this video tutorial we have explained step by step installation of Citrix XenApp 6.5 Server on Windows Server 2008 R2 is explained in this video. We have explained the difference between…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now