Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

1 Answer

up vote 4 down vote accepted

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.

share|improve this answer
    
This answer, although accepted, is actually a deprecated answer because it promotes the use of CRLs for validation. –  Brennan Apr 17 '12 at 21:28
4  
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 '12 at 23:27
    
Unfortunately, Stackoverflow Meta says to do otherwise :( –  Brennan Apr 18 '12 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 '12 at 14:46
2  
@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 Steel Aug 13 '13 at 11:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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