none
Migrated Enterprise Certificate Authority from 2003 to 2008 R2 using same ServerName. Slight Problem!

    Question

  • Original Server:  Windows Server 2003 Enterprise, SERVERCERT, IP 10.10.10.10

    New Server: Windows Server 2008 R2 Enterprise, SERVERCERT, IP 10.10.10.10

    This is the only certificate server on the domain (Single Forest, nice and easy)

    Steps I took:

    Performed a Backup of CA Database with Keys and Exported the Configuration Registry Key
    Uninstalled CA from Add/Remove Programs
    Powered off server

    Joined new server to the domain (using same name as the previous one)
    Added CA Feature to server
    Restored Database
    Imported Registry Key

    Waited 15mins for replication and everything to settle down.

    CA looks ok on the new server.  Everything looks how it did before.  I created a new local
    SSL cert on the new server and added it to the IIS site bindings.  Now users have access
    the certificate enrollment site via HTTPS.  So far so good :-)

    However....I have made a slight mistake

    When I joined the new server to the domain, I didn't delete the existing computer
    object from AD first.  I would have thought that when attempting to join a server using
    an existing name it would say "There is a duplicate name found in AD".

    There is one computer object in AD called SERVERCERT but this was the one from the original server not the new one.  Doesn't 'seem' to be causing us any issues.

    The problem though is this......

    When I open up the Certificate node in server manager there are two red X marks:

    AIA Location #2 - Unable to Download - http://servercert.mydomain.local/certenroll/servercert.mydomain.local_servercert(2)
    CDP Locoation #2 - Unable to Download - http://servercert.mydomain.local/certenroll/servercert(2).crl

    Looking at the other settings which have a status ok, most are set to ldap://CN=servercert(2),....

    I have gone into AD Sites and Services and Navigated to Services / Public Key Services / CDP / SERVERCERT and noticed there are two cRLDistributionPoint entries.  SERVERCERT and SERVERCERT(2).

    I'm not sure, but I think the problem is all down to this (2) setting after the server name.  Perhaps because I joined the new server to the domain using the old servers name?

    can someone help me tidy it all up please.  I don't really want to uninstall CA and start again if I can help it.  I'd rather try to fix the issue.  Please note, certificates are my weakest point as I have never had must to do with them until now.

    Thanks!!

    Thursday, June 20, 2013 8:47 AM

Answers

  • That has to be one of the worst and most unprofessional replies I have seen on TechNet.  Coming from an MVP I find it disgraceful!

    How about a little respect for starters, and a more technical response as to why?  This could help other people with a similar issue.

    I don't see what is unprofessional in my previous reply. I said that your configuration was wrong. Of course, you can have your own opinion here.

    CRL retrieval URLs are used to determine presented certificate's revocation status. Since you forced SSL for CDP location, revocation function must check SSL certificate revocation status too (before it downloads requested CRL). This simply leads to an infinity loop, because CRL cannot be downloaded before SSL certificate is checked for revocation, but revocation checking cannot check revocation status before SSL certificate is checked for revocation. CryptoAPI immediately fails if there is some sort of SSL, authentication and so forth on CDP and AIA locations. Something like to put WinRAR archiver in RAR archive.

    Moreover, CRLs and certificates are digitally signed and do not contain any sensitive information, therefore there is no need to protect them in any way.


    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new: PowerShell FCIV tool.

    • Marked as answer by GlenHarrison Friday, June 21, 2013 7:30 PM
    Friday, June 21, 2013 7:19 PM

All replies

  • Just to add, I've just checked the SERVERCERT object in AD and it states 'Windows Server 2008 R2' so I guess that's ok.
    Thursday, June 20, 2013 9:16 AM
  • make sure if you allow HTTP protocol on port 80 on CertEnroll virtual directory. There is nothing to do with Active Directory in your case.

    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new: PowerShell FCIV tool.

    Thursday, June 20, 2013 9:34 AM
  • I have installed the Microsoft URL redirect pack and created a ruleset in web.config to automatically direct users from HTTP to HTTPS

    Do you know why the red X are appearing?

    Thursday, June 20, 2013 1:17 PM
  • I have installed the Microsoft URL redirect pack and created a ruleset in web.config to automatically direct users from HTTP to HTTPS

    Do you know why the red X are appearing?


    you MUST NOT redirect CRT/CRL downloads to HTTPS. Never. This is why you are expiriencing this issue.

    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new: PowerShell FCIV tool.

    Friday, June 21, 2013 2:03 PM
  • You have me worried now

    I have just this minute set the IIS settings on SSL Certificates to auto.  Now all the errors are gone and everything looks great.

    Thinking this is/was a bad idea?

    Friday, June 21, 2013 2:22 PM
  • You have me worried now

    I have just this minute set the IIS settings on SSL Certificates to auto.  Now all the errors are gone and everything looks great.

    Thinking this is/was a bad idea?

    read my previous post. MUST NOT — this phrase mean that the definition is an absolute prohibition of the specification (configuration, in your case). Does it make a sense for you now?


    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new: PowerShell FCIV tool.

    Friday, June 21, 2013 6:17 PM
  • That has to be one of the worst and most unprofessional replies I have seen on TechNet.  Coming from an MVP I find it disgraceful!

    How about a little respect for starters, and a more technical response as to why?  This could help other people with a similar issue.

    Friday, June 21, 2013 6:33 PM
  • That has to be one of the worst and most unprofessional replies I have seen on TechNet.  Coming from an MVP I find it disgraceful!

    How about a little respect for starters, and a more technical response as to why?  This could help other people with a similar issue.

    I don't see what is unprofessional in my previous reply. I said that your configuration was wrong. Of course, you can have your own opinion here.

    CRL retrieval URLs are used to determine presented certificate's revocation status. Since you forced SSL for CDP location, revocation function must check SSL certificate revocation status too (before it downloads requested CRL). This simply leads to an infinity loop, because CRL cannot be downloaded before SSL certificate is checked for revocation, but revocation checking cannot check revocation status before SSL certificate is checked for revocation. CryptoAPI immediately fails if there is some sort of SSL, authentication and so forth on CDP and AIA locations. Something like to put WinRAR archiver in RAR archive.

    Moreover, CRLs and certificates are digitally signed and do not contain any sensitive information, therefore there is no need to protect them in any way.


    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new: PowerShell FCIV tool.

    • Marked as answer by GlenHarrison Friday, June 21, 2013 7:30 PM
    Friday, June 21, 2013 7:19 PM
  • Thanks for taking the time to explain it.  I'll remove SSL first thing on Monday.
    Friday, June 21, 2013 7:30 PM
  • you can configure SSL settings on application/virtual directory level, so web enrollment will be accessed over HTTPS and the rest over unencrypted HTTP.

    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new: PowerShell FCIV tool.

    Friday, June 21, 2013 7:35 PM
  • well that was easier than I thought

    Disabled the HTTPS redirect rule and SSL certificate acceptance on the CertEnrol directory.  Still looks like everythings working.

    Monday, June 24, 2013 8:06 AM
  • well that was easier than I thought

    Disabled the HTTPS redirect rule and SSL certificate acceptance on the CertEnrol directory.  Still looks like everythings working.


    glad to hear you resolved this issue.

    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new: PowerShell FCIV tool.

    Monday, June 24, 2013 11:56 AM