Windows 2008 CA won't issue Cert

Hi, Windows 2008R2 root CA is not handing out cert renewals.  

Looked ,root cert was near expiration.  So I renewed the root CA, now has 3 years on it.

Failed Request log shows...

revocation server was offline 0x80092013.  

Ran certutil -crl, got

CertUtil: -CRL command FAILED: 0x8007208d (WIN32: 8333)
CertUtil: Directory object not found.

certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

DNS name is unavailable and cannot be added to the Subject Alternate name.  0x8009480f.

I then reset to
certutil -setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

And this is where I am... stuck.

This CA was migrated with MS help from server 2003 to 2008R2 a good time ago.

Thanks in advance for the help!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
Wondering will this be the case - meaning if you try using "certutil -verify -urlfetch <YOURCACERT.CRT>", it shows a whole related error that is likely due to CDP Problem
From MS support: the issuer field of the CA certificate has the CERT_RDN_UTF8_STRING encoding format while the CRL is signed by a certificate which (appears identical but) has the CERT_RDN_PRINTABLE_STRING encoding format
During the certificate chain validation (from the end entity to a trusted root) the KeyId is used to create the certificate chain and it works independently of the subject and issuer codification (PrintableString or UTF8)
During the status validation, a binary comparison is made between the certificate issuer and the CRL issuer, so both field must use the same codification in order to match (PrintableString or UTF8)
We must re-issue and re-publish the CRLs from the Root CA and make sure the encoding of the issuer field matches
Jakob DigranesSenior ConsultantCommented:
try pkiview.msc from RUN - what does it show?
btanExec ConsultantCommented:
can also try the connectivity / DNS resolution problems. For connectivity, try ping requests using IPs. But key is also to make sure that
- the computer name is resolvable via DNS
- the template you are using allows the subject to be supplied in the request (and specify this template when submitting the request)

in fact for troubleshooting, PKI error log can be enabled (though it can be quite noisy)
Enable CAPI2 logging by opening the Event Viewer and navigating to the Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\CAPI2 directory and expand it.  You should see a view named Operational as illustrated in Figure 1.
Most of the revocation check failures are due to a failure in retrieving valid revocation information. In this case, an additional "ErrorStatus" flag "CERT_TRUST_IS_OFFLINE_REVOCATION" is set to indicate that the revocation status of one of the certificates in the chain is offline or is no longer current. This could be because revocation information could not be retrieved or that the information could be retrieved but was invalid.
Results of revocation checking are logged in the "CertVerifyRevocation" event. To find the cause, you need to look at the "CertRejectedRevocationInfo" and "CryptRetrieveObjectByUrlWire" events, which are nested under the "CertVerifyRevocation" event.
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

If you retained 2008 CA server hostname same as 2003, then probably this could be different issue.

Otherwise It seems that u have migrated CA from 2003 server with x hostname to 2008 server with y hostname
Now previously issued certificates having CRL pointing to old 2003 server which is offline, as a fact they are unable to raise certificate renewal request
Have you manually tried renewing existing certificate?
In this case I don't think it will allow you to renew certificates
U have to reissue certificates, and this time before issuing new certificates, make sure you configure http CRL location on CA server with some generic name (http://myca.domain.local) and point it to CA server / another web server in DNS. Now it will get added to issued certificates as http crl point
This will enable you to publish CRL to http location and then you will be ready for feature CA upgrades with different server names / same server names

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jakob DigranesSenior ConsultantCommented:
One thing you could consider. How many certs have you enrolled? What uses?
It might be easier to just install a new Enterprise CA - with new root certs and enroll new certificates.

Though you might be in trouble when decommissioning old CA if there's some problems with it. Then you should dive into the joyful world of ADSI-edit. BTW; there's a technet article describing this.

also - check what errors you have with pkiview.msc
btanExec ConsultantCommented:
overall, better to see specific error to focus troubleshooting pki issues as the error message in display can still be too wide coverage. To add, when a CA is renewed, various objects and attributes will be updated or changed. For CA as Enterprise root CA, the following objects in AD will be updated:

a -The updated CA certificate (cACertificate) and cross-certificate (CrossCertificatePair if renewal with a new key pair is performed) will be published to the AIA container.
b -A new CRL will be published for every key pair the CA has used.
c -The new certificate will be published to the NTAUTH object.
d -The new certificate will replace the existing certificate in the enrollment services container.

Also ky is to re-generate root CA CRL and copied it to the correct location on the subCA e.g. By default, on the server on which the CA is installed, the CRL and delta CRL are published in: Systemroot\system32\CertSrv\CertEnroll\

whoamAuthor Commented:
++On the CA, removed the entry from the configuration partition > services >public key services   ( all the entries apart from the “ServerHostName”  & “CAName” for the CDP )
++Gave permission "full control" on the CDP for the user
++Corrected built-in users and dcom cert access group's membership
++Found the CA cert 2 is not renewed with same key pair.
++Found that under cert 2 CDP path we have given path for old CRL.
++ Removed the old CRL path from extension.

++ Published new path in AD using command - certutil -f -dspublish "path of CRL"

++ On the workstations added cert in trusted store and now it is also corrected.
++ Since we found that we do not have permission to enroll web server template so gave enroll permission on CA on web server template
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.