Hi, I have an internal CA set up with a CRL CDP. Generally I produce certificates which contain the CDP, however I am presented with a situation where I need to produce a certificate which will not contain the CDP. In essence the certificate would contain no mention of CRLs, CDPs etc. How can I do this? Is it possible? Cheers, Lun

Can you please elaborate on the scenario? It is possible with the Server 2008 R2 CA to issue a a certificate without revocation information. - It is only possible for V2 or V3 certificate templates issued by a Server 2008 R2 CA - It is really intended for OCSP response certificates (you do not want to check revocation status on a signed response identifying revocation status Brian

It is possible with Windows Server 2003/2003 R2/2008 too. These CAs will require some custom workflows (manual operations). However I agree with Brian, can you provide business scenario example for this task?My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Hi, The Root CA is 2008 Enterprise edition SP2. From a business perspective, the provider of a service (on ServerA) requires Mutual Authenticated SSL. The certificates we generate, from our internal CA, all have an LDAP CRL. So ideally we generate a certificate for the client which we deploy on the server(ServerA). Unfortunately, the server (ServerA) to which this certificate will be deployed has no access to the AD that contains the CRL. The obvious solution would be to allow access from ServerA to AD, however that is not possible. Another solution would be to modify the server to exclude CRL checks - again not possible. So this is possible. Any handy links? Many thanks, Lun

in this case you need to configure HTTP URL in the CDP extension. If your company has publically accessible web server, you can manually (or automatically) publish CRLs to this network location (share on web server) and configure corresponding HTTP URL for this file (you can use either virtual directory or dedicated web site). Also if this HTTP URL is accessible for internal clients too, you may change URL priority so HTTP URL is processed first and LDAP is processed only if HTTP fails.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Hi Vadims, The business won't let a solution come in the way of a good problem! We can't give access via HTTP or LDAP - which leads to the initial problem of how to geberate a certificate without the CDP. Many thanks, Lun.

Still would advice to find a more convenient workaround. For example, purchase a certificate from 3rd party commercial CA (StartCom looks like the cheapest).My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

In addition, depending on how the certificate is used, you will just have a failed certificate with the error "cannot determine revocation information" rather than a working certificate. This is *not* a valid scenario. Certificates are public information as are CRLs. If you want to work with a partner, you *must* publish revocation information to the Internet or to a shared network Brian

Hi, This is for a certificate that will be used *internally*. For exteral and partner use - we purchase cetificates from a commercial 3rd party. We have a very tightly zoned network, tightly managed AD and this, coupled with a poor architecture, leads to an an uncomfortable position. So coming to the original question: Is is possible to generate certificates from a Root CA (2008 Enterprise edition SP2) without a CDP? The answer would appear to be a qualified 'yes' ; I can't quite see how to do it so any information/links would be really helpful. >In addition, depending on how the certificate is used, you will just have a failed certificate with the error "cannot determine revocation information" rather than a working certificate. This will bs used for MASSL ith the server on IIS7, we will get this error when the CDP is unreachable; if there is no CDP then IIS is quite happy with the certificate. >This is *not* a valid scenario. Certificates are public information as are CRLs. If you want to work with a partner, you *must* publish revocation information to the Internet or to a shared network True - to a point, and I think that depends on your usage. These certs are used internally and are not public information. Thanks, Lun

Good luck with that. This is not proper use of PKI and the answers provided should be followed Brian

As Brian is said, this wouldn't work. I've played with non-self-signed certificates (V3) without CDP extension. Applications (for example TS/RDS/VPN/etc) mostly reject this certificate. Also you are going to a very slippy way. Since this certificate don't contains revocation information it is not possible to determine whether certificate keys are not compromised. This is one of the PKI fundamentals that you should not break. Ok Root CA certificates don't contains CDP extension, but in this case special security measures are taken (server is isolated from the network is stored in a secure room, key pair is protected by HSM and so on). Obviously you cannot guarantee the same security measures and assurance level for your certificate and server. Trust me, you need *valid* solution (as I or Brian have suggested). My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Hi, Totally understand that PKI needs CRLs and 101% agree with everything you have said. My preferred solution is that we should supply both http and LDAP access points for the CRL. My hands, unfortunately, are tied. In the end we are stuck. If there is a dcumented way to do this, then I'd be highlighting it as an exception which, in essence, renders the use of such certs as useless. We have used openssl to produce certs without a CDP and we have verified that these will allow MASSL (on IIS) to work quite happily. >Trust me. ...of course I do :) Thanks, Lun

Not sure if this is documented (this scenario and related walkthroughs), but there are several low-level API's that can do this.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

On Tue, 26 Apr 2011 15:19:03 +0000, Lunar2000 wrote: The obvious solution would be to allow access from ServerA to AD, however that is not possible. Another solution would be to modify the server to exclude CRL checks - again not possible. If your application requires CRL checking and you're unable to disable such, then a certificate with no CDP should fail the verification process. If you're application doesn't in fact perform CRL checking, then the presence or absence of a CDP location in the cert should be irrelevant. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca Foolproof operation: All parameters are hard coded.