I have read at several blogs now that one should remove passwords from SSL certificates in order to avoid password prompts during Apache restarts.

Is this true and does this pose any security risks?

  • If you are really concerned, there is hardware available, where your private key can be stored on a USB device, and will never be retrievable. This won't really work in a hosted environment though.
    – Zoredache
    Nov 10, 2011 at 21:35
  • I note in passing, just to avoid confusion, that the certificate is never encrypted, nor would there be any point in doing so; for the SSL handshake to complete, the certificate has to be offered in plaintext to anyone who asks for it. A certificate is just a third-party-signed public key. It's the private key, the asymmetric counterpart of the public key (which is able to decrypt traffic encrypted to the public key), that can be stored encrypted and about which you are asking.
    – MadHatter
    Nov 11, 2011 at 8:14

3 Answers 3


Yeah, it will stop the prompts being sent to the terminal when starting a web server.

And yes it does pose a security risk because where before the certificate was encrypted it is now in plain text. This means it might be possible to steal a completely working certificate from the machine.

Whether this poses a significant security risk to you depends on what the repercussions would be if it happened to you and what the you gain from doing it this way.

If it's more important to you that services should restart gracefully even if unattended than the security of the SSL system overall then it's a straight forward answer.

Personally, I find keeping decrypted copies of SSL certificates overall has more pros than cons for my typical workload, here's why;

  1. An attacker would still have a copy of the certificate even if it was encrypted so it would be your duty to revoke it anyway.
  2. These days it's far easier for an attacker to obtain a valid certificate for your site via social engineering than to steal a working copy of one.
  3. Certificates naturally expire making their attack surface limited.
  4. Host based security systems such as traditionally permissions and SELinux offer a robust means of protecting certificates on the platform.
  5. A certificate isn't a be-all and end-all of a secure system. There are many other aspects to consider such as the data you store, the media you store it on and the value and/or personal nature of the data.

Things that might make me encrypt:

  1. If you used the certificate to perform mutual authentication.
  2. It's a wildcard certificate or a certificate which hosts multiple domains (the losses double, or triple or whatever many hosts can be used for it)
  3. The certificate is multi-purpose in some other fashion.
  4. The certificates purpose is to ensure the integrity high value data (medical records, financial transactions and the like).
  5. The other end expects a high degree of trust and/or is reliant on the integrity of your system to make operational decisions.

Ultimately, don't rely on others to make security decisions for you. You need to weight the risks and determine what is best for you and your institution using as much information as possible.


It provides some more security, but the reality is that if someone has gotten far enough into your system to get access to your private SSL key than you probably have bigger issues.

From a practical perspective, do you really want to be there every time apache needs to be restarted to put in a password?

One thing you could do is keep the key unpassword protected on your server (and protect it via normal system security) and keep the backup of the key you store elsewhere with a password. So if someone is able to scrap the key from somewhere other than your server (much more likely, think someones laptop getting stolen with it on their desktop) it is still protected.


Cient keys used for login should be password protected.

If you want SSL based services to restart without manual intervention, you have two options:

  1. Don't have a password on the key, and protect it so that only services that need it can access it.
  2. Store the password in plain text or a plain text equivalent on the server so that services which need it can provide the password. (You may end up with multiple copies of the password in poorly secured configuration files.)

Backup copies of the key should be password protected and secured as if they weren't password protected.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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