You do not need a pass phrase, in fact usually a pass phrase willKhalid Schofield wrote:
That being said, if there is a risk that someone could read your private
key off your webserver, either by physically stealing the server or an
untrusted admin, a pass phrase isn't a bad idea. But in this case you
have to consider what else would be compromised, and if it's easier just
to revoke that cert and get another one.
My recommendation would be to not use a pass phrase for SSL services,
but use a passphrase for a certificate that you use to sign other
certificates: i.e. VPN user authentication, authenticating SSL users by
issuing them each their own certificate, or similar.
The process of setting up signed cert is as follows:
1. Generate your private key and secure file permissions (you want to do
this in a secure fashion, i.e. on the box directly as a root or a
private user). Guard this file: if it is compromised the security SSL
provides is compromised.:
openssl genrsa -out secure.example.com.key 4096
chmod 400 secure.example.com.key
2. Generate your certificate signing request (CSR), you will be prompted
to answer a bunch of questions country, state, location, organization,
organization unit, common name and email address, answer these accuratly
or else the certificate authority will not sign your key, there is one
of special note: Common Name (CN) needs to be the exact domain name of
your SSL site i.e. secure.example.com in this example:
openssl req -new -nodes -key secure.example.com.key -out
secure.example.com.csr
3. Send the CSR (you can open the file and copy and paste the contents
into an email, or the certificate authority's website) to the
certificate authority along with what ever other documentation they
require (there job is to verify you are who you are requesting a
certificate for before signing the key, they usally require some proof
of domain ownership and everything else you entered in step 2).
4. You will then receive your signed certificate, you can either keep
the certificate in a separate file from your private key, or cat them
together to make a .pem file: cat secure.example.com.key
secure.example.com.cert > secure.example.com.pem; chmod 400
secure.example.com.pem
Configure apache to use your new cert and key:
SSLCertificateFile /etc/ssl/secure.example.com.cert
SSLCertificateKeyFile /etc/ssl/secure.example.com.key
- or -
SSLCertificateFile /etc/ssl/secure.example.com.key
Since apache is chrooted, have to restart it to read the new key and
certificate.
Dustin Lundquist
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Matt Mackall | Re: [PATCH] x86: fix unconditional arch/x86/kernel/pcspeaker.c compiling |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
git: | |
