none
Post Enterprise Root CA Migration Errors

    Question

  • I believe I have covered all of the steps in the guide, however after migrating my enterprise root CA from 2008 to 2012, the Delta CRL Location #1 and #2 appear to be pointed to the old CA.  While DeltaCRL Location #1 is working (ldap://), the CN is the name of the old CA.  The DeltaCRL Location #2 is pointing to http://oldca which of course is incorrect.

    As a quick side note, I published a new CRL / Delta CRL and this fixed some of the issues (DeltaCRL Location #1 has the correct CN now), however it removed DeltaCRL Location #2 (Http://) completely.  I verified the extension is configured to include the http:// path, so I'm not sure why it's missing.



    • Edited by Kendo452 Friday, August 23, 2013 9:21 PM
    Friday, August 23, 2013 9:14 PM

All replies

  • go into the Extensions tab of the AD CS properties and verify the CDP and AIA paths as they appear there. Also note that if you change the paths, this change will take effect only on newly issued certificates. Those certicicates that have already been produced will remain with the old paths.

    generally speaking, if you have any old paths, you must make them accessible. If the paths contain old computer names, you must probably create some aliases, or implement redirection on the old web servers.

    anyway, this is poor design to put non-alias computer names into the HTTP paths. rather be sure to put there alias names in order to be able to make further migrations smoother.

    ondrej.

    Saturday, August 24, 2013 9:06 AM
  • go into the Extensions tab of the AD CS properties and verify the CDP and AIA paths as they appear there. Also note that if you change the paths, this change will take effect only on newly issued certificates. Those certicicates that have already been produced will remain with the old paths.

    generally speaking, if you have any old paths, you must make them accessible. If the paths contain old computer names, you must probably create some aliases, or implement redirection on the old web servers.

    anyway, this is poor design to put non-alias computer names into the HTTP paths. rather be sure to put there alias names in order to be able to make further migrations smoother.

    ondrej.

    So in the case of changing the server name during a migration, can I just point the DNS entry of the old server to the new server so that the HTTP locations still work?  What happens as far as the CRL for the old certificates ? If they're pointed to Public Key Services \ CDP \ OldServerName in AD would they never pull a new CRL?  

    Should I create a new extension to publish to the CDP container for the old CA server name?

    As an example, on an old certificate, the Authority Information Access field has URL=http://ca02.domain.com/CertEnroll/ca02.domain.com_domain-CA02-CA.crt
     and the path no longer exists (even if I redirect the old DNS entry to the new server).  Will this cause issues?
    • Edited by Kendo452 Tuesday, August 27, 2013 6:20 PM
    Tuesday, August 27, 2013 3:53 PM
  • to say it simply - if you have any valid existing certificates that contain any Certificate Revocation List (CRL) Distribution Point (CDP) paths, you must make sure that the paths are still available even after anything happens (such as when you migrate the anywhere).

    If a computer which tries to validate a certificate cannot reach at least one of the CDP paths and obtain current and valid CRL from the path, it deems the certificate invalid and fails its check.

    So your task is that simple as going and finding all the previously used CDP paths and making them populated with current and valid CRLs every time your CA(s) issue new CRLs.

    I cannot help you more, it is usually a matter of several minutes for an experienced PKI master such as me :-), while often a painful chore for someone who have never did it before.

    ondrej.


    Wednesday, August 28, 2013 6:53 AM
  • I understand that the paths need to be valid, however, the CRL in the CDP container won't be valid unless I publish a extremely long CRL before I migrate, correct?  If I publish it for let's say 40 years, and make sure the HTTP location is valid post migration, I should be good?
    Wednesday, August 28, 2013 1:43 PM
  • no, do not publish the long CRL, it makes no sense from security point of view, and you have already migrated anyway. Just leave with its common validity period and define means to overcome the name change - such as scheduled tasks that copy the CRL to the old paths (CERTUTIL -dspublish or ROBOCOPY to a web server or as you said, the DNS name alias or HTTP redirection etc.).

    ondrej.

    Wednesday, August 28, 2013 1:46 PM
  • no, do not publish the long CRL, it makes no sense from security point of view, and you have already migrated anyway. Just leave with its common validity period and define means to overcome the name change - such as scheduled tasks that copy the CRL to the old paths (CERTUTIL -dspublish or ROBOCOPY to a web server or as you said, the DNS name alias or HTTP redirection etc.).

    ondrej.

    This makes sense, and I think I've found the certutil command to publish to the old CA container.  How should I be exporting the CRL so that it can be imported into the old location via certutil?
    Wednesday, August 28, 2013 3:44 PM
  • it should be stored in %windir%\system32\certsrv\CertEnroll by default, it is the location where CA publishes the CRL locally by default. o.

    Wednesday, August 28, 2013 4:14 PM
  • it should be stored in %windir%\system32\certsrv\CertEnroll by default, it is the location where CA publishes the CRL locally by default. o.

    Any idea why this command would be failing?  CONTOSOCA03 is the old CA which has been migrated to CONTOSOCA02.

    certutil -f -dspublish C:\windows\system32\certsrv\certenroll\contoso-CONTOSOCA03-CA.crl ldap:///CN=contoso-CONTOSOCA03-CA,CN=CONTOSOCA03,CN=CDP,CN=Public20%Key20%Services,CN=Services,CN=Configuration,DC=CONTOSO,DC=local?deltaRevocationList?base?objectClass=cRLDistributionPoint

    Wednesday, August 28, 2013 5:44 PM
  • it should be stored in %windir%\system32\certsrv\CertEnroll by default, it is the location where CA publishes the CRL locally by default. o.

    Any idea why this command would be failing?  CONTOSOCA03 is the old CA which has been migrated to CONTOSOCA02.

    certutil -f -dspublish C:\windows\system32\certsrv\certenroll\contoso-CONTOSOCA03-CA.crl ldap:///CN=contoso-CONTOSOCA03-CA,CN=CONTOSOCA03,CN=CDP,CN=Public20%Key20%Services,CN=Services,CN=Configuration,DC=CONTOSO,DC=local?deltaRevocationList?base?objectClass=cRLDistributionPoint

    To provide more information, without the 20% in the spaces in 'Public Key Services' I receive a "too many arguments" error.  If I add the 20% for spaces I receive a "Directory object not found" error.  I've also tried the escape character \ even though Microsoft documentation says you shouldn't need to escape a space in a CN object.  Here is the article I'm referencing: http://technet.microsoft.com/en-us/library/dd299801(v=ws.10).aspx

    How else can I publish to the old CDP container if certutil isn't able to parse spaces in a string?

    Wednesday, August 28, 2013 7:04 PM