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.
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;
Things that might make me encrypt:
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:
Backup copies of the key should be password protected and secured as if they weren't password protected.