Configuring Apache with SSL
The following instructions assume that you wish to run both a secure server (on port 443) and a regular server (on port 80). First, you need to configure the server to listen on both ports. Either edit
/etc/apache2/ports.conf (in Debian; this is included in
apache2.conf) or edit
/etc/apache2/apache2.conf directly to include the lines:
/etc/apache2/sites-enabled/yoursite to use the SSL settings. Separating the regular and secure server settings out by using VirtualHosts is the easiest option in terms of maintainability. Any configuration outside the VirtualHosts sections (such as setting the ServerAdmin) will apply to both (and any other) VirtualHosts. Add the following section to your config file:
# SSL/TLS settings
SSLProtocol -all +TLSv1 +SSLv3
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
A few notes on this configuration:
SSLEngine must be enabled so that the server uses SSL.
DocumentRoot sets the root directory for this virtual host. This means that you can separate secure content entirely from regular content.
SSLRequireSSL requires SSL to be used (on this virtual host): i.e., a user can't connect to this host using a regular HTTP request. This is why we separate out the secure and regular root directory.
SSLProtocol disables all protocols other than TLS v1.0 and SSL v3.0. This will be OK for current web browsers.
SSLCipherSuite is set to use only HIGH and MEDIUM security cipher suites. SHA1 is considered to be more secure than MD5 so is preferred.
SSLCertificateKeyFile should be set to the locations where you put your certificate and key files.
SSLVerifyClient should be set to none if not using client authentication.
To run the regular server on port 80, add the following section to the config file:
# Host-specific directory setup, options, etc
# Most of these options are likely to be set outside the VirtualHosts
After you've saved the edited configuration file, restart the web server. If you did use a passphrase when generating your certificate, you'll need to enter it when challenged.
Create a basic index.html page wherever the root directory for your web server is located, if you don't already have content there.
Then point your web browser at
https://www.yoursite.com. You should see an SSL connection opened and the page delivered. If you're using a self-signed certificate, your browser will pop up an alert warning you that the server's identity cannot be verified. You can choose to view and accept the certificate. If using an external certificate, it should all happen without intervention.
Make sure as well that you can't access the protected content using http://. If you try, you should get an error message.
If it's not working as expected, first check that your server is actually running, using
ps -a | grep apache. If that doesn't return anything, try restarting it, and check for error messages on the terminal.
Also check that the permissions on your key and certificate files are set correctly (see above), as well as the permissions on your test HTML file and its parent directory.
Next, check the logs. You should check both the main server logs and also the SSL logs that you set up in your config file above. If you don't get anything useful, try changing the LogLevel value in the Apache2 config file to "debug", restart Apache2, and test again. This should give more logfile data.
If you are running a regular web server on port 80 as well, try fetching a test page via http:// rather than https:// to help identify whether the problem is with the web server or with the SSL connection. Note that in the setup above, the web server's root directory is different for http:// and https://, so you won't (or shouldn't!) be able to access the same content. If your test page in the http:// root directory works fine, though, and your test page in the https:// root directory doesn't, then that can help you to pinpoint the problem.
If the problem is the SSL connection, a useful tool is
s_client, which is a diagnostic tool for troubleshooting TLS/SSL connections. The basic usage is:
/usr/bin/openssl s_client -connect localhost:443. There are numerous other options as well, for which you can check the documentation. If you get error messages, this should help you in locating the problem.