openssl - should I generate a key with a password?

Right now when I generate a CSR, the procedure goes something like this:
- Generate .key with a password
- Use the .key to generate .csr
- Remove the password from .key file

Is having the password on there while I generate the CSR any better than initially generating the CSR using a .key without a password?  

If it's not better, what is the point of putting a password on the .key? Is this something that only applies when there are multiple users on the system?  (I am the only ssh user)
Who is Participating?
arnoldConnect With a Mentor Commented:
IT is up to you.

You could put it in place to avoid the certificate/key leaking out. Once you have the certificate, you can strip out the password from the key and be done with it.
This does not deal with individuals who have administrative access to the system gaining copying out the key and certificate.
If you keep a backup of the key/certificate offsite etc., it would be advisable to have a password on the private key.
It depends on the purpose for which you will be using the certificate.

If it is for a service, web, secure mail, secure POP, secure IMAP, etc. you should leave the key without a password. If you have a password, when the service starts, a prompt for the password will be generated.

If the certificate will be used as a means to identify you as a user accessing other systems, you could consider setting the password this way no one other than you will be able to use the key/certificate combination to authenticate into .....
Lets say there is an internal site that uses personal certificates as a means by authentication, and then a username/password for authorization.
Steve BinkCommented:
You can also remove the password before generating the request, and still generate the same request.  

The purpose of passwording the private key is that it is the "real" key for the set.  Anything encrypted using the private key is "known" to have come from the owner of the key.  Anyone with the public key (the certificate) can decrypt it, as well as encrypt messages of their own for decryption by the private key.  In practice, though, the passphrase tends to get in the way.  Anytime you use the private key, the system/application/whatever will need the passphrase to access it.  This means, for example, Apache needs to stop during load and ask for it.  When you're installing the certificate on a public web server, this is, at best, inconvenient.

If you do remove the passphrase, be *sure* to properly safeguard your key.  The file should have permissions of 400, owned by root.  This is not just a "multiple user system" practice - this is a basic security practice.
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

A key when used by apache or any other service likely can not have 400 permissions as it is read in within the SSL certificate configuration section of the application at a time when it is running as the service account versus as the startup root..
Steve BinkCommented:
>>> A key when used by apache or any other service likely can not have 400 permissions

All of my .pem files are 400, and Apache reads them just fine during startup.  

My installation is configured to run as a specific local user (not root) and is managed by the normal init.d script.  Looking at `ps -aF | grep 'apache'` shows all the threads under the auspices of the assigned user.  The private key is unencrypted, owned by root, and has 400 permissions.
Steve BinkCommented:
After thinking about your statement a few more moments, it made sense.  Why is my assigned user able to read the key?  Answer: it isn't.  Apache's parent thread spawns as root, then launches the other processes using the User directive.  Rechecking my ps output, I see the parent thread I missed the first time.  That also makes sense in the context of the service starting...all of them are owned by root.  

In any case, 400 permissions are the recommendation after decrypting your private key.
jeff_zuckerAuthor Commented:
Very informative answers so far....

I am using this for web services and the reason I don't want a password is for when I restart Apache.  If I'm understanding your answers, there is *is* an advantage to using the 3 step process I mentioned vs. a 2 step process of generating a key without a password and then a csr (all with no pws)?  Just want to clarify if that process of putting  password on and then taking it off later is a waste of time or an important step.

Steve BinkConnect With a Mentor Commented:
>>> If you keep a backup of the key/certificate offsite etc., it would be advisable to have a password on the private key.

Agreed, though I would skip the "if" part of that.  :)  Make sure you keep a backup of the key, and keep the passphrase on it.  

That also sort of answers the other question: generate the key with a password, and remove it from the copy you use for Apache.  As a general rule, private keys need that protection.  Its unencrypted use with Apache is an exception to the rule.
jeff_zuckerAuthor Commented:
This really clears things up.  Thank you.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.