ADCS Installation (Part 2): Offline Root CA CAPolicy.inf and post install script
Hello Everyone, Here is my original post for same question: http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/1588cacd-a7a3-41f6-991e-ab2e7c4e6daa?lc=1033&prof=required As my original thread is quite long, I am starting a new thread. My plan is to keep the current installation of ADCS on the offline root CA but the online issuing CA will be re-installed. The offline root CA has been installed with the following CAPolicy.inf: **************************************************************** [Version] Signature= "$Windows NT$" [Certsrv_Server] RenewalKeyLength=2048 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=10 [CRLDistributionPoint] [AuthorityInformationAccess] [LegalPolicy] OID=1.3.6.1.4.1.My_PEN.21.43 Notice = “Legal policy statement text.” URL = “http://www.MyCompany.com/certdata/cps.asp” **************************************************************** I plan to run the following post installation script on the offline root CA: **************************************************************** ::Declare Configuration NC certutil -setreg CA\DSConfigDN CN=Configuration,DC=MyRootDomain,DC=com ::Define CRL Publication Intervals certutil -setreg CA\CRLPeriodUnits 26 certutil -setreg CA\CRLPeriod "Weeks" certutil -setreg CA\CRLDeltaPeriodUnits 0 certutil -setreg CA\CRLDeltaPeriod "Days" certutil -setreg CA\CRLOverlapPeriod "Weeks" certutil -setreg CA\CRLOverlapUnits 2 ::Apply the required CDP Extension URLs 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\n2:http://My-Online-IssuingCA-Server.MyChildDomain.MyRootDomain.com.com/certenroll/%%3%%8%%9.crl" ::Apply the required AIA Extension URLs 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\n2:http://My-Online-IssuingCA-Server.MyChildDomain.MyRootDomain.com.com/CertData/%%1_%%3%%4.crt" ::Enable all auditing events for the Fabrikam Corporate Root CA certutil -setreg CA\AuditFilter 127 ::Set Validity Period for Issued Certificates certutil -setreg CA\ValidityPeriodUnits 10 certutil -setreg CA\ValidityPeriod "Years" :: Enable discrete signatures in subordinate CA certificates Certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1 ::Restart Certificate Services net stop certsvc & net start certsvc sleep 5 certutil –crl ::Copy the Root CA certificates and CRLs to the USB Drive ::Echo Insert the USB Drive in the USB slot ::sleep 5 ::copy /y %windir%\system32\certsrv\certenroll\*.cr? F:\ **************************************************************** As the comment lines show, the script is from Brian Komar's book and I have modified slightly. Comparing with my original post installation script, there are a few more settings defined in it. They are CA\AuditFilter CA\csp\DiscreteSignatureAlgorithm Do I need them for offline root CA? Please check "CA\CRLPublicationURLs" and "CA\CACertPublicationURLs" lines. I hope I have right this time. This forum is great. I appreciate very much for the helps I have received. Thanks in advance. SJJ123
January 8th, 2010 3:39pm

Looks fine, though as a best practice I'd put the HTTP URLs first.Paul Adare CTO IdentIT Inc. ILM MVP
Free Windows Admin Tool Kit Click here and download it now
January 8th, 2010 3:53pm

Your CAPolicy.inf file is incorrect.You will not get any policy OIDs in the root CA certificateYou need to add the Policystatementextension section referencing the LegalPolicy section you have includedI agree with Paul, putting LDAP first is just a PSS case away from being switched to HTTP first when your first non-domain or non-Windows client attempts to validate a certificate.One last thing, change the term DiscreteSignatureAlgorithm to AlternateSignatureAlgorithm.I recently discovered that this attribute name was changed just before RTM and was not communicated to me for the book.Brian
January 8th, 2010 4:32pm

Hi Brian, Thank for your reply. I have moved HTTP before LDAP. Should I reset the DiscreteSignatureAlgorithm first? Certutil -setreg CA\csp\DiscreteSignatureAlgorithm 0 May I assume the following command is correct? Certutil -setreg CA\csp\AlternateSignatureAlgorithm 1 Do I need to add the following section only before [LegalPolicy]? Am I right ? [PolicyStatementExtension] Policies = LegalPolicy Critical = 0 Please let me know what other sections if I must have. As I have installed my root CA. can I correct the OID issue by running some additional script? Anyway, I have run the post installation configuration script. Here are the "CA\CRLPublicationURLs" and "CA\CACertPublicationURLs": **************************************************************** C:\>certutil -getreg CA\CRLPublicationURLs HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\My-Root-Ca\CRLPublicationURLs: CRLPublicationURLs REG_MULTI_SZ = 0: 1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl CSURL_SERVERPUBLISH -- 1 1: 2:http://my-issuing-ca-server.mychilddomain.myrootdomain.com/certenroll/%3%8%9.crl CSURL_ADDTOCERTCDP -- 2 2: 10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10 CSURL_ADDTOCERTCDP -- 2 CSURL_ADDTOCRLCDP -- 8 CertUtil: -getreg command completed successfully. C:\>certutil -getreg CA\CACertPublicationURLs HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\My-Root-Ca\CACertPublicationURLs: CACertPublicationURLs REG_MULTI_SZ = 0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt CSURL_SERVERPUBLISH -- 1 1: 2:http://my-issuing-ca-server.mychilddomain.myrootdomain.com/CertData/%1_%3%4.crt CSURL_ADDTOCERTCDP -- 2 2: 2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11 CSURL_ADDTOCERTCDP -- 2 CertUtil: -getreg command completed successfully. **************************************************************** My root CA is offline (no network) and it is a member of a workgroup. Please let me know whether or not I have correct CDP and AIA settings. Do I need worry about CSURL_ lines? Thanks, SJJ123
Free Windows Admin Tool Kit Click here and download it now
January 8th, 2010 6:21pm

