Hi, I'm getting one single error in my PKIView console and that is a simple typo where the published LDAP location is ldap:///CN=NEW-RootCA,CN=AIA,CN=PublicKey%20Services,CN=Services,CN=Configuration,DC=domain,DC=internal And the actual location of the LDAP crt file (confirmed using AD Explorer) is ldap:///CN=NEW-RootCA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=internal I'm lost in the woods here and really can't find at what part of the process of implementing this PKI I'd been through setting that location, isn't it in the Root Cert? If so - I've corrected the location in the Root Offline CA, but how do I get that information out to the rest of the Enterpise PKI? Do I need to certutil -renewcert to get the new certificate out there? If that is the case, I have done this , but the Certsrv\Certenroll directory is now populated with 3 new .crt files, as such :- hostname_NEW-RootCA.crt This is the original The new three are hostname_NEW-RootCA(0-1).crt hostname_NEW-RootCA(1).crt hostname_NEW-RootCA(1-0).crt What's the score with these new files? I'm getting myself in more of a mess as things go on, I'm simply trying to fix one thing and I'm ending up with more problems - or questions - depends on which way you look at it. Sorry I'm not learned enough on the subject to understand all these intricacies, it does seem rather convoluted to me. Kind Regards Paul.

Normally after fixing things up in the CAPolicy.inf file, the registry, or CA settings (as appropriate for your scenario) you would issue the command "certutil -renewcert reusekeys" - this would keep the same keyset so you wouldn't have to worry about breaking the CA signature. Here is a generic article regarding renewing CA certs: http://technet.microsoft.com/en-us/library/cc740209%28WS.10%29.aspx As for the numbering, the article I'm used to referring people to would be this one: http://msdn.microsoft.com/en-us/library/aa376550%28VS.85%29.aspx However, that does not address your scenario with the (0-1), etc. To be honest, I'm not exactly sure what you have going on here. I would be curious as to how your AIA locations are configured. Usually it just appends (1) on the first renewal, (2) on the second, etc. (see article above for specifics). Having (1) and (1-0) really confuses me, even if there were something introduced to separate the key renewal vs. the cert renewal for that key (e.g. 1-0 representing key renewal 1 - original issue, 0-1 representing orginal key - 1st renewal), although I'm not aware of any new feature like this but I haven't gotten as much time as I would like to yet in order to play around with 2008 R2.

