Apache and SSL

When you want to transmit information through an untrusted channel (i.e. internet) and want to keep that information private, guarantee it’s integrity and keep the authenticity then you need something like SSL. The mod_ssl module provides strong cryptography for the Apache web server through the SSL (Secure Sockets Layer, v2/v3) and the TLS (Transport Layer Security, v1) protocols implementation of OpenSSL. It also provides message digest mechanism to guarantee messages integrity and digital signature for authenticity.

Understanding SSL and TLS

WebAdmins tend to transmit sensitive information safely and securely. To protect yourself from threats like eavesdropping, tampering and impersonation OpenSSL provides mechanisms to encrypt, check message integrity and authenticate your sensitive information.

The communication between both ends starts by the so called handshake process. The handshake allows the server to authenticate itself to the client using public-key techniques, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.

The process starts when the client sends its SSL version number, random data, etc and a list of cipher suites it supports to the Apache webserver. The cipher suite is a set of cryptographic algorithms that will be used for authentication and session encryption. Apache then sends back its SSL version and other data and chooses a cipher suite (the strongest enabled cipher suites they have in common) from the list sent by the client, notifies to client the choosen cipher suite and sends its certificate (which contains the server’s public key).

Upon receiving the server’s certificate, the client checks it and tries to authenticate the server.

  • Checks the certificate’s validity period.
  • The client maintains a list of trusted Certificate Authorities (CA) certificates (the root certificate for the key that was used to sign the server’s certificate) that determines which server certificates the client will accept. To verify the certificate the client checks if the issuing CA is in the list of trusted CAs. More specifically, does the distinguished name (DN) of the issuing CA match the DN of a CA on the client’s list of trusted CAs?
  • From its list of trusted CAs, the client compares the public key from the CA’s certificate to the one being presented in the server’s certificate.
  • Check if the domain name in the certificate match the domain name of the server itself.

If all the above cuestions are succesfully resolved the server is authenticated and the client proceeds with the SSL handshake.

Once all is okay, the client creates and sends a premaster key (which is used as the basis of the session key) encrypted with the server’s public key.

If the Apache webserver is configured to request client authentication (optional in the handshake), the client sends the server both a certificate and a separate piece of signed data to authenticate itself. Now Apache will try to authenticate client’s identity:

  • Apache checks if the client’s digital signature could be validated with the public key in the certificate.
  • Checks the certificate’s validity period.
  • As in the client side, Apache maintains a list of trusted Certificate Authorities (CA) certificates that determines which client certificates the server will accept. To verify the certificate, Apache checks if the issuing CA is in the list of trusted CAs.
  • Is the client authorized to access this resource?

If all the above cuestions are succesfully resolved the client is authenticated and allowed to continue.

At this point Apache decrypts the premaster key with its private key and generates a master key which is sent to the client. Both the client and the server use the master key to generate the session keys. The interesting point here is having both the client and the server agree on a session key without ever sending it as plaintext over the network (this depends on the cipher suite selected). Now both ends inform each other that future messages will be encrypted with the session key and that the handshake is finished. This is the end of the SSL handshake and the start of the SSL session.

Configuring Apache to support SSL/TLS

Now I will show you how to configure your Apache webserver with SSL support. I assume you have Apache correctly configured and compiled with SSL support. If not, please take a look at References below.

Edit your httpd.conf and add the following if necessary or modify it accordingly to your needs:

…..
LoadModule ssl_module extramodules/libssl.so
…..

AddModule mod_ssl.c
…..
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
…..
…..
Listen 443
SSLPassPhraseDialog builtin
SSLSessionCache dbm:/var/log/httpd/ssl_scache
SSLSessionCacheTimeout 300

SSLMutex sem
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

SSLLog /var/log/httpd/ssl_engine.log
SSLLogLevel error

##
## SSL Virtual Host Context
##

<VirtualHost 192.168.100.1:80>

DocumentRoot /var/www
ServerAdmin karkoma@karkomaonline.com
ServerName www.karkomaonline.com
ErrorLog /var/log/httpd/error.log
CustomLog /var/log/httpd/access.log common

<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 192.168.100.
</Location>
…..

SSLEngine on
SSLProtocol SSLv3