Hello All, If I revised my CAPolicy.inf for my offline root CA as follows: ;**************************************************************** [Version] Signature= "$Windows NT$" [PolicyStatementExtension] Policies = LegalPolicy Critical = 0 [LegalPolicy] OID=1.3.6.1.4.1.My_PEN.21.43 Notice = “Legal policy statement text.” URL = “http://www.MyCompany.com/certdata/cps.asp” [CRLDistributionPoint] Critical = true [AuthorityInformationAccess] Critical = true [Certsrv_Server] RenewalKeyLength=2048 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=10 ;**************************************************************** Does it have any problem? I have not included two more sections from Brian's book example CAPolicy.inf: [EnhancedKeyUsageExtension] and [basicconstraintsextension]. I do not want to restrict my CA to only limited purposes. And my [certsrv-server] section does not have all settings in the example CAPolicy.inf. It looks like that I have to re-install Certificate Services on both offline CA server and online issuing CA server. Thanks, SJJ123
January 8th, 2010 7:43pm

Remove the Critical=true from both the AIA and CDP sections, they are not needed since neither extension will be populated in the root cert.Paul Adare CTO IdentIT Inc. ILM MVP
Free Windows Admin Tool Kit Click here and download it now
January 8th, 2010 8:53pm

Hello, Just re-confirm my understanding. We have 2-tier AD domain structure: MyRootDomain and MyChildDomain . All users and computers for certificates are members of the As my root CA will be offline (i.e., it does not have a network connection plus in a workgroup), I will specify the Comman Name and Suffix for my root CA during its installation: Common name for this CA: MyOffline-Root-CA Distinguished name suffix: DC=MyRootDomain,DC=com However, do I need add MyChildDomain during the installation of my Online Issuing CA server? Common name for this CA: MyOnline-Issuing-CA Distinguished name suffix: DC=MyRootDomain,DC=com My Online Issuing CA server is a member of the MyChildDomain . My understanding is that I should not use MyChildDomain . Can anyone confirm this? Thank you very much. SJJ123.
January 11th, 2010 1:03pm

You're getting what you were told about configuring the ConfigDN vaule with the distinguished name of your CA. There is no relationship at all between your forest/domain names and the DN suffix for your CAs.Paul Adare CTO IdentIT Inc. ILM MVP
Free Windows Admin Tool Kit Click here and download it now
January 11th, 2010 1:12pm

Adding to Paul's response...Most of our customers would never allow exposing the domain construct in a CA certificate (showing the DC= components)Most will use a generalized X.500 name type (OU=PKI,O=Example Corporation,C=TV)Brian
January 11th, 2010 4:30pm

Hi Paul and Brian, In this case, I just specify both CA servers as follows: I will specify the Comman Name and Suffix for my root CA during its installation: Common name for this CA: MyOffline-Root-CA Distinguished name suffix: OU=PKI,O=MyCompanyName,C=UK However, do I need add MyChildDomain during the installation of my Online Issuing CA server? Common name for this CA: MyOnline-Issuing-CA Distinguished name suffix: OU=PKI,O=MyCompanyName,C=UK My company is in UK. I hope they will be all right. Thanks. SJJ123
Free Windows Admin Tool Kit Click here and download it now
January 11th, 2010 5:25pm

You can put whatever you want in the DN suffix of the CA.I prefer using names like you have proposed here (they look fine) as they do not cause controversy about using the DC= extensions and it does not expose your AD strucutre in the name of the certificateBrian
January 11th, 2010 7:47pm

Hi I've followed this thread with much interest as i'm in a similar deployment scenario (offline Root, Enterprise SubCA, etc). I have a few further questions for my own understanding. Won't the AD structure be exposed in the certificate extension, CRL Distribution Points if i'm using an LDAP DP? This being the CRL DP in the Enterprise Sub CA cert. My understand is that this is becuase the DConfigDN registry key of the offline root CA is set to the Forrest_AD_Domain. This is the %6 (or %%6 in cmd scripts) CA variable used in CRL DP definitions which is set to enable manual publishing of offline root CA CRL to AD. The same problem may possibly occur in the subject field of the Enterprise subCA depending on config at installation time. The same AD structure would then be exposed in the Subject & CRL DP fields/extensions in any domain joined end entity certs issued from the Enterprise subCA? I'm just trying to confirm i understand correctly of the potential exposure of my company's AD structure should an issued certifcate (and cert chain) be obtained from say, a lost smart card. Cheers T
Free Windows Admin Tool Kit Click here and download it now
May 18th, 2011 12:21pm

If you are concerned about exposing AD structure, use these rules: 1) Do not use LDAP URLs for AIA or CDP extensions 2) Do not use the LDAP distinguished name in any subjects of the certificate. Use just the common name or use the Subject name module from FIM CM to do a custom X.500 name style 3) Do not use the default subject name presented in the wizard when installing an enterprise or domain-joined standalone CA For what it's worth, I would never deploy today with LDAP URLs from AIA and CDP. The new best practices recommend using a clustered Web resource that is both internally and externally accessible. This means no need to define %6 in your scripts, since it is not used in any URLs Brian
May 18th, 2011 1:31pm

Thanks Brian. your answer was a very helpful. cheers T
Free Windows Admin Tool Kit Click here and download it now
May 25th, 2011 3:19am

This is a timely discussion as I am finalizing CDP/AIA configuration on a PKI and just ran into this. I was going to list HTTP then LDAP in the CDP, since we support varying client OS types. But, it would seem from my research and implied by this discussion that LDAP is not a strict requirement, and the integration is really one of convenience for Windows domain-joined clients. Are the latest best practices found on TechNet that include and expand upon your advice above? Many thanks.
June 13th, 2011 4:47pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics