4 ms·

>An important feature here is that the new certificate has the same subject name and public key as the old certificate, so that its signature on the End-Entity

>An important feature here is that the new certificate has the same subject name and public key as the old certificate, so that its signature on the End-Entity certificate is valid. Shouldn't it be impossible to generate a new cert (with a different expiry date) that ends up having the same public key as an existing cert?

bityard 7y ago
No, one public/private key pair can be used to generate or sign as many certificates as you like, as often as you like.
- parliament32 7y ago
  No I'm not talking about the root, I mean they generated a new certificate (the intermediate) (with a new private key) that had a public key identical to an existing certificate -- you shouldn't be able to do this, public keys can't be "specified" afaik, they're derived from your private key and the signer's public key.
  - rossdavidh 7y ago
    Isn't that the point of having the root cert and the intermediate? Otherwise, why not just have everything keyed to the root?
    - rndgermandude 7y ago
      Because a root typically has a longer expire date and thus has to be stored extra secure and handled extra safely. You'd usually store it in some hardware security module that is operated by an airgapped system or something like that that requires physical access at the very least. Replacing the root often requires shipping new versions of your software that disables the old root and bakes in a new root. If an intermediate certificate becomes compromised, you can revoke it and issue a new intermediate certificate with your still secure root without the need to push out new binaries.
  - vesinisa 7y ago
    AFAIK the public and private keys of any keypair, like the intermediary, are always linked. You can not have a new public key with the same private key. But you can always re-sign the same keypair from the root with a new, non-expired certificate. And since this keypair (the intermediary) signed all the individual add-ons to begin with, it will just magically work. Remember that certificate is nothing but a message that is signed by some "higher" keypair, which says that some "lower" keypair is trusted.
  - floatingatoll 7y ago
    The literal ascii blob of the signed key would be different, because (for example) the "Valid Until" date has changed — but they control the private keys for the signer and the intermediate, which means they can issue a certificate that is logically identical from an X.509 perspective other than fields that either time or randomness contribute to. (Serial number would not necessarily be randomized in this scenario.)
  - jcrawfordor 7y ago
    I think you're perhaps mixing up the public key on the certificate and the signature on the certificate. The signature is over the contents of the certificate, so the certificate cannot change without the signature changing. The public key, though, is just part of the arbitrary information that the certificate is intended to secure. Much like multiple certificates can be issued with the same subject name (but varying other details), multiple certificates can be issued with the same public key. For example, in the TLS context, you can produce an unlimited number of CSRs (certificate signing requests) off of the same private/public key pair used for TLS. It's a common practice to generate a new private/public key pair every time you generate a new CSR in order to mitigate potential compromise of the private key, but even that practice is becoming less common because changing the public key prevents pinning it using e.g. HSTS - today, some clients establish trust by verifying the public key against both the certificate and some other separate method (often TOFU). This is a separate practice used alsongside certificate verification intended to mitigate some of the security concerns around the certificate infrastructure. In this case, as in Mozilla's case here, it is a practical requirement to issue a new certificate with the same public key, because clients expect the public key to remain constant for various reasons.
perlgeek 7y ago
> Shouldn't it be impossible to generate a new cert (with a different expiry date) that ends up having the same public key as an existing cert? If you have the secret key of the original certificate, you can use the same key material, and just use different meta data (like expiry date).

bityard 7y ago

No, one public/private key pair can be used to generate or sign as many certificates as you like, as often as you like.

parliament32 7y ago
No I'm not talking about the root, I mean they generated a new certificate (the intermediate) (with a new private key) that had a public key identical to an existing certificate -- you shouldn't be able to do this, public keys can't be "specified" afaik, they're derived from your private key and the signer's public key.
- rossdavidh 7y ago
  Isn't that the point of having the root cert and the intermediate? Otherwise, why not just have everything keyed to the root?
  - rndgermandude 7y ago
    Because a root typically has a longer expire date and thus has to be stored extra secure and handled extra safely. You'd usually store it in some hardware security module that is operated by an airgapped system or something like that that requires physical access at the very least. Replacing the root often requires shipping new versions of your software that disables the old root and bakes in a new root. If an intermediate certificate becomes compromised, you can revoke it and issue a new intermediate certificate with your still secure root without the need to push out new binaries.
- vesinisa 7y ago
  AFAIK the public and private keys of any keypair, like the intermediary, are always linked. You can not have a new public key with the same private key. But you can always re-sign the same keypair from the root with a new, non-expired certificate. And since this keypair (the intermediary) signed all the individual add-ons to begin with, it will just magically work. Remember that certificate is nothing but a message that is signed by some "higher" keypair, which says that some "lower" keypair is trusted.
- floatingatoll 7y ago
  The literal ascii blob of the signed key would be different, because (for example) the "Valid Until" date has changed — but they control the private keys for the signer and the intermediate, which means they can issue a certificate that is logically identical from an X.509 perspective other than fields that either time or randomness contribute to. (Serial number would not necessarily be randomized in this scenario.)
- jcrawfordor 7y ago
  I think you're perhaps mixing up the public key on the certificate and the signature on the certificate. The signature is over the contents of the certificate, so the certificate cannot change without the signature changing. The public key, though, is just part of the arbitrary information that the certificate is intended to secure. Much like multiple certificates can be issued with the same subject name (but varying other details), multiple certificates can be issued with the same public key. For example, in the TLS context, you can produce an unlimited number of CSRs (certificate signing requests) off of the same private/public key pair used for TLS. It's a common practice to generate a new private/public key pair every time you generate a new CSR in order to mitigate potential compromise of the private key, but even that practice is becoming less common because changing the public key prevents pinning it using e.g. HSTS - today, some clients establish trust by verifying the public key against both the certificate and some other separate method (often TOFU). This is a separate practice used alsongside certificate verification intended to mitigate some of the security concerns around the certificate infrastructure. In this case, as in Mozilla's case here, it is a practical requirement to issue a new certificate with the same public key, because clients expect the public key to remain constant for various reasons.

perlgeek 7y ago

> Shouldn't it be impossible to generate a new cert (with a different expiry date) that ends up having the same public key as an existing cert? If you have the secret key of the original certificate, you can use the same key material, and just use different meta data (like expiry date).