PKI CRL distribution point - configuring default LDAP server in IIS
I am attempting to integrate IIS 6.0 with an Entrust PKI which issues certificates containing a CDP (CRL distribution point) attribute specifying a relative
LDAP URL along the lines of:
ldap:///CN=CRL1, OU=…, O=…, C=.../certificateRevocationList;binary,authorityRevocationList;binary,deltaRevocationList;binary
Without a server name specified in this URL, IIS attempts to retrieve the CRL from its closest Active Directory server, as described in
http://technet.microsoft.com/en-us/library/cc780454(WS.10).aspx
However the Active Directory server does not hold the CRL, so certificate verification fails with HTTP 403.13. I need to configure IIS to default to a
specific LDAP server name instead - is there any way to achieve this?
I have been able to downloaded the CRLs using certutil into the CRL cache, however this does not seem to help, presumably because the CDP URLs is different.
November 12th, 2010 5:01am
On Fri, 12 Nov 2010 09:56:30 +0000, Alastair Carter wrote:
I am attempting to integrated?IIS 6.0 with an Entrust PKI with certificates issued containing a CDP (CRL distribution point) attribute specifying a relative LDAP URL along the lines of:
ldap:///CN=CRL1, OU=?, O=?, C=.../certificateRevocationList;binary,authorityRevocationList;binary,deltaRevocationList;binary
Without a server name specified in this URL, IIS attempts to retrieve the CRL from its closest Active Directory server, as described inhttp://technet.microsoft.com/en-us/library/cc780454(WS.10).aspx
However the Active Directory server does not hold the CRL, so certificate verification fails with HTTP 403.13.?I need to configure IIS to default to a specific LDAP server name instead - is there any way to achieve this?
I have been able to downloaded the CRLs using certutil into the CRL cache, however this does not seem to help, presumably because the CDP URLs is different.
You cannot configure IIS to retrieve a CRL from a specific location as IIS
simply makes calls to the crypto engine in the underlying OS which reads
the CRL location from the certificate it is attempting to validate.
You have two choices here:
1. Make sure that the CRL is replicated to all domain controllers.
2. Configure Entrust to use include an absolute URL in all issued
certificates and then reissue the certificates.
For number 2 you're going to have to consult an Entrust support resource.
Paul Adare
MVP - Identity Lifecycle Manager
http://www.identit.ca
Free Windows Admin Tool Kit Click here and download it now
November 12th, 2010 5:15am
Thanks for the reply.
I understand the Windows crypto engine reads the CRL from the certificate and this is not modifiable, but because the hostname itself is not part of the CRL - it is a default assumed by Windows - I had expected that it would be configurable. I would
expect it is normal in any non-Microsoft PKI that CRLs reside on a server other than the Windows domain controller?
November 12th, 2010 10:48am
On Fri, 12 Nov 2010 15:43:50 +0000, Alastair Carter wrote:
I understand the Windows crypto engine reads the CRL from the certificate and this is not modifiable, but because the hostname itself is not part of the CRL - it is a default assumed by Windows - I had expected that it would be configurable.
It is not. The 3rd "/" in LDAP:/// is replaced automatically by any domain
controller in the forest. If you want to specify a domain controller or
some other LDAP server then you need to do so when the certificate is
issued, you cannot do so after the fact.
? I would expect it is normal in any non-Microsoft PKI that CRLs reside on a server other than the Windows domain controller?
You'd need to check with Entrust on how to configure this.
Paul Adare
MVP - Identity Lifecycle Manager
http://www.identit.ca
Free Windows Admin Tool Kit Click here and download it now
November 12th, 2010 11:14am
Anyone experiencing the same problem may find the following alternative solution useful where your CRLs must be obtained from a server other than your Windows domain controller.
Rather than leaving IIS to fetch CRLs based on the CDP, it is possible to import a CRL that has been downloaded to the filesystem into the Windows Certificate Store using the .NET CertMgr.exe (http://msdn.microsoft.com/en-us/library/e78byta0.aspx).
Once a valid CRL is in the certificate store, IIS will validate CRLs using it rather than attempt to fetch a new CRL from the CDP. Since my CRLs were also available on a HTTP location I created a script to run as a scheduled job and download the CRLs then
import using CertMgr periodically.
February 8th, 2011 11:34am
If the CRLs were available via an HTTP location, why not just reference that HTTP location in the CDP extension of issued certificates and have that extension appear *above* the LDAP URL (or even drop the LDAP URL).
This is the preferred way of doing this. All that you have done is come up with a way to pre-stage the CRL into the client's cache.
This would have been done by the client from the HTTP URL.
Brian
Free Windows Admin Tool Kit Click here and download it now
February 8th, 2011 12:43pm
Brian,
Unfortunately that was not possible because we have been integrating with an existing PKI where thousands of users have been issued with certificates with a relative LDAP CDP, rather than creating a new PKI from scratch. Certainly it would have been preferable
if those certificates were issued with a HTTP CDP but for whatever reason these certificates were designed and issued without one, long before we came along and re-issung the entire organisation with new certificates was not an option!
In this situation, this pre-staging the CRL appears to be the only way of loading the CRLs...
Alastair
February 9th, 2011 3:56am