How to publish a CRL for an internal Windows certification authority?
You will need to modify your CA's CRL locations via the Certification Authority snap-in. Right-click on the CA, select 'Properties', then the Extensions tab. Select the 'CRL Distribution Point' extension and add the needed locations.
Full instructions are located on Technet: http://technet.microsoft.com/en-us/library/ee649168(WS.10).aspx
Unfortunately, the CRL paths are 'wired' to the issued certs, so if you already have certs that have been previously issued, they will need to be reissued. Just create a new certificate template that supersedes the old one and configure your machines to autoenroll.
Related videos on Youtube
![Massimo](https://i.stack.imgur.com/fGz6O.jpg?s=256&g=1)
Massimo
"Against stupidity, the Gods themselves fight in vain." https://www.linkedin.com/in/massimo-pascucci
Updated on September 18, 2022Comments
-
Massimo almost 2 years
I have an Active Directory domain with an Enterprise Root Certification Authority in it; the domain uses a private domain name ("domain.local"), and we also have a public domain name ("domain.com"). The domain contains the following servers:
- dc1.domain.local (Domain Controller)
- dc2.domain.local (Domain Controller)
- ca.domain.local (Certification Authority)
- exchange.domain.local (Exchange 2010)
- fw.domain.local (TMG 2010 firewall)
The firewall has two network interfaces, a private one and a public one, and a bunch of public IP addresses; it's also the default gateway for the internal network. It publishes the Exchange server's web services using the public name "mail.domain.com", and it also acts as a SSTP VPN server, using the public name "vpn.domain.com". All the involved certificates have been issued from the internal CA. This is ok, because all computers which will ever use this domain's services are supposed to trust the internal CA's certificates.
What I need is to publish the internal CA's Certificate Revocation List, because otherwise the Windows SSTP VPN client complains about not being able to check it (I know this can be fixed using a Registry key, but it's difficult to manage globally).
I have issued a certificate containing the two names "ca.domain.local" and "ca.domain.com", I've configured it in the CA's IIS and on the TMG firewall, and I've published the internal CA's web site with the public URLhttps://ca.domain.com
.
But here's the catch: how can I tell the CA to write down in its certificates that its CRL can be found athttp://ca.domain.com/SomePath
, other than athttp://ca.domain.local/SomePath
, which is the default configuration?And also: since this information is embedded in each issued certificate, if I change it, will I need to re-issue them, so that whoever checks them knows where their CRL can be found?
-
Brennan about 12 yearsThis answer, although accepted, is actually a deprecated answer because it promotes the use of CRLs for validation.
-
Ashmeet Singh about 12 yearsI understand that OCSP is the successor to CRLs, but I have to admit that I don't have any experience in using the service with Windows. Rather than down voting my answer, how about providing a solution using OCSP instead? That way, you can enlighten the rest of us!
-
Brennan about 12 yearsUnfortunately, Stackoverflow Meta says to do otherwise :(
-
murisonc about 12 years@ Brennan - Quote from Meta "One thing you have to consider here, and this has been brought up times before, is that deprecated or not, people might well be lumbered with such 'legacy version' technologies, and require the solution fitting for such - and, therefore, they have a deserved place."
-
Ashley almost 11 years@Brennan Considering Microsoft's own articles currently describe the use of CRLs and nothing else, I'm not sure it is valid to just dismiss this answer as invalid without providing other solutions.