I'm preparing a small PKI implementation with a single Enterprise Root CA on Windows 2008 R2 Enterprise. The primary role of this CA is to provide certificates for about 20 laptops that will use the certificates for authentication to a wireless network. I have prepared a CAPolicy.inf file and a post installation script (below). Renewal period for the root cert should be 10 years, CRL publication every 2 days with Delta publication every 12 hours (details in scripts below). * I want to make sure the AIA and CRL url commands are correct. Does this look correct? AIA 1:%WINDIR%\System32\CertSrv\CertEnroll\%%1_%%3%%4.crt This should publish the CA certificate to the local file system "certenroll". * 2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11 This places the LDAP url in the AIA extension of issued certs. * I am not planning to use HTTP, hence its absence. * CRL 1:%WINDIR%\System32\CertSrv\CertEnroll\%%3%%8%%9.crl This publishes the CRL to the local file system ("certenroll" subfolder). * 10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10 Indicates CDP in AD DS and includes CDP url in issued certificates. ########################################## Complete scripts ########################################## 1. CAPolicy.inf - %windir% [Version] Signature= "$Windows NT$" [certsrv_server] renewalkeylength=2048 RenewalValidityPeriodUnits=10 RenewalValidityPeriod=years CRLPeriod = days CRLPeriodUnits = 2 CRLDeltaPeriod = hours CRLDeltaPeriodUnits = 12 LoadDefaultTemplates=0 2. Install Role Follow steps in GUI here 3. Run post-install script certutil -setreg CA\DSConfigDN CN=Configuration,DC=mydomain,DC=local certutil -setreg CA\CRLPeriodUnits 2 certutil -setreg CA\CRLPeriod "days" certutil -setreg CA\CRLDeltaPeriodUnits 12 certutil -setreg CA\CRLDeltaPeriod "hours" certutil -setreg CA\ValidityPeriodUnits 10 certutil -setreg CA\ValidityPeriod "Years" certutil setreg CA\CACertPublicationURLs "1:%WINDIR%\System32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11" certutil setreg CA\CRLPublicationURLs "1:%WINDIR%\System32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10" certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1 certutil -setreg CA\AuditFilter 127 net stop certsvc & net start certsvc certutil -crl Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

Hi, Regarding Scripting issue, I suggest we seek help in our script forum: http://social.technet.microsoft.com/Forums/en-US/ITCG/ There you can get more effective suggestion by other experts who familiar with this topic. Your understanding is appreciated. Regards Kevin

Hi, Regarding Scripting issue, I suggest we seek help in our script forum: http://social.technet.microsoft.com/Forums/en-US/ITCG/ There you can get more effective suggestion by other experts who familiar with this topic. Your understanding is appreciated. Regards Kevin

