CA will not start... What do you mean, cannot download CRL...Frank Breedijk
- I installed my Issuing CA and generated the certificate request
- I issued the request to my Root CA and generated the Issuing CA certificate
- I tried to install the Issuing CA certificate and got the following error:
Cannot verify certificate chain. Do you whish to ignore the error and continue? The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2168885613)
My first reaction was to call one of the network guest and notify him that I needed http access to the Issuing CA to the CDP location. But whil on the phone, I decided to try and to my surprise I was actually able to manually pull down the crl. Intregued, I decided to check a few things:
- I could download the CRL from both CDP locations with Internet Exporer
- I could open the downloaded CRLs
- I could telnet to port 80 of the both webservers
- I could telnet to port 80 manually issue the GET /crl/CRLname.crl HTTP/1.0 command and get data back
PKI view shows "Unable To Download" for both CDP locations
This did sent me on a wild goose chase:
- Microsoft own documentation, clearly blames it on unavailability of the CDP location, something I, by now, had triple checked four times and refused to believe
- This "Network Builders" forum and many others, simply suggest to turn off revocation checking, but that is clearly not a worthy solution either.
- Apparently there is also an issue with serving delta CRLs threw IIS because the + sign at the end of the basename of a delta CRL file leads to so called "double escaping". I could rule this out by looking at the IIS logs.
- In the end this technet forum post, about OCSP reponders Brian Komar points out:
But, as stated, I would use certutil to get the "best" answer on how is my configuration. Certutil -verify -urlfetch "certfile.cer" will check *every* CDP and AIA URL (including OCSP) and tell you how they are all doing *at that specific instance in time" since it goes to the URLs immediately. Brian
I exported the Issuing CA certificate from the certificate database of the Root CA and ran the command against is and this is what I found
E:\>certutil -verify -urlfetch <certfile>.cer Issuer: CN=Root CA Subject: CN=Issuing CA Cert Serial Number: 115d5f6400020000000b <snip> ---------------- Certificate AIA ---------------- Verified "Certificate (0)" Time: 0 [0.0] http://IIS1.domain1local/crl/Root-CA.crt Verified "Certificate (0)" Time: 0 [1.0] http://IIS2.domain1.local/crl/Root-CA.crt ---------------- Certificate CDP ---------------- Wrong Issuer "Base CRL (13)" Time: 0 [0.0] http://IIS1.domain1.local/crl/Root-CA.crl Wrong Issuer "Base CRL (13)" Time: 0 [1.0] http://IIS2.domain1.local/crl/Root-CA.crl <snip> E:\>
So while PKI view and the other error messages I was getting all pointed to the most common cause, it actually turned out that the CRl did get downloaded, but was not cryptographically relevant to what the system believes is the Root CA certificate. Root causeInspection of the CRLs generated and the Root certificates installed showed what had caused the problem. In order to test the CDP extensions I had reissued the Root CA certificate, causing the Root CA to have three active certificates. Each with a
This CA has three CA certificates
When validating the Issuing CA certificate, validation would end at the last certificate issued, however the CA still signs its CRLs with the key pair of the first certificate. I guess for me there is nothing left but to reinstall the entire chain.