Following Eric Covener's advise from
I'm using this space to kick-off an SSL How-to, which we will use to replace the current, highly out-dated one.
In the first step I'll just fill in the titles. I really hope for some participation here Please also take into consideration features from 2.4, such as OSCP
Also consider that recommendations should include security at a high enough level to make sense. For generating certs, that means 2048, for picking cipher suites, that means strong encryption, etc.
create a (self-signed) certificate or certificate request
add a listen directive
make sure Listen 443 is *before* Listen 80..
Why before??? --DRuggeri
add a VH *:443
elaborate on the option of SNI.
add cert-related directives
These are two. Not 3409.
- SSLEngine On
- SSLCertificateFile /path/to/cert.pem
- SSLCertificateKeyFile /path/to/key.pem
- SSLCertificateCAFile or SSLCertificateCAPath /path/to/target
Smart to have:
SSLCipherSuite <Insert cipher suite that is common, but strong>
- SSLProtocol SSLv3 TLSv1
We should probably follow: http://journal.paul.querna.org/articles/2010/07/10/overclocking-mod_ssl/ for some good guidelines on SSLCipherSuite, or mod_ssl in general
Required for client auth
- SSLVerifyClient require
Enabling OCSP for client auth
Handling the passphrase
When you encrypt a private key with a passphrase, httpd will need access to that passphrase. There are three ways to handle this situation:
- Do nothing - In this case, httpd will prompt the server administrator for the passphrase when starting the instance. This is often an undesired effect in the event you have configured httpd to start via init scripts or are using some other method for automated startup.
- Use SSLPassPhraseDialog "exec:/path/to/command" - there are currently only two requirements for using this method. First, /path/to/command must be a file (TBD: will Daniel ever submit the patch to remove this restriction?) and should be executable as the root user. Second, the STDOUT output to /path/to/command must deliver the full passphrase. Using this method allows you to take any security mechanisms you have in mind to any extent you can imagine before delivering the passphrase via the /path/to/command.
- Decrypt the key - To do this, you would need to use openssl to remove the encryption on the key like so: openssl rsa -in key.pem -out newkey.pem
See also RemoveSSLCertPassPhrase
WARNING: Although you may implement elaborate methods to protect your passphrase, the httpd image in memory contains the passphrase as a string which can be obtained by triggering a core dump (ie. in the event the root process is compromised).