ADCS Server migration
> It seems like the certificate provided by the CA is not trusted. can you provide exact error message? I think that there are issues with certificate revocation checking. Can you run PKIView.msc console on CA server and tell whether everything is ok? I have verified this and this was eventually OK. At first it wasn't ok because it was looking for following ldap address: CN=NEWCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix I modified the extension to only publish to CN=OLDCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix and then everything PKIview turn to green. just put default LDAP URL in the CDP extension: <a href="ldap:///CN=<CRLNameSuffix>, CN=<ServerShortName>, CN=CDP, CN=Public">ldap:///CN=<CATruncatedName><CRLNameSuffix>, CN=<ServerShortName>, CN=CDP, CN=Public Key Services, CN=Services, <ConfigurationContainer><CDPObjectClass> (CA properties, Extensions, CDP?) That was available by default so I would suspect that that would create following CDP in AD yet that isn't present.CN=NEWCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix > I had to adjust some additional security settings using ADSEDIT there is no need to modify permissions on AD containers. Although the new CA was added to the trusted publishers I had to add the computeraccount of the new CA directly to the CDP and its containers. When checking the permissions on the containers AIA, CDP, I saw that the OLD CA was also present. This is usually not the case and only trusted publishers is present in the ACL of the container. The computers account is only present on CDP itself (CN=CA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix) The official documentation also tells you to modify the security on the AIA and CDP container: http://technet.microsoft.com/en-us/library/9aa53be9-0497-49fa-9ff6-09b72cb69444(v=ws.10)#BKMK_GrantPermsAIA Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.
August 27th, 2012 4:27pm

If the name of the destination server is different from the source server, the destination server must be granted permissions on the source server's CDP and AIA containers in AD DS to publish CRLs and CA certificates. Complete the following procedure in the case of a server name change. 1. Log on as a member of the Enterprise Admins group to a computer on which the Active Directory Sites and Services snap-in is installed. 2. Click Start, point to Run, type dssite.msc, and then click OK. 3. In the console tree, click the top node. 4. On the View menu, click Show services node. 5. In the console tree, expand Services, expand Public Key Services, and then click AIA. 6. In the details pane, right-click the name of the source CA, and then click Properties. To assign certificate templates to the destination CA To grant permissions on the AIA and CDP containers 7. Click the Security tab, and then click Add. 8. Click Object Types, click Computers, and then click OK. 9. Type the name of the destination server, and click OK. 10. In the Allow column, click Full Control, and click Apply. 11. If the source server object is displayed in Group or user names, click the name of the source server, then click Remove, and then click OK. 12. In the console tree, expand CDP, and then click the name of the source server. 13. In the details pane, right-click the cRLDistributionPoint item at the top of the list, and then click Properties. 14. Click the Security tab, and then click Add. 15. Click Object Types, click Computers, and then click OK. 16. Type the name of the destination server, and click OK. 17. In the Allow column, click Full Control, and click Apply. 18. If the source server object is displayed in Group or user names, click the name of the source server, then click Remove, and then click OK. 19. Repeat steps 13 through 18 for each cRLDistributionPoint item.Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin
Free Windows Admin Tool Kit Click here and download it now
September 1st, 2012 7:55am

Dear i.biswajith, Thanks for your help, but that is not an issue. The new server is able to Update CRL's published IN AD. This means that the security settings placed on AIA and CDP are correct. The information you provided is also provided in the official documentation and has been applied. Furthermore if i publish the CRL's manually using Certutil, it finishes successfully. Also PKIview.msc displays no errors on the CRL. My college disabled CRL checking in Cisco ISE but the issue continue's. Now in regards to my second question: The LDAP URL is present in the Extension tab under CDP, yet I cannot publish the CRL because the object does not exist: Object: CN=NEWCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix LDAP URL: "LDAP:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>" If i translate the LDAP URL it should lead to CN=SubCA-NEWCA,CN=NEWCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix Now is the object is not created when an LDAP path is defined in the CDP list under the extensions tab, because i have tried this in my lab environment so the CDP is not created, therefore i think i need to create the container manually by Certutil certUtil -Addstore ..... Can someone confirm this?Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.
September 1st, 2012 8:52am

