|
Posted by Doug McIntyre on June 11, 2007, 3:19 pm
If you were Registered and logged in, you could reply and use other advanced thread options >> Am Sun, 10 Jun 2007 22:43:22 -0700 schrieb Ramon F Herrera:
>>
>> > Every time I add a cert to a web server (to support https://) I have
>> > to be around and type the passphrase at reboot time.
>>
>> openssl rsa -in $server.key -out server_nopassword.key
>> openssl x509 -in server.pem -out server_nopassword.pem
>Thanks to Burkhard for his succinct explanation, which takes care of
>the syntax. Can anyone please delve into the semantics?
Its not the cert that is protected, its the private key (used to make
the csr, which gets signed by the CA, which becomes the cert).
Initially SSL was implemented to have the private key password
encrypted that would have be entered upon each time the SSL protected
process started up.
The reasoning being, is if your private key is compromised, all SSL
communication can be easily decoded if the traffic is intercepted. The
private key is the whole key to any and all protection offered by SSL.
Many admins find the convience of the private key not being password
protected to auto-start the web process out-weighs (or they have no
concept of what they are doing either way) the protection having the
private-key password protected.
What the commands above do is to remove any password on the private
key and save the private key out fresh without the password on it.
Thus if somebody compromised your server and took these keys, and had
a way to intercept traffic going your way, they can decrypt all SSL traffic.
If you leave the private keyfile password encrypted, and have to type
in the password each time your web process starts, even if your
machine is compromised, the hacker would still have to break the
password protecting the private key in order to decrypt the SSL
encryption traffic they intercept.
So, its your choice. Convience, or security against that sort of attack.
| 
XML site map