none
Migrating Internal standalone CA from SHA1 to SHA256

    Question

  • We have a single standalone enterprise CA running on Windows Server 2008 R2 which is still using the SHA1 hash algorithm (Micrsoft Software Key Storage Provider).

    Due to a requirement in our recently changed security policy we must migrate to use SHA256.

    How much of an impact will there from making this change?

    Will we have to renew our root certificate to be SHA256 and then have all clients (Windows 7 SP1 Enterprise) and affected servers (Windows 2003 and 2008 R2) re-install it ? My assumption yes.

    Also will we have to re-issue certificates that have previously been issued by this CA? In the case we want them to be SHA256 I realize the answer is yes but if we want to continue using the existing SHA1 installed ones, does it become an issue?

    Appreciate any advice or tips. Thank you.




    Sunday, August 10, 2014 9:26 PM

Answers

  • > On principle the hash algorithm a CA uses can be changed by editing a registry key

    you can't. This setting affects only issued certificates and not CA certificate itself. Maintaining different signing algorithms within a PKI tree is a sort of profanity and makes no sense at all. That is, if you want to move to new algorithms (and/or public key algorithm and length), you have to setup a new PKI tree with new root. Partial signature algorithm migration is a joke.


    My weblog: en-us.sysadmins.lv
    PowerShell PKI Module: pspki.codeplex.com
    PowerShell Cmdlet Help Editor pscmdlethelpeditor.codeplex.com
    Check out new: SSL Certificate Verifier
    Check out new: PowerShell FCIV tool.

    Monday, August 11, 2014 5:21 AM
  • > On principle the hash algorithm a CA uses can be changed by editing a registry key

    you can't. This setting affects only issued certificates and not CA certificate itself.

    That's why I said after a renewal of the CA also the CA certificate will use the new algorithm (as also the CA certificate is one of the certificates issued after change of the registry key).

    As I understood the question, the "PKI tree" here is just a single CA. Re-configuring the registry key and renewing the CA would configure the whole tree for SHA256.

    But I also recommend setting up a new PKI in parallel.



    Monday, August 11, 2014 8:00 AM

All replies

  • On principle the hash algorithm a CA uses can be changed by editing a registry key and restarting the CA (with CNG providers, not with classical CSPs), and after a renewal also the new certificate would be signed with SHA256. However in this case all certificates issued after that and also all CRLs would be signed using SHA256.

    I would rather mitigate the risk (of some not yet updated application not being able to understand SHA26) and set up a second CA in parallel that uses SHA256. The existing CA would keeping signing CRLs and existing "legacy" applications would be happy.

    Then all clients could be gradually tested and migrated to the new CA by "moving" the respective template to the new CA (or copy the template, supersede the old one, first give only a pilot group enroll permission).

    Both CA certificates would be published to AD and all clients would trust both. Via permissions on the templates and on the CA (Request Certificates) you can control which client can enroll at which CA.

    Clients > Windows 2003 / XP are not a problem.

    Windows 2003 / XP might need the patch mentioned in this thread.

    I would be most concerned about embedded systems, devices and generally all "exotic" applications (third-party LDAP browsers accessing AD,...) as it is often difficult to determine what sort of algorithms they support.

    Elke

    Sunday, August 10, 2014 10:31 PM
  • > On principle the hash algorithm a CA uses can be changed by editing a registry key

    you can't. This setting affects only issued certificates and not CA certificate itself. Maintaining different signing algorithms within a PKI tree is a sort of profanity and makes no sense at all. That is, if you want to move to new algorithms (and/or public key algorithm and length), you have to setup a new PKI tree with new root. Partial signature algorithm migration is a joke.


    My weblog: en-us.sysadmins.lv
    PowerShell PKI Module: pspki.codeplex.com
    PowerShell Cmdlet Help Editor pscmdlethelpeditor.codeplex.com
    Check out new: SSL Certificate Verifier
    Check out new: PowerShell FCIV tool.

    Monday, August 11, 2014 5:21 AM
  • > On principle the hash algorithm a CA uses can be changed by editing a registry key

    you can't. This setting affects only issued certificates and not CA certificate itself.

    That's why I said after a renewal of the CA also the CA certificate will use the new algorithm (as also the CA certificate is one of the certificates issued after change of the registry key).

    As I understood the question, the "PKI tree" here is just a single CA. Re-configuring the registry key and renewing the CA would configure the whole tree for SHA256.

    But I also recommend setting up a new PKI in parallel.



    Monday, August 11, 2014 8:00 AM
  • One more comment: As this was called an standalone enterprise CA I zoomed in on enterprise and described the scenario for moving certificate templates. If it is really a standalone CA it is just IIS permissions and/or providing subscribers with the URL (to the web application).
    Monday, August 11, 2014 8:03 AM
  • Thank you all for your replies. Judging from your responses it seems like it would not be do-able but looking atthe below two links I see that they are saying the opposite:

    http://www.cusoon.fr/update-microsoft-certificate-authorities-to-use-the-sha-2-hashing-algorithm-2/#comment-3193

    http://blogs.technet.com/b/pki/archive/2013/09/19/upgrade-certification-authority-to-sha256.aspx

    Can anyone confirm one way or the other?

    I simply want to be able to issue certificates using the SHA256 hash algorithm but not impact our existing root certificate and issued certificates from the same standalone CA.

    Thank you.


    • Edited by Barkley Bees Wednesday, September 10, 2014 5:44 PM
    Wednesday, September 10, 2014 5:43 PM
  • These instructions are exactly what I tried to say with: change the registry key / renew the CA (The second article covers a part of the procedure - in the first article the algorithm is changed, then the CA is renewed, in the second article just the change of the config. is described).

    Changing that key will make the CA sign anything - certificates, incl. its own renewed certificate and CRLs - using the new algorithm.

    However, since the process also impacts CRLs the impact on existing certificates is not zero though those certificates are of course not changed:

    Any application that needs to validate such an old certificate signed with SHA1 will need to understand SHA256 in case the application checks CRLs.

    Elke



    • Edited by Elke Stangl Wednesday, September 10, 2014 5:56 PM
    Wednesday, September 10, 2014 5:52 PM
  •  There are many sides to the SHA-2 upgrade story. You can do side by side different Root CA migration, or you can upgrade your existing CA servers.

    There is a white paper describing each approach and how it will affect your applications:

    http://ammarhasayen.com/2015/02/04/what-makes-a-ca-capable-of-issuing-certificates-that-uses-sha-2/   


    ammarhasayen

    Wednesday, February 04, 2015 3:13 PM