none
Problem restoring CA to new server

    שאלה

  • We have a PKI-environment consisting of an (offline) Root CA and two Issuing CA's running Windows Server 2008 R2. I want to migrate the PKI-environment to Windows Servers 2016. I backed up the Root CA and restored it without problems on the Windows Server 2016 OS. I also backed up the first issuing CA and restored it without problems on the Windows Server 2016 OS.

    I backed up the second issuing CA and when I want to configure the AD CS and try to restore the backup, I get the error: The imported certificate does not match the chosen CA type and will not be used. However, the imported key can still be used.

    I chose the Enterprice CA as setup type of CA. I chose a Subordinate CA as type of CA. Exactly as I did on the first issuing CA.

    I tried it via the MMC CA console. I tried it via command prompt using certutil  (certutil.exe -f -resoredb <path>) but than I see CertUtil: No local Certification Authority; use -config option and CertUtil: No more data is available.

    I  already made a fresh new backup but that doesn't fix it. I also tried selecting Standalone CA and Subordinate CA (which is wrong but looking at the error I tried) but this does not work either. In need for some despirate help.

    [Edit:]
    I tried restoring the backup from the first issuing CA and this works without problems. There is something wrong with the backup from the second issuing CA. I already made a new backup (as I said) but the new backup from the second issuing CA is still not working. What can I do now?
    • נערך על-ידי TechnoBjörn יום שלישי 10 יולי 2018 15:11
    יום שלישי 10 יולי 2018 14:48

כל התגובות

  • The incorrect type of CA message infers that that the CA is not a subordinate CA. Can you confirm that the CA certificate was issued by the root CA, or was it incorrectly installed as an Enterprise Root CA.

    Brian

    יום שלישי 10 יולי 2018 18:20
  • The incorrect type of CA message infers that that the CA is not a subordinate CA. Can you confirm that the CA certificate was issued by the root CA, or was it incorrectly installed as an Enterprise Root CA.

    Brian

    Hi Brian,

    Thank you for your reply.

    If I open a random issued certificate I can see the whole chain (RootCA/IssuingCA/<device>) on the Certification Path tab.

    If I open the  Certificate Authority I can see the Certificate Templates node which means it is an Enterprice CA.

    Furthermore, if I look at the registry at HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<certname>\CAType is set to 0x00000001 which stands for Enterprise Subordinate CA.

    I configured the new issuing CA running Windows Server 2016 OS as an Enterprise CA and as a Subordinate CA but still see that the imported certificate does not match the chosen CA type.

    The strange thing is that if I restore the  backup from the first old issuing CA on the  new second issuing CA, the problem does not occur. I rebuild the backup from the  second old issuing CA 3 times now using the MMC, certutil and PowerShell but that does not help at all.

    What can I do next?


    • נערך על-ידי TechnoBjörn יום רביעי 11 יולי 2018 08:09
    יום רביעי 11 יולי 2018 08:05
  • Hi,

    Thanks for your question.

    Due to the backup from the first issuing CA can be restored on the second new CA. The cause may be a incorrect backup from the second old issuing CA. Please check and re-backup it on the second. 

    Please refer to the following article,

    Migrate or Restore a Windows Server 2012 R2 Certification Authority to a New Server

    Please also check the event viewer for the error message related to ADCS so that we can find more clue.  

    Hope this helps. I look forward hearing your good news.

    If you have any question or concern, please feel free to let me know.

    Best regards,

    Michael


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    יום רביעי 11 יולי 2018 09:09
  • Hi,

    Thanks for your question.

    Due to the backup from the first issuing CA can be restored on the second new CA. The cause may be a incorrect backup from the second old issuing CA. Please check and re-backup it on the second. 

    [....]

    Hello Michael. Thank you for your reply.

    When restoring the backup from the old second CA onto the new second CA, I did not decommission the old second CA first. I guess that this not a problem because when I restored the backup from the old first CA to the new first CA there weren't any problems whatsoever. The old en new CA's still have different hostnames. I wanted to check this entire backup/restore process first before I decommission the old CA's. I did this because of this very reason that something might can go wrong.

    I re-backuped the old second CA a couple of times now using the MMC or certutil. This process goes fine and I just did it once more. I again restored the fresh new backup from the old second CA on the new second CA during the AD CS server role configuration process but still I get the same message that the imported certificate does not match the chosen CA type.

    If I look at the eventviewer on the old second CA I see two different warnings occuring each day:

    1) The "Windows default" Policy Module logged the following warning: The ACSTemplate Certificate Template could not be loaded. Element not found. 0x80070490 (WIN32:1168)

    2) The "Windows default" Policy Module logged the following warning: The Active Directory connection to DC07.intranet.local has been reestablished to DC06.intranet.local.

    I reckon that both have nothing to do with my issue.

    What can I do next?



    • נערך על-ידי TechnoBjörn יום רביעי 11 יולי 2018 10:05
    יום רביעי 11 יולי 2018 09:54
  • Am I allowed to *bump*  this thread?
    יום רביעי 18 יולי 2018 11:22
  • The old CA doesn't necessarily need to be decommissioned but it does at least need to be stopped.  I suspect the issue relates to restoring the CA image to a host with a different name than it was backed up on.


    יום שישי 20 יולי 2018 09:04