Is it good practice to remove the password from a ssl cert? – Problems with loading a website are often blamed on the Internet connection, but even the most perfectly set up network cannot help if there is no service to reply at your destination. One of the most popular HTTP servers used for this task is Apache2. Much of Apache’s popularity can be attributed to its easy installation and use, but never the less it is possible to run into problems with even the easiest of the software. If you’ve encountered an issue loading your web page, follow these simple troubleshooting methods outlined in this guide to attempt to get your web server back up and working again. Below are some tips in manage your apache2 server when you find problem about apache-2.2, ssl-certificate, , , .
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?
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;
- 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.
- 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.
- Certificates naturally expire making their attack surface limited.
- Host based security systems such as traditionally permissions and SELinux offer a robust means of protecting certificates on the platform.
- 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:
- If you used the certificate to perform mutual authentication.
- 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)
- The certificate is multi-purpose in some other fashion.
- The certificates purpose is to ensure the integrity high value data (medical records, financial transactions and the like).
- 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:
- Don’t have a password on the key, and protect it so that only services that need it can access it.
- 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.