cross certificates when migration sha1 to sha2 RRS feed

  • שאלה

  • Hello,

    There are some documentations explaining the process, but i did not yet practice them.

    When the Root CA will be move to KSP capabilites, i will renew its certificate (with the same key & with SHA2)

    As the ROOT CA is the domain, i guess the new certificate will be propagated automcatically to all connected windows machines in the domain.

    As there is no change no the priv/pub key, there won't be any cross-certificates between the new and the old certificates.

    But i have a doubt as the algorithm for signature is now SHA2, the SKI (based on the hash of the ub key) of the certification may  not be the same, and then the cross-certificates are needed. Right? I guess the CA will create them automatically, and i hope it will be deployed also aumotically to the entire domain?

    IF someone could confirm ...


    יום שלישי 12 יוני 2018 09:27


כל התגובות

  • Hi Laurent,

    Migrating from SHA1 to SHA256 is a bit sensitive (though possible), and if uncertain, migrating side-by-side (building a new PKI and migrating the certificates) is a more risk-free way. That said, here's how I understand certificate validation.

    If you open any certificate, four attributes, three of them visible, are important:

    - The signature of the certificate, which very simplified is the hash encrypted with the private key of the CA.

    - The signature algorithm (and signature hash algorithm).

    - The Subject Key Identifier.

    - The Authority Key Identifier.

    When your issuing CA is verified against the Root CA, it will first look for the Authority Key Identifier in its own certificate. It will then start looking for a certificate where the Subject Key Identifier matches the Authority Key Identifier (the Root CA Certificate). Once it found it, it will look in that Root CA Certificate for the Signature Hash Algorithm, make a hash of its own certificate. Finally it will decrypt the hash in the original signature, and compare the two hashes. If the hashes match, the signature is valid.

    What you get when you upgrade a Root CA to SHA256 but use the same key pair is that the Signature Hash Algorithm changes in the new Root CA certificate, but the Signature, the Subject Key Identifier and the Authority Key Identifier do not change. In other words, since the sub CA certificate was originally signed using SHA1, the hashes will not match. Therefore if you want te upgrade, but also want to keep your older certificates alive for a while, it's best to also renew the key pair.

    Kind Regards,

    יום שלישי 12 יוני 2018 13:46
  • Adding to the previous response:
    1) When renewing the root CA, the best practice is to renew with a new key pair each and every time

    2) It is most important to renew the root CA with a new key pair when changing the hashing algorithm.


    • הוצע כתשובה על-ידי Brian Komar [MVP] יום שישי 15 יוני 2018 14:19
    יום שלישי 12 יוני 2018 14:31
  • Thanks for your explanations.

    Ok, The renewal of the cert with a new key pai is a best practice.

    I have another question (it is for me to understand the microsoft PKI mechanism)

    If i renew with existing key pair, a new cert with the name subca(1).crt will be created.

    i have have to copy this certificatre to the AIA location.

    But in parallel, as it is an enterprise CA, this certificate will arrive to the "Intermediate trusted CA" store of all users'machines.

    Then in this store there will be the subca.crt (the old one) and the subca(1).crt.

    How will the Certicate Chain Engine (CCE) take the decision to choose one and not the other one?


    יום חמישי 14 יוני 2018 06:57
  • Hi Laurent,

    Have a look for yourself. The filename subca(1).crt is just that, a filename. Open the file, go to the details tab and look for the subject key identifier. Then open subca.crt and do the precise same thing. You'll find that the subject key identifiers are the same number.

    And there's your problem. CCE can't determine which one to choose since they both are entitled to the same private key with which the end entity certificate was signed. Upon reaching the first one it finds, it will assume it has found the right one. If it is the one with the wrong signature hash algorithm, it will make an incorrect hash calculation to compare with the signature and fail.

    Kind Regards,

    יום שישי 15 יוני 2018 05:48
  • Ok , so it is better to renew the key too to avoid this behavior.

    Many Thanks


    • סומן כתשובה על-ידי laurent feron יום שני 18 יוני 2018 07:54
    יום שישי 15 יוני 2018 11:46