This configuration can be seen both in the CA managment console, and in registry. Open Certification Authorities and right click the CA and choose properites. Find Extension and choose AIA from the drop down box (default is CDP). Here you will find the LDAP path. The trick is here...when setting up a root dont define AIA and CDP info in the CAPolicy.inf file. Define AIA and CDP in the CA managment console, or in the registry (either by regedit or certutil). This will give the subordinate a CDP and AIA location, but leave the root certificate blank. This is good practise if you have an offline root CA. So there are to ways to set CDP and AIA information, either in CAPolicy.inf prior to installing the CA. This will put the AIA and CDP infromation when the CA certificate is generated. Note this only applies if you are installing a root CA or another standalone CA. If you are installing a subordinate CA, it is the CDP and AIA information of the CA in the chain above (then what is defined in the CA managment console or registry) the subordinate that will controll what is entered in the CDP and AIA field of that certificate. Hope this makes things a bit clearer. I think the 0-1, 1, 1-0 are cross certificates so one can have trust across chains (correct me if I'm wrong). Regards Morten

Hi Morten, Seems the kind MSFT moderator has marked the replies given here as answers.. Isn't that my job? :( Anyhoo.. My capolicy.inf file looks like this for the Root CA and is placed in %WINDOWS% [Version] Signature=$Windows NT$ [certsrv_server] RenewalKeyLength=2048 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=15 CRLPeriod=weeks CRLPeriodUnits=26 CRLOverlapPeriod=weeks CRLOverlapPeriodUnits=2 CRLDeltaPeriod=days CRLDeltaPeriodUnits=0 DiscreteSignatureAlgorithm=1 This doesn't contain any CDP or AIA locations right? The CRL entries don't affect anything to do with the CDP/AIA locations do they? My post Root CA configuration script looks as so ::Declare Configuration NC certutil -setreg CA\DSConfigDN CN=Configuration,DC=domain,DC=internal certutil -setreg CA\DSDomainDN "DC=domain,DC=internal" ::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,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n2:http://www.domain.com/certdata/DOMAINRootCA.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://www.domain.com/certdata/DOMAINRootCA.crt" ::Enable all auditing events for the DOMAIN Root CA certutil -setreg CA\AuditFilter 127 ::Set Validity Period for Issued Certificates certutil -setreg CA\ValidityPeriodUnits 7 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 certutil -crl ::Copy the Root CA certificates and CRLs to the published folder C:\publish copy /y %windir%\system32\certsrv\certenroll\*.cr? C:\publish This is the NEW post Root CA configuration script, the issue I have is that I believe the orginal script didn't insert the space between 'public' and 'key' in this string ldap:///CN=NEW-RootCA,CN=AIA,CN=PublicKey%20Services,CN=Services,CN=Configuration,DC=domain,DC=internal Bear in mind that in my directory, using ADExplorer from sysinternals I can see that the information is there that needs to be downloaded, simply the AIA location for the Root CA is incorrect with the lack of space between 'Public' and Key in the ldap string as mentioned above. Do you have any further thoughts on how to modify the AIA location for the Root CA when the locations already been set? Regards Paul.

The thread here is very much the same thing as i'm experiencing http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/bdfdce41-b910-413d-aa6a-5e39a1d49823 It looks like it might actually be easier for me to start from scratch again, no? I haven't employed Group Policy to deploy certificates yet and I'm only using a certificate on one meaningless webserver, though my issuing CA's are production DC's. I'll look into this further before I trash and rebuild the CA hierarchy. It's one offline Root and two Issuing CA's FYI. Regards Paul

On Tue, 27 Jul 2010 15:04:26 +0000, Paul_WWF wrote: Do you have any further thoughts on how to modify the AIA location for the Root CA when the locations already been set? It isn't the root CA cert you need to be concerned with, it is the subordinate CA(s) and the end-entity certs that you've already issued. Depending on how many tiers you've got, you're going to have to: 1. For a 3-tier - reissue (renew) the policy CA cert making sure that you've got the correct AIA location in the registry on the root CA. For a 2-tier, skip to step 2, for a 3-tier continue with step 2. 2. Renew the issuing CA cert making sure that you've got the correct AIA location in the root CA's registry (for a 2-tier). For a 3-tier renew the issuing CA cert making sure that you've got the correct location in the policy CA's registry. 3. Renew all end-entity certs making sure that you've got the correct AIA locations in the issuing CA's registry. The bottom line here is that the AIA (and CDP) locations that get added to issued certs are read from the registry of the CA that issues the certificate. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca

Paul, Thank you, your reply is concise and makes sense to me. I'm going to try working with my existing 2 tier CA hierarchy rather than blow away, I need to get used to the renewal process and understand file numbering anyhow, so better to do it in it's infancy rather than when EVERYTHING's running off it and I'm under pressure. I have nothing of interest with Certs Issued, so It's no hassle to go through this process. I'll post with my results within the next day or so. Thanks again!! Regards Paul.

Sorry for the late reply, been on holiday. But seems Paul covered things. You having a 2 tier, you need to fix the AIA extension on the root CA (as you have done). Then you need to renew the subordinate certificate (can use the same private key). This will give you the correct publishing AIA string in the certificate, and new certificates published by the subordinate CA will give correct chain validation based on the new location. Old certificates will use the old AIA string so it would be best to renew already published certificates from the subordinate CA.

Hi Guys, I understand everything that's been said here, but I'm missing something. I seem to have created even more problems with my existing implementation. I now am struggling to understand why or if I'd want multiple copies of the RootCa's cert in the Trusted CA Store on local machines, the relevance of the (1), (0-1) numbering after the renewed certs on the RootCA, teh Sub CA won't start saying it's got problems saying the revocation server is offline, I thought the CAPolicy.inf stated there were no AIA and CDP locations for the RootCert? Anyways, you can see I'm struggling here. I wondered if you guys, Paul, Leron and Morten could point me in the direction of some good text to get the fundamentals of managing Windows PKI down. I've read mostly verbatim the Windows Server 2008 PKI and Certificate Security, and used the walkthroughs to get me where I am now, but I'm either missing something or the text isn't explanative enough for me. I'm usually pretty good, I'm well versed in other areas of Cisco and MS technologies just this is proving a little tough to visualise for me, especially PKI operations, the actual Month by Month/Year by Year operations of revocation and renewal which is definitely not talked about well in the book I referred to which leaves me unable to document it for my organisation and have equally little confidence in scenarios I find myself in here. Any help REALLY appreciated, I'm calling out to you guys! Regards Paul.

Sorry but my experience is that the existing texts just confuse further. This is because depending if the text are written for 2000, 2003 or 2008 PKI, they have subtile differences illustrating a change in what is considered best practice. What I always do is use the CA management console to renew root or subordinate CA's because this gives for me the most consistent result. You are in a senario now where you get two CRL from root, one from the old root certificate (still valid) and one from the new certificate. This is done so the old chain can live thogether with the new chain, and not disrupt operation of the certificates issued from the old chain. What you could have done when renewing the root certificate was to use the same privte key, then you would not have had this mess with the cross certificates. I have created a bunch of code and scripts and integrated it with Operation Manager, where lots of comon senarios are alerted on. Among when its time to renew the root CRL. We operate with 1 year lifetime of the root CRL, as this only controls revocation of subordinate CA's (and if you have to do this, we just pegg the whole PKI as compromised and configure a new one). The Root CA is virtual on a hyper-V standalone server (not connected to network or ILO). Operators log in with a special identity that starts scripts to publish and back up CRL and CA to external media (USB storage). The CRL USB stick is then plugged into a domain joined machine and publishes CRL to the relevant location. The backup (virtual image) is circulated to the cold standby root CA, so as to take over if the original HW have issues. Everything is done automatic, and the operator have only to log on and circulate the USB sticks. The servers and relevant USB sticks are encrypted. If you want to understand what happens on the client you can read my post here: http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/2eeecd7c-35e5-4cc6-bf16-0c5da0cc440f Read the test bit, and how you can delete and get the client to populate the local store again. Two parts, deleting the certificate on the local client and deleting the reg key i mention. Also everything published to the AIA container in AD (use pkiview.msc rightclick top node and choose manage AD containers) is published to domain joined clients and servers in the intermediate store. Root certificate published to the certification authorities container in AD will be published to the trusted store on the local client or server. Regards Morten