Is it possible to detect SSL private key changes?

Question

I wonder if it would be possible to detect a change of an SSL private key? If you change the key, then I think one must issue a new certificate, but new certificates could be issued without changing the key, right?

Or is it possible to keep the certificate, and change the key? I'd assume, no.

As far as I know, e.g. when a certificate expires, one must generate a new key and with that key a certificate signing request, from which a new certificate is created.

Answer 1

A certificate is signed, which means that not a single bit can be changed in it without breaking the signature. Certificates are immutable. When you want to "change the key" or "change the validity dates", then you need a brand new certificate. Renewal is a business concept; at the X.509 level there is a certificate, and then there is another one, and both live independently of each other.

A certificate contains a name and a public key. The same public key may appear in several certificates; there is no technical rule that forces a new key pair generation whenever a new certificate is issued. There can be legal or business rules, though: a CA is supposed to follow its published certification policy, and that policy may mandate a new key pair for a certificate renewal.

We may note that when a CA wants to "renew" a certificate without changing the public key, then it can do it by itself: the CA already knows everything which goes into the new certificate. Thus, that kind of renewal can be done automatically without needing to talk to the certificate owner at all. Not all CA do that.

---

For each public key, there is a corresponding private key. The private key, formally, is the knowledge of the mathematical elements which allow to run the "private key operations" (signature generation, asymmetric decryption). Mathematically, this knowledge can be encoded in various ways. In RSA, the public key is a pair of big integers:

• the modulus n
• the public exponent e

The modulus is a product of two big prime integers p and q. The private key is, really, the knowledge of p and q. However, in practice, the private key is encoded as several big integers:

• the modulus n
• the public exponent e
• p
• q
• the private exponent d
• d_p = d mod p-1
• d_q = d mod q-1
• 1/q mod p

The "private exponent" is a value d such that e·d = 1 modulo both p-1 and q-1. It so happens that there are several (actually, infinitely many) possible values for d, for a given public key (n,e). This is what others have pointed out: you can have "several" private keys for the same public key. However, I may argue that all these private keys are in fact several representations of a unique "true" private key, which is the knowledge of p and q. All these so-called private keys will compute the same things for the same inputs, and produce the same outputs. Really, there is only one private key.

(Mathematically, looking for equivalent values for d_p and d_q has been employed to gain some performance on some low-power architectures, namely smart cards; the trick is that making d_p slightly longer can imply a performance improvement if the longer value has a lower Hamming weight.)

So I'd say that you can forget this notion of "changing the private key without changing the public key". It adds only confusion.

---

Finally, the public key of a SSL server is in the server's certificate, which is public and sent to the client. If the client remembers the last certificate used by a given server, then it can certainly report when that certificate is changed, and what has changed exactly. In particular whether the public key is the same as previously, or another one.

There is a Firefox add-on for that.

Note that certificates which change are a normal occurrence on the Web, not only for renewals (CA who sell certificates like it a lot when they can sell more certificates, and that's a primary driver for the short life times of existing server's certificates) but also for multi-frontends: when a server is hosted on several machines with load-balancing, each machine may have its own certificate, distinct from the certificates of other frontends.

Answer 2

Let's try to break this down. The way you've asked this has actually created several questions:

First, if you change the private key, you must issue a new certificate. A certificate is generated by signing a certificate signing request. A certificate signing request contains the public key of the requestor. Since the public and private key are mathematically related and the certificate is, at its most basic, signing the public key portion of that system, changing the private key will require a change of the certificate.

Therefore, it is not possible to keep the certificate and change the key. However, you have a few more questions in there. Here's the next one that I see:

"Must I generate a new key pair to make a certificate signing request?" The answer to this one is "No." While many people will take the CSR as an opportunity to change the public/private key, it is not a requirement. You can easily generate a new CSR with the same key and have it signed for a new time period or even by a new trust vendor!

Lastly, your very first question. "Is it possible to detect the change of an SSL private key?" The answer is yes. When the public key changes, you are guaranteed that the private key changed. Remember that the certificate contains a signed copy of the public key. Since this is the case, you can easily check to see if the public key of the current certificate matches the previous public key. If they don't match, the private key has changed.

Hope this helps!

Answer 3

No, not always.

But it's highly unlikely anyone would follow the process below unless subverting your application's pre-conditions was more important retaining their key pair security:

1. Create a RSA key pair.
2. Pick a random value M > 1
3. Multiply the private exponent (a/k/a private key) by M * Phi(N) where Phi(N) is Euler's totient function*.
4. You now have two private keys that generate the same public key.

See this crypto stack exchange question/answer for more detailed information; as having two keys sharing related private exponents is deeply insecure.

_{* I think. I've forgotten most of the advanced maths I once knew.}

Answer 4

As a rule, yes. Changing the private key means changing the public key, which means issuing a new certificate. You can get a new certificate with the same public key as before, but you can easily compare the old and new cert to see if the key is the same.

No, you cannot keep the same certificate while changing the key. Since the public key is embedded into the certificate, a different key means a different cert. It'd be like trying to change your passport number while keeping the same passport.

@LateralFractal is correct that it is possible to create two RSA private keys which share the same public key, but as a rule, this doesn't happen. You'd have to do the math yourself as no crypto library implements this feature.