Apache HTTP Server Version 2.4
Apache HTTP Server Version 2.4
The wise man doesn't give the right answers, he poses the right questions.
-- Claude Levi-Strauss
Errors such as ``mod_ssl: Child could not open
SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows)
[...] System: Permission denied (errno: 13)'' are usually
caused by overly restrictive permissions on the parent directories.
Make sure that all parent directories (here /opt,
/opt/apache and /opt/apache/logs) have the x-bit
set for, at minimum, the UID under which Apache's children are running (see
the User directive).
Cryptographic software needs a source of unpredictable data
to work correctly. Many open source operating systems provide
a "randomness device" that serves this purpose (usually named
/dev/random). On other systems, applications have to
seed the OpenSSL Pseudo Random Number Generator (PRNG) manually with
appropriate data before generating keys or performing public key
encryption. As of version 0.9.5, the OpenSSL functions that need
randomness report an error if the PRNG has not been seeded with
at least 128 bits of randomness.
To prevent this error, mod_ssl has to provide
enough entropy to the PRNG to allow it to work correctly. This can
be done via the SSLRandomSeed
directive.
SSL_XXX variables not
available to my CGI & SSI scripts?Yes. HTTP and HTTPS use different server ports (HTTP binds to port 80, HTTPS to port 443), so there is no direct conflict between them. You can either run two separate server instances bound to these ports, or use Apache's elegant virtual hosting facility to create two virtual servers, both served by the same instance of Apache - one responding over HTTP to requests on port 80, and the other responding over HTTPS to requests on port 443.
You can run HTTPS on any port, but the standards specify port 443, which
is where any HTTPS compliant browser will look by default. You can force
your browser to look on a different port by specifying it in the URL. For
example, if your server is set up to serve pages over HTTPS on port 8080,
you can access them at https://example.com:8080/
While you usually just use
$ telnet localhost 80
GET / HTTP/1.0
for simple testing of Apache via HTTP, it's not so easy for
HTTPS because of the SSL protocol between TCP and HTTP. With the
help of OpenSSL's s_client command, however, you can
do a similar check via HTTPS:
$ openssl s_client -connect localhost:443 -state -debug
GET / HTTP/1.0
Before the actual HTTP response you will receive detailed information about the SSL handshake. For a more general command line client which directly understands both HTTP and HTTPS, can perform GET and POST operations, can use a proxy, supports byte ranges, etc. you should have a look at the nifty cURL tool. Using this, you can check that Apache is responding correctly to requests via HTTP and HTTPS as follows:
$ curl http://localhost/
$ curl https://localhost/
This can happen when you try to connect to a HTTPS server (or virtual
server) via HTTP (eg, using http://example.com/ instead of
https://example.com). It can also happen when trying to
connect via HTTPS to a HTTP server (eg, using
https://example.com/ on a server which doesn't support HTTPS,
or which supports it on a non-standard port). Make sure that you're
connecting to a (virtual) server that supports SSL.
This error can be caused by an incorrect configuration.
Please make sure that your Listen directives match your
<VirtualHost>
directives. If all else fails, please start afresh, using the default
configuration provided by mod_ssl.
SSL_XXX variables
not available to my CGI & SSI scripts?Please make sure you have ``SSLOptions +StdEnvVars''
enabled for the context of your CGI/SSI requests.
Usually, to switch between HTTP and HTTPS, you have to use
fully-qualified hyperlinks (because you have to change the URL
scheme). Using mod_rewrite however, you can
manipulate relative hyperlinks, to achieve the same effect.
RewriteEngine on
RewriteRule "^/(.*)_SSL$" "https://%{SERVER_NAME}/$1" [R,L]
RewriteRule "^/(.*)_NOSSL$" "http://%{SERVER_NAME}/$1" [R,L]
This rewrite ruleset lets you use hyperlinks of the form
<a href="document.html_SSL">, to switch to HTTPS
in a relative link. (Replace SSL with NOSSL to switch to HTTP.)
An RSA private key file is a digital file that you can use to decrypt messages sent to you. It has a public component which you distribute (via your Certificate file) which allows people to encrypt those messages to you.
A Certificate Signing Request (CSR) is a digital file which contains your public key and your name. You send the CSR to a Certifying Authority (CA), who will convert it into a real Certificate, by signing it.
A Certificate contains your RSA public key, your name, the name of the CA, and is digitally signed by the CA. Browsers that know the CA can verify the signature on that Certificate, thereby obtaining your RSA public key. That enables them to send messages which only you can decrypt.
See the Introduction chapter for a general description of the SSL protocol.
Yes. In general, starting Apache with
mod_ssl built-in is just like starting Apache
without it. However, if you have a passphrase on your SSL private
key file, a startup dialog will pop up which asks you to enter the
pass phrase.
Having to manually enter the passphrase when starting the server can be problematic - for example, when starting the server from the system boot scripts. In this case, you can follow the steps below to remove the passphrase from your private key. Bear in mind that doing so brings additional security risks - proceed with caution!
PATH.server.key and
server.crt files:$ openssl req -new -x509 -nodes -out server.crt
-keyout server.keyhttpd.conf
file:
SSLCertificateFile "/path/to/this/server.crt" SSLCertificateKeyFile "/path/to/this/server.key"
server.key does not have any passphrase.
To add a passphrase to the key, you should run the following
command, and enter & verify the passphrase as requested.$ openssl rsa -des3 -in server.key -out
server.key.new
$ mv server.key.new server.key
server.key file, and the passphrase
you entered, in a secure location.
Here is a step-by-step description:
PATH.
$ openssl genrsa -des3 -out server.key 2048server.key file and the
pass-phrase you entered in a secure location.
You can see the details of this RSA private key by using the command:$ openssl rsa -noout -text -in server.key$ openssl rsa -in server.key -out server.key.unsecure$ openssl req -new -key server.key -out server.csrhttps://www.foo.dom/, enter "www.foo.dom" here.
You can see the details of this CSR by using$ openssl req -noout -text -in server.csr$ openssl x509 -noout -text -in server.crtserver.key and
server.crt. These can be used as follows in your
httpd.conf file:
SSLCertificateFile "/path/to/this/server.crt" SSLCertificateKeyFile "/path/to/this/server.key"The
server.csr file is no longer needed.
The short answer is to use the CA.sh or CA.pl
script provided by OpenSSL. Unless you have a good reason not to,
you should use these for preference. If you cannot, you can create a
self-signed certificate as follows:
$ openssl genrsa -des3 -out server.key 2048server.key file and the
pass-phrase you entered in a secure location.
You can see the details of this RSA private key by using the
command:$ openssl rsa -noout -text -in server.key$ openssl rsa -in server.key -out server.key.unsecure$ openssl req -new -x509 -nodes -sha1 -days 365
-key server.key -out server.crt -extensions usr_certserver.crt file.$ openssl x509 -noout -text -in server.crtYou simply have to read it with the old pass-phrase and write it again, specifying the new pass-phrase. You can accomplish this with the following commands:
$ openssl rsa -des3 -in server.key -out server.key.new
$ mv server.key.new server.key
The first time you're asked for a PEM pass-phrase, you should enter the old pass-phrase. After that, you'll be asked again to enter a pass-phrase - this time, use the new pass-phrase. If you are asked to verify the pass-phrase, you'll need to enter the new pass-phrase a second time.
The reason this dialog pops up at startup and every re-start is that the RSA private key inside your server.key file is stored in encrypted format for security reasons. The pass-phrase is needed to decrypt this file, so it can be read and parsed. Removing the pass-phrase removes a layer of security from your server - proceed with caution!
$ cp server.key server.key.org$ openssl rsa -in server.key.org -out server.key$ chmod 400 server.keyNow server.key contains an unencrypted copy of the key.
If you point your server at this file, it will not prompt you for a
pass-phrase. HOWEVER, if anyone gets this key they will be able to
impersonate you on the net. PLEASE make sure that the permissions on this
file are such that only root or the web server user can read it
(preferably get your web server to start as root but run as another
user, and have the key readable only by root).
As an alternative approach you can use the ``SSLPassPhraseDialog
exec:/path/to/program'' facility. Bear in mind that this is
neither more nor less secure, of course.
A private key contains a series of numbers. Two of these numbers form the "public key", the others are part of the "private key". The "public key" bits are included when you generate a CSR, and subsequently form part of the associated Certificate.
To check that the public key in your Certificate matches the public portion of your private key, you simply need to compare these numbers. To view the Certificate and the key run the commands:
$ openssl x509 -noout -text -in server.crt
$ openssl rsa -noout -text -in server.key
The `modulus' and the `public exponent' portions in the key and the Certificate must match. As the public exponent is usually 65537 and it's difficult to visually check that the long modulus numbers are the same, you can use the following approach:
$ openssl x509 -noout -modulus -in server.crt | openssl md5
$ openssl rsa -noout -modulus -in server.key | openssl md5
This leaves you with two rather shorter numbers to compare. It is, in theory, possible that these numbers may be the same, without the modulus numbers being the same, but the chances of this are overwhelmingly remote.
Should you wish to check to which key or certificate a particular CSR belongs you can perform the same calculation on the CSR as follows:
$ openssl req -noout -modulus -in server.csr | openssl md5
The default certificate format for OpenSSL is PEM, which is simply
Base64 encoded DER, with header and footer lines. For some applications
(e.g. Microsoft Internet Explorer) you need the certificate in plain DER
format. You can convert a PEM file cert.pem into the
corresponding DER file cert.der using the following command:
$ openssl x509 -in cert.pem -out cert.der -outform DER
One reason this might happen is because your server certificate is signed by an intermediate CA. Various CAs, such as Verisign or Thawte, have started signing certificates not with their root certificate but with intermediate certificates.
Intermediate CA certificates lie between the root CA certificate (which is installed in the browsers) and the server certificate (which you installed on the server). In order for the browser to be able to traverse and verify the trust chain from the server certificate to the root certificate it needs need to be given the intermediate certificates. The CAs should be able to provide you such intermediate certificate packages that can be installed on the server.
You need to include those intermediate certificates with the
SSLCertificateChainFile
directive.