Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

As I understand it, a certificate is used only for verifying the identity of the server. Are there any security benefits for changing them frequently (once a week for example)?

If this is done so that a new symmetric key can be negotiated for each session (for perfect forward secrecy (PFS), say), can't it be done without needing to change the certificate? Am I misunderstanding how certificates are used?

share|improve this question

1 Answer 1

up vote 3 down vote accepted

Renewing the certificate has no benefit, except if you use it as a substitute for revocation. Normally, a certificate is issued by the CA for some time (say, one or two years); to cope with abnormal conditions (e.g. the private key was stolen), the CA will regularly publish a list of "revoked certificates". A revoked certificate which looks good cryptographically (it is properly signed and all), but must nonetheless be rejected because the CA says it so. Revocation status check entails downloading the current CRL, verifying its signature and looking at its contents; this is bulky and cumbersome, and a lot of SSL clients (say, Web browsers) are tempted not to download CRL. If the certificates are very short-lived, then not checking revocation status can be tolerated: the CA, presumably, would not renew a certificate that it would consider as revoked.

This is an edge case. Usually, it is considered that the overhead of renewing certificates every week outweighs the cost of publishing and processing a new CRL every week.

Renewing the private key may have benefits. Remember that the certificate contains only the public key, so "renewing the certificate" does not necessarily imply changing the private and public keys; the CA could just take the existing certificate, change the validity dates, and resign it. But if the private key is changed, then so is the public key; changing the private key thus implies obtaining a new certificate.

Using a new private key may help in achieving a reduced form of Perfect Forward Secrecy. The issue that we want to deal with is the possibility of theft of the server's private key after the key was used. If the attacker records a TLS session, then, at a later point, steals the private key, then he may decrypt the session that he previously recorded.

Renewing the private key will grant you PFS insofar as the previous key is destroyed; it is not the obtaining the new key which grants PFS, but deleting the old one. Presumably, once deleted, the old key can no longer be stolen. This must be taken with a grain of salt, though: during the week the private key was active, it was stored on a physical medium (the hard disk), and really deleting data from physical mediums is tricky. It may also have been copied to some backup tapes or something similar.

SSL/TLS has a better way to obtain PFS. You get PFS by using one of the "DHE" cipher suites. With these cipher suites, the server's private key (the one corresponding to the server's certificate) is used only for signatures; the actual key for encryption (precisely, for key exchange) is a dynamically generated DH key pair, which the server never stores; the server keeps the private key in RAM only, for a few seconds. Since the key is never written to a file, it is much less susceptible to ulterior theft.

The symmetric key has nothing to do with PFS. In SSL/TLS, you always get a new symmetric key from each handshake: client and server send random values to each other, and these values enter in the computation of the symmetric encryption keys. PFS is not about using a new symmetric key; it is about not storing the asymmetric private key which would allow for reconstruction of the symmetric key (the DH private key for a DHE cipher suite, the RSA private key for a RSA cipher suite).


For a primer on how SSL works, read this answer.

share|improve this answer
    
So, if you're using a DHE cipher then the server's public and private keys are used only for verifying identity. A generated DH pair is used for exchanging the symmetric key. Did I get this right? –  user1033777 Sep 26 '13 at 17:50
    
Yes. One alternate way to see it is to consider that the server acts as a kind of sub-CA, emitting for himself a short-lived "certificate" (the ServerKeyExchange message in the TLS handshake) containing its DH public key. –  Tom Leek Sep 26 '13 at 18:00
    
I've had to remind work colleges in the past that renewing a certificate is pointless unless you also generate a new key pair. The security in the system comes from the key pair, not the mystical ivory tower of VeriSign. –  LateralFractal Sep 26 '13 at 23:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.