I have a system where clients securely communicate with a remote server over internet using TLS. In this scenario, how CA signed server certificates are better than pre-sharing the server public key? When the server private key is compromised, new keys pairs will replace the old then it is tiresome to do the pre-sharing process for all clients again. In this case, i assume certificate has an upper hand. But am i right?

  • 1
    Yes - but you also have that problem whenever you're doing a key rollover. This would be about 2 years, 4 would max. Additionally, there are many scenarios where you do not know all clients an advance, thus pre-sharing is simply impossible. Side note: in such a setup, you would usually not publish the public key but a self-signed certificate for that key.
    – Tobi Nary
    Commented Jul 19, 2017 at 14:11

2 Answers 2


Let's compare the workflows of the two processes, specifically how the handle key compromise.

Pre-shared Secret

The server generates a keypair, you copy this to every client machine (manually, through a script, etc). When connecting to the server, the client will check that the public key presented matches the one they have cached for that server (conceptually, this is the same as SSH's fingerprint id method).

Upside: no need for the inconvenience of getting a CA-signed certificate. You can generate the server's keypair and start deploying it to clients immediately.

Downside: Recovering from a key compromise is difficult or impossible because there is no mechanism for the server to notify clients of a key compromise, except by pushing a new keypair to all clients. Consider that an attacker has the server's private key and can intercept traffic between the client and server (both to block the updated keypair push, and to man-in-the-middle the client's connection to the server). The client will trust the attacker and believe that it is talking to the authentic server and there is nothing you can do to prevent this because at a fundamental level, pre-shared secrets have no revocation mechanism.


Yes, it's annoying (and sometimes expensive) to get a certificate, but the trust no longer depends on your ability to push the pre-shared key to the clients.

Part of the validation process for a certificate is for the client to reach out to the CA and ensure that the certificate is not revoked and if it fails to reach the CA, this counts as a failure. Spoofing this revocation check requires the attacker to compromise not only the server's private key, but the CA's private key as well. If the server realizes that it's keypair has been compromised and asks the CA to revoke it, all clients will know immediately because the online revocation checks will fail.

Revocation is the main reason to use certificates here, but also consider that an attacker can intercept the initial public key push and replace it with their own public key. Maybe you are the network admin and can guarentee to deploy the public keys securely, but certificates make this a moot point because even if the attacker can intercept the certificate deployment, spoofing a cert requires compromising the CA.


With pre-shared keys, you need to secure ALL endpoints: server and clients. If a single one of the participant is compromised, you have to re-distribute a new set of keys.

Also, the only time you need an external secure channel with a PKI is when you initially setup your trust chain. After that, you do not have to use a secure channel any more unless your root is compromised.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .