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).
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:
SSLProtocol -All +TLSv1.3
Header always set X-Content-Type-Options nosniff
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
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:
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.
Check other blog postsSee all blog posts
- Read more
Multiple websites on one server is a threat that can have different faces. Find out what the most important ones are and see why you should split your sites on different hosting accounts. Powiązane wpisy: Compendium: how to secure your WordPress? Everything you have to keep in mind when creating an online store Useful plugins…
- Read more
Too much website traffic can be as disastrous as no traffic at all. A traffic disaster results in server overload. In such a situation, no one is able to use e.g. your online store’s offer, and you do not earn. Learn how to optimally prepare your website for increased traffic. Powiązane wpisy: Compendium: how to…
- Read more
Do you have a bank account? Use the internet with your smartphone? Congratulations! Then you are on the brighter side of the power, where digital exclusion does not reach. But can you take care of the security of your data as effectively as you invite your friend for a beer via instant messenger? Powiązane wpisy:…