to create CDP object, you must publish it by using certutil: certutil -dspublish -f newcrl.crl My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki
Free Windows Admin Tool Kit Click here and download it now
September 1st, 2012 9:20am

Thanks Vadims, but can you clarify it a bit for me please? If I run CertUtil -Dspublish -f newcrl.crl, how can Certutil know it needs to create a new CDP: CN=<CATruncatedName><CRLNameSuffix>,CN=NEWCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix I guess i need to run certutil -f -dspublish newcrl.crl "LDAP:///CN=subca-newca-ca,CN=NewCA,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=subdomain,DC=RootDomain,DC=suffix?CertificateRevocationList?Base?ObjectClass=cRLDistributionPoint?CertificateRevocationList", which i tried in a test environment but fails. The error is: DecodeFile returned The system cannot find the file specified. 0x80070002 (WIN3 : 2) DecodeFile returned The system cannot find the file specified. 0x80070002 (WIN3 : 2) Could not load Certificate or CRL from file (The system cannot find the file sp cified. 0x80070002 (WIN32: 2)) CertUtil: -dsPublish command FAILED: 0x80070002 (WIN32: 2) CertUtil: The system cannot find the file specified. I tried CertUtil -Dspublish -f newcrl.crl in my test environment but fails with the same error. I have verified the CRL name under %Systemroot%\System32\Certsrv\CertEnroll and it is correct. Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.
September 1st, 2012 10:02am

ok, run the following command: certutil -dspublish -f newcrl.crl <NewCAHostName> replace <NewCAHostName> with a new host name (short name) where CA is installed. For example, CA is installed on mynewca.company.com, then the command must be: certutil -dspublish -f newcrl.crl mynewcaMy weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki
Free Windows Admin Tool Kit Click here and download it now
September 1st, 2012 10:23am

That answerred my second question clearly, thanks a million Vadims. Now regarding the trust issue. I do not see anything wrong in regards to the certificates. Both the root and subordinate CA look clean when verifying the certificate chain. As my college disabled CRL checking we know that CRL's are not being checked. So we can rule out CRL's. He has opened a Call with Cisco. Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.
September 1st, 2012 10:47am

Two questions: Story line: One of my clients has three domains, a root domain (management) and two child domains. The root domain has a Windows Server 2003 domain Controller which is configured as root CA. One of the sub domains that has the users plus all application servers, had a Windows Server 2003 domain Controller which was also configured a Stand-alone Subordinate CA for the root CA in the root Domain. We wanted to move the subordinate Certificate Authority away from the domain controller to a stand-alone subordinate CA running on Windows Server 2008 R2. The domain controller running that CA may not be decommissioned. I performed the migration using following article: http://smtpport25.wordpress.com/2010/01/16/migrating-windows-certificate-authority-server-from-windows-2003-standard-to-windows-2008-enterprise-server/ This gave me a good basic idea how to address the migration. I had to adjust some additional security settings using ADSEDIT, which were not mentioned in the article but overall everything worked out OK, at least that is what I think. The customer asked me to set-up autoenrollment for computer certificates for every domain joined computer. The computer certificate will be used for client authentication to the Wireless LAN (Cisco ISE). I configured the correct templates and policies and checked if the certificates rolled out OK. Everything seems fine. Now a college of mine imported the root and subordinate CA in Cisco ISE and tries to connect domain computers to the wireless LAN. This however does not work. It seems like the certificate provided by the CA is not trusted. I haven't been onsite so havent done any troubleshooting. What I do know is that all certificate chains turn up OK. So here comes my first question: Has anybody done a similar migration and are there any pitfalls, something i might have forgotten or isn't mentioned in the article? Second question: How can i create a new CRL distribution point in AD for the new server. Like explained in the article, the old CRL in AD is used to publish the CRL's in AD. This is required for certificates which have been rolled out prior to the migration. Yet when looking further away, this OLD CRL name might cause confusion in the Future. To make it more realistic i want to create a second CRL in AD with the new subordinate CA name. I guess it should be done through CertUtil, yet finding the right Syntax is not easy. The CDP in AD now contains two CDP's: The root ca: CN=Root,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix Subordinate CA CN=OLDCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix I want to create a third CDP= CN=NEWCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix and publish the CRL to both the old CDP as the new. Then the old CDP can be removed when all certificates that have been deployed from the old CA have expired. Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.
Free Windows Admin Tool Kit Click here and download it now
September 1st, 2012 2:00pm