SSLCipherSuite HIGH:MEDIUM

SSLCertificateFile /path/to/your/ssl/www.karkomaonline.com.crt
SSLCertificateKeyFile /path/to/your/ssl/www.karkomaonline.com.key
SSLCACertificateFile /path/to/your/ssl/karkomaCA/karkomaCA.crt
SSLVerifyClient require
SSLVerifyDepth 1
…..

</VirtualHost>

Generating your own certificate infrastructure

Depending on you needs you must pay a fee to Certificate Authority such as Thawte or VeriSign to get your site widely recognized as a secure site by an international CA. Or you can become a CA and create your own client and/or server certificates, sign and distribute them for your intranet for example or other needs.

Let’s start by creating our CA key and certificate:

openssl genrsa -rand /var/log/messages -out karkomaCA.key 1024
openssl req -new -x509 -key karkomaCA.key -out karkomaCA.crt

Okay, we have our private key and the corresponding certificate which will be used to sign the Certificate Signing Requests (CSR) requested by our clients. Note that in the above httpd.conf sample file SSLCACertificateFile directive points to this cert, this is the root certificate for the client certificates you’ll sign karkomaCA.crt. You could also add other CA’s root certificate if you plan to use them.

Now we are going to create a key and a Certificate Signing Request for the Apache webserver and sign it with our CA certificate; karkomaCA.

openssl genrsa -rand /var/log/messages -out www.karkomaonline.com.key 1024
openssl req -new -key www.karkomaonline.com.key -out www.karkomaonline.com.csr

openssl x509 -req -days 365 -in www.karkomaonline.com.csr -CA karkomaCA.crt -CAkey karkomaCA.key -CAcreateserial -out www.karkomaonline.com.crt

Finally create a CSR from your client and sign it with your CA cert:

openssl genrsa -rand /var/log/messages -out client.key 1024
openssl req -new -key client.key -out client.csr

openssl x509 -req -days 365 -in client.csr -CA karkomaCA.crt -CAkey karkomaCA.key -CAcreateserial -out client.crt

Now you are able to handle your sensitive information from your servers and clients in a more accurate form. You can implement this in your organization’s intranet as a means of handling private documents, test your internal developments based on SSL, etc. Please, see the References below to get an indepth knowledge of the SSL technology.

That’s all for now. Your comments are very welcome!

References

  • The OpenSSL project homepage
  • This is the Apache module that enables the webserver to communicate through Secure Sockets Layer
  • RFC 2246 specifies Version 1.0 of the Transport Layer Security (TLS) protocol and here SSLv3 specification.
  • RFC 2818 specifies HTTP over TLS

2 Responses to “Apache and SSL”

  1. morpheo says:

    Very interesting article indeed. Let me enlighten one point (quotation from webdav howto).

    Anything encrypted with Private Key can only be decrypted by using the Public Key. Similarly anything encrypted using the Public Key can only be decrypted using the Private Key. There is a common mis-conception that only the Public Key is used for encryption and Private Key is used for decryption. This is not case. Any key can be used for encryption/decryption. However if one key is used for encryption then the other key must be used for decryption. e.g. A message can not encrypted and then decrypted using only the Public Key.

    Using Private Key to encrypt and a Public Key to decrypt ensures the integrity of the sender (owner of the Private Key) to the recipients. Using Public Key to encrypt and a Private Key to decrypt ensures that only the inteded recipient (owner of the Private Key) will have access to the data.(i.e. only the person who holds the Private Key will be able to decipher the message).

    Symmetric Cryptography: Actual transmission of data: After the SSL connection has been established, Symmetric cryptography is used for encrypting data as it uses less CPU cycles. In symmetric cryptography the data can be encrypted and decrypted using the same key. The Key for symmetric cryptography is exchanged during the initiation process, using Public Key Cryptography.

    Message Digest: The server uses message digest algoritm such as HMAC, SHA-1, MD5 to verify the integrity of the transferred data.

    Great article!

  2. karkoma says:

    *.crt files mentioned in the article are PEM encoded. And are recognized by Apache. DER enconded certs are converted to PEM format issuing something like this:

    openssl x509 -inform DER -in cert.crt -outform PEM -out cert.der

Leave a Reply

You must be logged in to post a comment.