A couple of things (just a quick glance) 1) CAPolicy.inf Everything looks fine in this file. You will have a 2 day base crl and 12 hour delta CRLs. No default templates are loaded, so you must manually designate all published certificates 2) Post install Script a. Best practices are to use HTTP only, not to use LDAP, so your whole design does not follow best practices. Furthermore, if you issue a certificate to a single, non-domain joined machine, they will be unable to evaluate your certificates. If you decide to do VPN (or use an internal SSL cert on an externally accessible Web server), revocation checking will fail because you do not publish AD to the external world b. Will you be issuing 10 year certificates from the CA. These lines: certutil -setreg CA\ValidityPeriodUnits 10 certutil -setreg CA\ValidityPeriod "Years" define the maximum validity period of certs issued *by* the CA. For example, if a certificate template states 4 years, then a four year will be issued (less than 10 years). If a template state 12 years, then the max age will be 10 years. Think of it as a governor. c.CACertPublicationURLs . This should include an HTTP URL, and if you want to still include LDAP, HTTP should be prior to the LDAP URL. d. CRLPublicationURLs. This should include an HTTP URL. If you want to still include LDAP, HTTP should be prior to the LDAP URL. Your checkbox value for the LDAP URL is incorrect as well. For a CA that issues both base and delta CRLs, you must have a value of 79 (all check boxes enabled). Your current configuration would fail for revocation checking because you do not publish the base or delta CRL to AD. There is another check box missing (I believe the one to include the URL in the base CRL's freshest CRL extension (how to find the delta CRL). e. Do not include the DiscreteSignatureAlgorithm line in the script. If you have any Windows XP clients, they will not be able to use the certs (BTW, this should have been AlternateSignatureAlgorithm in my book - where you sourced your scripts). This would only be used on a CA where you used something like Elliptical Curve as the assymetric algorithm and SHA384 as the signature algorithm). f. The restart line should be net stop certsvc && net start certsvc. The double && ensures that the service comes to a complete stop before the start command is executed. HTH, Brian

Thanks Brian! Your comments are much appreciated. Yes, the scripts are utimately sourced from your "PKI and Certificate Authority" book although what I have above is directly based on my experiments with a two-tiers CA hierarchy from several months ago. That may be the source of discrepancies with settings better suited for a single level CA "hierarchy". In particular, I see (on page 144) where "79" precedes the CRL LDAP location. I'll revise my script above based on those settings. * b. Will you be issuing 10 year certificates from the CA? No. I was planning for a 10 year certificate for the root CA and then something like 5 for the issued certificates. So it looks like I would only need "5" for that setting. * a. Best practices are to use HTTP only, not to use LDAP, so your whole design does not follow best practices. Yes, I realize that non-domain members could never check the CRL, nor could external users, domain members or not, because our organization does not have an internal web server (or a web server in the DMZ) for this purpose. We do have a website but that is hosted by a third party and completely dissociated with our Active Directory domain. The CA really is only for internal Active Directory domain members - in particular company owned laptops that need to access our wireless network. That's the only reason I'm configuring the CA - RADIUS authentication (with certificates deployed via Group Policy) is preferable from a management perspective than WPA-PSK. Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

Thanks Brian! Your comments are much appreciated. Yes, the scripts are utimately sourced from your "PKI and Certificate Authority" book although what I have above is directly based on my experiments with a two-tiers CA hierarchy from several months ago. That may be the source of discrepancies with settings better suited for a single level CA "hierarchy". In particular, I see (on page 144) where "79" precedes the CRL LDAP location. I'll revise my script above based on those settings. * b. Will you be issuing 10 year certificates from the CA? No. I was planning for a 10 year certificate for the root CA and then something like 5 for the issued certificates. So it looks like I would only need "5" for that setting. * a. Best practices are to use HTTP only, not to use LDAP, so your whole design does not follow best practices. Yes, I realize that non-domain members could never check the CRL, nor could external users, domain members or not, because our organization does not have an internal web server (or a web server in the DMZ) for this purpose. We do have a website but that is hosted by a third party and completely dissociated with our Active Directory domain. The CA really is only for internal Active Directory domain members - in particular company owned laptops that need to access our wireless network. That's the only reason I'm configuring the CA - RADIUS authentication (with certificates deployed via Group Policy) is preferable from a management perspective than WPA-PSK. Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

Other than what we've already discussed (external users and non-domain members) why would HTTP be preferred to LDAP for the publication of the CRLs? I'm looking at some other discussions right now: http://social.technet.microsoft.com/Forums/en/winserversecurity/thread/f7f9129c-0a7b-43ee-b86f-7154c2748c69 20% external users there. 0% for me. * http://www.aspfree.com/c/a/Windows-Security/Implementing-a-PKI-Part-III-Managing-Microsoft-Certification-Services/ Replication latency will not be an issue: single site (one building), both domain controllers connected to same switch. Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

Other than what we've already discussed (external users and non-domain members) why would HTTP be preferred to LDAP for the publication of the CRLs? I'm looking at some other discussions right now: http://social.technet.microsoft.com/Forums/en/winserversecurity/thread/f7f9129c-0a7b-43ee-b86f-7154c2748c69 20% external users there. 0% for me. * http://www.aspfree.com/c/a/Windows-Security/Implementing-a-PKI-Part-III-Managing-Microsoft-Certification-Services/ Replication latency will not be an issue: single site (one building), both domain controllers connected to same switch. Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

Per the white paper on Troubleshooting Revocation Checking (written by myself and Yogesh Mehta) As the authoritative source, I stand by the whitepaper. http://technet.microsoft.com/en-us/library/ee619783%28v=ws.10%29.aspx Brian

Thanks once again Brian. I don't dispute that what is recommended is indeed best practice, or necessary for implementations more complex than mine, but question whether it is necessary, the LDAP option seeming perfectly functional from what I can see.Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

Thanks once again Brian. I don't dispute that what is recommended is indeed best practice, or necessary for implementations more complex than mine, but question whether it is necessary, the LDAP option seeming perfectly functional from what I can see.Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

I disagree. While you state *today* that you plan to only use certs for internal use, one day, you will need to use certs for applications like VPN, and then you have to modify your entire infrastructure. Remember, when you design a PKI, you must design for *all* certificate usages. Today, when I design PKIs for any size of customers - I use only HTTP URLs - I never use LDAP URLs - I make sure that the HTTP URL is available both internally and externally (or provisions are in place to make the URL available at a later date - I make sure that the HTTP URL is a CNAME that can be redirected to a load balancer at a later date Brian

I disagree. While you state *today* that you plan to only use certs for internal use, one day, you will need to use certs for applications like VPN, and then you have to modify your entire infrastructure. Remember, when you design a PKI, you must design for *all* certificate usages. Today, when I design PKIs for any size of customers - I use only HTTP URLs - I never use LDAP URLs - I make sure that the HTTP URL is available both internally and externally (or provisions are in place to make the URL available at a later date - I make sure that the HTTP URL is a CNAME that can be redirected to a load balancer at a later date Brian

Remember, when you design a PKI, you must design for *all* certificate usages. Why all? For VPN, OK. If we decide we want to create a cert for that in-house rather than acquire one from a 3rd party. That's conceivable at least. But there is NO chance our organization would be creating code, let alone signing code. Imagine a small law firm. They might want to secure their wireless network internally but will never be signing code. They may, or may not use, or ever use, a VPN. Nowadays, more and more data is stored in the Cloud so VPN access into the (main) office may not be an issue. Maybe they're using Office 365 for the better part of their operations. But let's say, for arguments sake, that we do have to modify our "entire" infrastructure. Let's say we either place an IIS server in a sort of DMZ or allow access to an internal web server. Or whatever. What would stop you from adding the appropriate HTTP URL at that point? Sure, the coordinates would obviously not be valid for previously issued certs but why not for certs issued afterwards? Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

Remember, when you design a PKI, you must design for *all* certificate usages. Why all? For VPN, OK. If we decide we want to create a cert for that in-house rather than acquire one from a 3rd party. That's conceivable at least. But there is NO chance our organization would be creating code, let alone signing code. Imagine a small law firm. They might want to secure their wireless network internally but will never be signing code. They may, or may not use, or ever use, a VPN. Nowadays, more and more data is stored in the Cloud so VPN access into the (main) office may not be an issue. Maybe they're using Office 365 for the better part of their operations. But let's say, for arguments sake, that we do have to modify our "entire" infrastructure. Let's say we either place an IIS server in a sort of DMZ or allow access to an internal web server. Or whatever. What would stop you from adding the appropriate HTTP URL at that point? Sure, the coordinates would obviously not be valid for previously issued certs but why not for certs issued afterwards? Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

Let's agree to disagree I, personally, will never deploy any future PKIs with LDAP only URLs Good luck to you when the managing director buys a MAC and cannot use your certs to connect to the wireless network! <G> Good luck when the BYOD device team states that they will support iPhones, iPads, Android devices Good luck trying to stand up and change the PKI environment at that point Forward looking is important, you do not seem to see the point BTW, by all possible usages, I mean all future uses that could be used by your network. No where did I state Code Signing :-( Brian

Let's agree to disagree I, personally, will never deploy any future PKIs with LDAP only URLs Good luck to you when the managing director buys a MAC and cannot use your certs to connect to the wireless network! <G> Good luck when the BYOD device team states that they will support iPhones, iPads, Android devices Good luck trying to stand up and change the PKI environment at that point Forward looking is important, you do not seem to see the point BTW, by all possible usages, I mean all future uses that could be used by your network. No where did I state Code Signing :-( Brian