Secure SSL configuration on Apache server

Generation of certificates

SSL certificates for over 20 years have been the basic component of a properly configured website hosting service. A critical parameter determining the strength of SSL encryption is the length of the keys used. The longer it is, the more difficult it is to decrypt the transmission between two computers without a dedicated key. Currently recommended asymmetric key length is 2048 bits. SSL certificates purchased from us meet these requirements.

Generation of a certificate from an external vendor

A command can be used to (correctly) generate requests for a certificate (CSR – Certificate Sign Request) compliant with the applicable standards:

openssl req -sha256 -new -nodes -newkey rsa:2048 -out /etc/pki/tls/certs/www.example.com.csr -keyout /etc/pki/tls/private/www.example.com.key

It generates two files – a private key file (used to decrypt messages) and a CSR file from which we can generate a public key file (used to encrypt messages). CSR enables us to generate a public key from external providers such as Comodo, RapidSSL, Go Daddy, etc. If we are not a CA (Certificate Authority), it is the only way to be able to have a “trusted certificate”, i.e. one that is recognized by the user’s browser and does not display an HTTPS warning (connection not trusted).

The above openssl tool will create a 2048 bit RSA key (-newkey rsa:2048) unencrypted (-nodes) and a request for a certificate, in PKCS#10 format, with the indication that we want to use an SHA algorithm with a 256-bit key to sign the certificate.

The -sha256 option is particularly important because many certification authorities do not yet have the default setting to sign certificates using SHA-2 – instead, a weaker SHA-1 algorithm is used, which is currently treated as obsolete (and will soon display a warning in browsers). The -sha256 option allows us to indicate that we want to use specifically this version of the SHA algorithm to sign our certificate.

Generation of self-signed certificate

To generate a self signed certificate, use the command:

openssl req -sha256 -new -x509 -nodes -days 3650 -newkey rsa:2048 -out /etc/pki/tls/certs/www.example.com.crt -keyout /etc/pki/tls/private/www.example.com.key

As in the example above, we create two files, but this time instead of CSR we create a CRT file in which we have our certificate (-x509), signed by ourselves. This allows us to bypass the verification process and signing the certificate with an external provider (which is usually paid) but, on the other hand, client browsers will not display the connection as trusted (broken HTTPS padlock).

SSL Settings

In order to further increase the security of our HTTPS server, in addition to the relevant certificates, we can also change the settings of the allowed list of cryptographic ciphers that are used during the exchange of information. The configuration is shown on the example of Apache 2.2 and CentOS operating system.

In order to disable support for old and weak algorithms/methods of encryption, the file /etc/httpd/conf.d/ssl.conf should be added/replaced:

SSLEngine on
SSLProtocol -All +TLSv1.3
SSLUseStapling off
SSLStaplingFakeTryLater off
SSLStaplingReturnResponderErrors off
SSLStaplingResponderTimeout 3
SSLCompression off
SSLSessionTickets off
Header always set X-Content-Type-Options nosniff
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256

The above list of SSLCipherSuite and SSLProtocol comes from wiki.mozilla.org and contains the average (intermediate) security settings. They are the most compatible but still safest, as they disable RC4 algorithm (which has verified, unrepairable vulnerabilities) and SSLv3 (POODLE attack). The exception in terms of compatibility is Internet Explorer 6.0 under Windows XP and Java 1.6. For the latter platform you can still restore support, creating a rigidly generated Diffi-Hellman protocol parameters and add at the end of the main domain certificate:

openssl dhparam -out /tmp/dh.crt 1024
cat /tmp/dh.crt >> /etc/pki/tls/certs/www.example.com.crt

For a more detailed description of the solution to Java 1.6 please visit httpd.apache.org/docs.

It should also be noted that the above setting does not eliminate the BEAST attack vector using TLSv1.2, which, for compatibility reasons, we recommend to leave on, as it is the highest available algorithm in many older programs, e.g. Internet Explorer to ver. 10, Firefox to ver. 26 or Chrome to ver. 21.

Strict Transport Security

If possible, add to the same file (ssl.conf) as well:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

This should be done only if the application supports 100% HTTPS, i.e. it does not try to connect via pure HTTP, e.g. to API or auxiliary servers or subdomains, e.g. CDNs (in this case you can remove the "includeSubDomains" fragment).

Strict-Transport-Security briefly informs the browser that has received such a header together with reading, for example, the home page of the portal, that the user should remain on an encrypted connection at all times. It protects the user in a situation when someone tries to redirect the user from the website where he is (using HTTPS) to HTTP (using a Man-in-the-middle attack) and in this way tries to read the encrypted transmission.

SSL compression and CRIME attack

It is a good idea to add to /etc/sysconfig/httpd as well:

export OPENSSL_NO_DEFAULT_ZLIB=1

This disables compression of encrypted data on the fly, which protects against CRIME attack (in Apache 2.4.3+ this setting can be changed directly in config - SSLCompression variable).

SSL settings generator

If you want to easily prepare a secure configuration for Apache, Nginx or HAProxy servers, you can use a dedicated tool. Mozilla SSL Configuration Generator allows you to customize the configuration, taking into account the version of our webserver and the version of openssl library used. We are sure that we use the safest possible settings, matching our environment.

Verification of SSL settings

To check the security level of our HTTPS server, you can use one of the many tools available on the network. For example, an application from Globalsign allows you to test the configuration for many known attacks on the SSL protocol (and not only). It also allows us to check the compatibility of our settings on many different platforms.

Mandatory verification of CAA records

From 8 September 2017 all Certification Authorities are obliged to verify entries in DNS CAA records for the domain for which they want to issue a certificate. In practice, this means that domain owners have the ability to clearly identify which companies can issue a certificate for the domain. The purpose of this is to protect themselves against false certificates. For example, an entry in a domain:

thecamels.org.		128	IN	CAA	0 issue "rapidssl.com"

specifies that only RapidSSL has the right to issue a certificate for this domain. Detailed information on the introduced changes is available on the official websites of individual exhibitors.