[Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 806
  • Last Modified:

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
0
nacAdmin
Asked:
nacAdmin
1 Solution
 
MaheshArchitectCommented:
Ideally you should publish CRL and AIA for offline root ca prior to install subordinate CA, on some web server which will be online for all the time (It can be sub ca server) OR in active directory with long enough validity and then you could issue new sub CA cert.
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.
0
 
Jakob DigranesSenior ConsultantCommented:
is the servers licensed and activated?
Just went through an installation with 2012 sever where the CRL for the issuing CA was only one week even though we set it in CMD and verified that it had been set to 104 weeks.
after license was added and server activated - we republished CRL for issuing ca (from root CA) and all was good.
rememeber that the ROOT Cert should NOT have any CRL or AIA information, but the issuing CA should have. The CRL and AIA from the ROOT CA is for verifiying that the issuing CA is still valid - thus only needing update rarely. To publish new CRL from offline root .- this needs to be put online and publish CRL - copy it to the issuing CA and publish via CMD
0

Featured Post

When ransomware hits your clients, what do you do?

MSPs: Endpoint security isn’t enough to prevent ransomware.
As the impact and severity of crypto ransomware attacks has grown, Webroot has fought back, not just by building a next-gen endpoint solution capable of preventing ransomware attacks but also by being a thought leader.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now