> I performed the migration using following article: http://smtpport25.wordpress.com/2010/01/16/migrating-windows-certificate-authority-server-from-windows-2003-standard-to-windows-2008-enterprise-server/ I'm sorry, but we do not support 3rd party guides. You should ask blog author what is went wrong. Further, use official guides as possible. Here is the link to official AD CS migration guide: http://technet.microsoft.com/en-us/library/ee126170(WS.10).aspx My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki
September 1st, 2012 2:40pm

I am sorry, but the blog is from a fellow MVP, so i believe it is trustworthy. I have read the official documentation and every official documentation states to remove the old CA completely. Now this cannot be done because it is a domain controller and secondly what is the use of removing the old server if you are not going to reuse the name? Thirdly, if you read the official documentation it is exactly what has been told in the blog, only the blog is written clearly. Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.
Free Windows Admin Tool Kit Click here and download it now
September 1st, 2012 3:38pm

> I am sorry, but the blog is from a fellow MVP, so i believe it is trustworthy. sure. But you are not the first who has issues with mentioned article. > I have read the official documentation and every official documentation states to remove the old CA completely. if you move CA service to another server with different name, then you don't need to decommission entire server, just uninstall certificate services from old server before you install it on a new machine. > Thirdly, if you read the official documentation it is exactly what has been told in the blog, only the blog is written clearly. I read official guide and can tell that they are not exact, moreover, an article has few misleading steps. BTW, > I had to adjust some additional security settings using ADSEDIT there is no need to modify permissions on AD containers. > It seems like the certificate provided by the CA is not trusted. can you provide exact error message? I think that there are issues with certificate revocation checking. Can you run PKIView.msc console on CA server and tell whether everything is ok? > To make it more realistic i want to create a second CRL in AD with the new subordinate CA name just put default LDAP URL in the CDP extension: <a href="ldap:///CN=<CRLNameSuffix>, CN=<ServerShortName>, CN=CDP, CN=Public">ldap:///CN=<CATruncatedName><CRLNameSuffix>, CN=<ServerShortName>, CN=CDP, CN=Public Key Services, CN=Services, <ConfigurationContainer><CDPObjectClass> and enable all required checkboxes.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki
September 1st, 2012 4:37pm

> It seems like the certificate provided by the CA is not trusted. can you provide exact error message? I think that there are issues with certificate revocation checking. Can you run PKIView.msc console on CA server and tell whether everything is ok? I have verified this and this was eventually OK. At first it wasn't ok because it was looking for following ldap address: CN=NEWCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix I modified the extension to only publish to CN=OLDCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix and then everything PKIview turn to green. just put default LDAP URL in the CDP extension: <a href="ldap:///CN=<CRLNameSuffix>, CN=<ServerShortName>, CN=CDP, CN=Public">ldap:///CN=<CATruncatedName><CRLNameSuffix>, CN=<ServerShortName>, CN=CDP, CN=Public Key Services, CN=Services, <ConfigurationContainer><CDPObjectClass> (CA properties, Extensions, CDP?) That was available by default so I would suspect that that would create following CDP in AD yet that isn't present.CN=NEWCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix > I had to adjust some additional security settings using ADSEDIT there is no need to modify permissions on AD containers. Although the new CA was added to the trusted publishers I had to add the computeraccount of the new CA directly to the CDP and its containers. When checking the permissions on the containers AIA, CDP, I saw that the OLD CA was also present. This is usually not the case and only trusted publishers is present in the ACL of the container. The computers account is only present on CDP itself (CN=CA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=Subdomain,DC=RootDomain,DC=Prefix) Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.
Free Windows Admin Tool Kit Click here and download it now
September 1st, 2012 6:39pm

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

Other recent topics Other recent topics