This is a small groowing blog post about obtaining an A+ rating with Apache 2.4.6 or higher on a freshly installed CentOS 7 with Let’s Encrypt certificates. Several blog posts claim getting an A+ rating on SSLLabs isn’t possible without HPKP (HTTP Public Key Pinning). This actually isn’t true. It’s perfectly possible to get an A+ rating by just enabling HSTS and OCSP Stapling, which are both easy to implement (compared to HPKP).
Contrary to what some blogs are posting, you also don’t need to use a 4096 bit key. This will definitely save you some resources, which is proved in this blog post from CertSimple:
4096 bit handshakes are indeed significantly slower in terms of CPU usage than 2048 bit handshakes.
HTTP Public key pinning (HPKP) is a security mechanism which only protects against a relatively rare MitM attack that’s very hard to pull off. Someone would have to impersonate you with a fraudulent certificate generated via a Certificate Authority that your browser already trusts.
But if misconfigured, it can really brick your website. And it is not supported by Internet Exploter and Edge as you can see here in the Microsoft Edge Platform Status. HPKP is alsonot recommend with Let’s Encrypt and has a lot of additional requirements. This is explained by Peter Eckersley from the EFF in this blog post.
These days, encryption is a necessary part of any self-respecting IT organization. If your traffic is unencrypted, you (or your visitors) are almost certainly being monitored by someone in some government somewhere on our little planet. If not by the so-called “Five Eyes” (Australia – Canada – New Zealand – United Kingdom – United States), then some other government organization owned by the Russians, the Chinese or an other less known security agency or hacker group might have you on their radar. Luckily since 3 December 2015 Let’s Encrypt entered public beta. (not that this means you are suddenly safe 😀 )
If you want information about cryptography laws in your country, please consult http://www.cryptolaw.org. It has a very detailed list of existing and proposed laws and regulations on cryptography for almost any country.
Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. Let’s Encrypt is a service provided by the Internet Security Research Group (ISRG). ISRG is a California public benefit corporation. Major sponsors are the Electronic Frontier Foundation (EFF), the Mozilla Foundation, Akamai and Cisco Systems. Other partners include the certificate authority IdenTrust, the University of Michigan, the Stanford Law School and the Linux Foundation. Not the smallest organizations aren’t they?
The key principles behind Let’s Encrypt are:
- Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.
- Automatic: Software running on a web server can interact with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal.
- Secure: Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.
- Transparent: All certificates issued or revoked will be publicly recorded and available for anyone to inspect.
- Open: The automatic issuance and renewal protocol will be published as an open standard that others can adopt.
- Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.
Do you need any more convincing? For years people have been paying far too much for their SSL certificates to security companies such as Comodo, GlobalSign, Godaddy, Thawte and others. I have never really understood why they cost so much. And why would we trust them? Remember DigiNotar?
DigiNotar was a Dutch certificate authority owned by VASCO Data Security International. On September 3, 2011, after it had become clear that a security breach had resulted in the fraudulent issuing of certificates, the Dutch government took over operational management of DigiNotar’s systems. That same month, the company was declared bankrupt. After more than 500 fake DigiNotar certificates were found, major web browser makers reacted by blacklisting all DigiNotar certificates. The scale of the incident was used by some organizations like ENISA andAccessNow.org to call for a deeper reform of HTTPS in order to remove the weakest link possibility that a single compromised CA can affect that many users.
An initiative such as Let’s Encrypt, carried and supported by a huge number of people and organizations is in my humble opinion a much safer option then trusting your certificates in the hand of ‘relatively small companies’. All those so called security companies claim to be secure, but in the meantime fail to deliver transparent and open protocols. Your security might be in compromised by just one overworked individual failing to do his job properly.
But what can other Certificate Authorities offer that Let’s Encrypt can’t?
There are three types of SSL certificates: Domain Validated (DV), Organization Validated (OV) and Extended Validation (EV). To get a DV cert you only need prove that you control the domain for which the certificate is assigned. For an OV cert the CA checks with third parties to ensure that the name of the applying organization is the same as that which owns the domain. For an EV cert, the kind that turn your browser address bar green, you need to provide much more extensive documentation, and there are no personal EV certs. The very fact that the Let’s Encrypt process is automated means that they will not be able to offer anything other than DV certificates. To many companies this isn’t enough. You should use Let’s Encrypt:
- If you are running your own web server
- If you have a registered publically accessible domain name
You should not use Let’s Encrypt with:
- Shared web hosting
- You want to keep the existence of your certificate a secret
- Wildcard certificates
- Long-lived certificates
- Extended Validation
- If you want your certificate to be trusted by older software
SSLLabs Rating Methodology
SSLLab’s approach for calculating the rating consists of four steps.
They look at the certificate to verify that it is valid and trusted. Server certificates are often the weakest point of an SSL server configuration. Certificates that aren’t trusted fail to prevent MITM attacks.
Any of the following certificate issues immediately result in a zero score:
- Domain name mismatch
- Certificate not yet valid
- Certificate expired
- Self-signed certificate
- Use of a certificate that is not trusted (unknown CA or some other validation error)
- Revoked certificate
- Insecure certificate signature (MD2 or MD5)
- Insecure key
So how are the Let’s Encrypt certificates doing? Let’s Encrypt’s intermediate is signed by ISRG Root X1. However, since they are a very new certificate authority, ISRG Root X1 is not yet trusted in most browsers. In order to be broadly trusted right away, their intermediate is also cross-signed by another certificate authority, IdenTrust, whose root is already trusted in all major browsers. Specifically, IdenTrust has cross-signed our intermediate using their DST Root CA X3.
They inspect the server configuration in three categories. The category scores are combined into an overall score expressed as a number between 0 and 100. A zero in any category will push the overall score to zero.
They then apply a series of rules to handle some aspects of server configuration that cannot be expressed via numerical scoring. Most rules will reduce the grade (to A-, B, C, D, E, or F) if they encounter an unwanted feature. Some rules will increase the grade (to A+), to reward exceptional configurations.
SSLLab will look at the protocols supported by an SSL server. For example, both SSL 2.0 and SSL 3.0 have known weaknesses. Because a server can support several protocols, they use the following algorithm to arrive to the final score:
- Start with the score of the best protocol
- Add the score of the worst protocol
- Divide the total by 2
Key exchange support
The key exchange phase serves two functions. The first phase is done with asymetric encryption. It performs authentication, allowing at least one party to verify the identity of the other party. The other is to ensure the safe generation and exchange of the secret keys that will be used during the remainder of the session. The weaknesses in the key exchange phase affect the session in two ways:
- Key exchange without authentication allows an active attacker to perform a MITM attack, gaining access to the complete communication channel.
- Most servers also rely on public cryptography for the key exchange. Thus. the stronger the server’s private key, the more difficult it is to break the key exchange phase.
|Key exchange aspect ||Score
|Weak key (Debian OpenSSL flaw) ||0%
|Anonymous key exchange (no authentication) ||0%
|Key or DH parameter strength < 512 bits ||20%
|Exportable key exchange (limited to 512 bits) ||40%
|Key or DH parameter strength < 1024 bits (e.g., 512)||40%
|Key or DH parameter strength < 2048 bits (e.g., 1024)||80%
|Key or DH parameter strength < 4096 bits (e.g., 2048) 9||90%
|Key or DH parameter strength >= 4096 bits (e.g., 4096)||100%
To break a communication session, an attacker can attempt to break the symmetric cipher used for the bulk of the communication. A stronger cipher allows for stronger encryption and thus increases the effort needed to break it. Because a server can support 7 ciphers of varying strengths, SSLLab penalizes the use of weak ciphers.
|Cipher strength ||Score
|0 bits (no encryption) ||0%
|< 128 bits (e.g., 40, 56) ||20%
|< 256 bits (e.g., 128, 168) ||80%
|>= 256 bits (e.g., 256) ||100%
You can find the SSL server rating guide here.
Requirements for getting an A+ rating on SSLLabs
Use any of this code at your own risk. Do no use it on a production webserver. Do not use it if you don’t know what you are doing.
Please replace any variables such as $Hostname and $Email with values.
Create SSL Configuration
Listen 443 https
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect builtin
SSLProtocol -ALL -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
I’m assuming you have ran CertBot to generate your Let’s Encrypt certificates. If not, start with installing the python-certbot-apache yum package:
yum install python-certbot-apache -y
certbot certonly --webroot -w /var/www/$Hostname/public_html --email $Email -d $Hostname --agree-tos -vvv
Make sure httpd and mod_ssl yum packages are installed on the server.
yum install httpd mod_ssl -y
You can check your Apache version like this:
Server version: Apache/2.4.6 (CentOS)
Server built: Jul 18 2016 15:30:14
Enable the httpd service:
systemctl enable httpd.service
Create the webroot:
mkdir -p /var/www/$Hostname/public_html
Set webroot owner:
chown -R $User1:$User1 /var/www/$Hostname/public_html
Furthermore set the webroot permissions:
Create demo page:
cat > /var/www/$Hostname/public_html/index.html <<EOF
<title>Welcome to $Hostname</title>
<h1>Success! The $Hostname virtual host is working!</h1>
Create vhost directory /etc/httpd/sites-available
Equally create vhost directory /etc/httpd/sites-enabled
Add sites-enabled/*.conf to httpd.conf:
echo "IncludeOptional sites-enabled/*.conf" >> /etc/httpd/conf/httpd.conf
Create Apache vhost:
cat > /etc/httpd/sites-available/$Hostname.conf <<EOF
Redirect / https://$Hostname
CustomLog /var/log/access_http.log combined
DirectoryIndex index.html index.php
CustomLog /var/log/httpd/access_https.log combined
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header always set X-Frame-Options SAMEORIGIN
Link Apache vhost:
ln -s /etc/httpd/sites-available/$Hostname.conf /etc/httpd/sites-enabled/$Hostname.conf
In addition add the firewalld https service:
firewall-cmd --zone=public --permanent --add-service=https
Finally restart firewalld:
systemctl restart firewalld
First of all, let me know if I forgot something. As much as I tried to make the article as accurate as possible, I might have made a mistake. Qualys is also continuously improving their tests and rating methods. As a result some parts of this article might no longer be valid.
Furthermore, please note that an A+ rating is probably not ideally for every web application. It’s not because you have received and A- or A rating that your web application is suddenly vulnerable for any malicious attack. Different websites have different needs, which means that there is not a ‘perfect’ configuration that works for everyone.
I would like to suggest this GitHub project from SSLLabs which contains some very useful recommendations about SSL and TLS deployments.
Please let me know if I something I wrote is incorrect.