nacAdmin
asked on
Microsoft AD Certificate Services CRL quirk?
Hello,
We have a newly deployed Active Directory Certificate Services infrastructure setup, and are trying to work out some kinks. Our setup consists of two severs (Windows 2008 R2 Datacenter) running in a 2003 forest / domain. The Root CA is standalone / offline, and the Issuing CA is online (domain member / integrated) to issue certificates and serve revocation lists.
We had an issue last week where we noticed certificate requests failing due to the Root CA revocation list not being valid (aka - expired). We resolved this by flipping over to the Root CA, and executing "CERTUTIL -CSR 455:00", publishing a CRL file, and then copying that CRL onto the Issuing CA server's CDP (an http URL on the Issuing CA server).
Well, I just looked at the Root CA's CRL file on the Issuing CA server, and the CRL's "Next Update" property was for this morning. I thought to myself... 'did we actually not copy that CRL over?'... So I copied the CRL over from the Root CA once more (verifying beforehand that its "Next Update" property was for some time in August of 2015).
Once I placed this file in the CDP (again - on our Issuing CA server), and looked at its properties, the "Next Update" property immediately changed to this Sunday - July 13, 2014.
It seems as though the CRL validity period imposed by the Issuing CA server trumps what the Root CA put in the CRL file; so while we *want* the Issuing CA to have a more rapid CRL update cycle, that cycle is what is imposed on the Root CA CRL - which we *don't* want.
Now... not sure exactly how to resolve this - without tearing everything down and re-creating Root certificates / Issuing CA certificates, and using a separate CDP for the Root CA's CRL / CDP (maybe on a small *nix box or something)...? Do-able, but hopefully there is an easier path?
Thanks in advance!
~D
We have a newly deployed Active Directory Certificate Services infrastructure setup, and are trying to work out some kinks. Our setup consists of two severs (Windows 2008 R2 Datacenter) running in a 2003 forest / domain. The Root CA is standalone / offline, and the Issuing CA is online (domain member / integrated) to issue certificates and serve revocation lists.
We had an issue last week where we noticed certificate requests failing due to the Root CA revocation list not being valid (aka - expired). We resolved this by flipping over to the Root CA, and executing "CERTUTIL -CSR 455:00", publishing a CRL file, and then copying that CRL onto the Issuing CA server's CDP (an http URL on the Issuing CA server).
Well, I just looked at the Root CA's CRL file on the Issuing CA server, and the CRL's "Next Update" property was for this morning. I thought to myself... 'did we actually not copy that CRL over?'... So I copied the CRL over from the Root CA once more (verifying beforehand that its "Next Update" property was for some time in August of 2015).
Once I placed this file in the CDP (again - on our Issuing CA server), and looked at its properties, the "Next Update" property immediately changed to this Sunday - July 13, 2014.
It seems as though the CRL validity period imposed by the Issuing CA server trumps what the Root CA put in the CRL file; so while we *want* the Issuing CA to have a more rapid CRL update cycle, that cycle is what is imposed on the Root CA CRL - which we *don't* want.
Now... not sure exactly how to resolve this - without tearing everything down and re-creating Root certificates / Issuing CA certificates, and using a separate CDP for the Root CA's CRL / CDP (maybe on a small *nix box or something)...? Do-able, but hopefully there is an easier path?
Thanks in advance!
~D
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
This will ensure that all issued certs including subordinate CA by root ca will have above CRL points
You have to bring the root CA online to:
Publish an updated root CA crl.
To issue or renew a subordinate CA certificate
To revoke a subordinate CA certificate.
Check below articles
http://marckean.wordpress.com/2010/07/28/build-an-offline-root-ca-with-a-subordinate-ca/
OR
http://www.rickygao.com/configuring-an-offline-root-ca-with-2-tier-pki-hierarchy/
Mahesh.