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 URL https://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 at http://ca.domain.com/SomePath, other than at http://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?

1 Answer 1


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.

  • This answer, although accepted, is actually a deprecated answer because it promotes the use of CRLs for validation.
    – Brennan
    Apr 17, 2012 at 21:28
  • 5
    I 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!
    – newmanth
    Apr 17, 2012 at 23:27
  • Unfortunately, Stackoverflow Meta says to do otherwise :(
    – Brennan
    Apr 18, 2012 at 0:29
  • 2
    @ 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."
    – murisonc
    Apr 18, 2012 at 14:46
  • 3
    @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.
    – Ashley
    Aug 13, 2013 at 11:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.