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 300SSLMutex sem
SSLRandomSeed startup builtin
SSLRandomSeed connect builtinSSLLog /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 SSLv3SSLCipherSuite 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.csropenssl 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.csropenssl 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
Very interesting article indeed. Let me enlighten one point (quotation from webdav howto).
…
…
Great article!
*.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: