SSL/TLS server configuration for maximum security

I've been playing around a lot with SSL/TLS server settings. I'll explain what settings I used for this https connection and how they improve your security.

This site passes the Qualys SSL Server Test with an A. (It does not get an A+ due to a bug in the Qualys test, it appears several sub-tests are disabled in a TLS 1.3 only configuration.) When I started this page, most browsers were unable to access it, but nowadays luckily most browsers support TLS 1.3. This page is accessible with https and many fancy TLS settings through and with less strict TLS settings through

TLS 1.3 only

What? Only connections through 1.3 are allowed.

Why? TLS 1.3 deprecates a lot of problematic algorithms and features, and therefore prevents many famous attacks on TLS by design.

Browser support: Usually available these days.

Server support: Can be enabled in current apache with the SSLProtocol directive:

SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 +TLSv1.3

Server Name Indication (SNI)

Not exactly a security feature, but an option to have more than one certificate on one IP. Usually, today's webservers run dozents of virtual hosts on one IP. This made SSL implementation difficult in the past, as traditional SSL requires one IP per certificate and the domain name is fixed in the certificate. The Server Name Indication, available since TLS 1.0, allows to circumvent this restriction (although there were some problems with browsers due to backwards compatibility, see this Mozilla bug).

Server support: Using Apache 2.2.12 or above you can specify a certificate in every vhost with SSLCertificateFile, SSLCertificateKeyFile and, if neccessary, SSLCertificateChainFile.

Certificate from Let's Encrypt with 2048 bit and SHA256 signature

Certificate is signed by Let's Encrypt.

It has a 2048 bit RSA key and a signature with SHA256. (Originally I had a 4096 bit certificate, but it is too much hassle to support this with our certificate automation and 2048 is more than enough.)

RSA keys with 1024 bit are considered insecure against very powerful attackers, keys with 768 bit have been broken in practice and keys with 512 bit can be broken on home hardware. Google, PayPal, Amazon, Yahoo, eBay, Apple, Twitter and a bunch of others still used 512 bit keys in 2012 (for DKIM, not for https). In 2010, the EFF found 512 bit RSA certificates on https with so-called "Extended Validation" (EV), which is forbidden by the EV rules.

Keys with 2048 bit or above are considered secure.

Also, we've correctly installed the certificate chain. This should be obvious, but it is not. Very often, wrongly installed chains can remain undetected for a long time, because browsers are lax when the chain is in wrong order and if it's completely missing, the browser will take intermediate certificates it has cached from other sites.

OCSP stapling

A hughe problems with certificates are revocations. The CRL or OCSP protocols should allow browsers to check certificate authorities if certificates are still valid. However, browsers either disable OCSP or implement it in an insecure way treating "no reply" as "everything's fine". Also, OCSP has privacy issues, because the certificate authority will get all the IPs from users checking their certs. So it's basically broken and useless, but that's the way things are.

With OCSP stapling, the server caches the certificate authorities OCSP reply and bundles it into the SSL connection. This improves performance and privacy when using OCSP.

HTTP Strict Transport Security (HSTS)

We send the HTTP Strict Transport Security header, which tells the browser to access this page only with SSL for a certain timeframe and thus makes SSL stripping attacks less likely. The timeout is set to two years.

The domain is also in the HSTS preload list.

Secure Renegotiation

In 2009, a flaw was found in the SSL/TLS renegotiation feature. A TLS-extension specified in RFC 5746 allows renegotiation without the flaw.

TLS 1.3 has replaced renegotiation with a different rekeying mechanism.

No insecure Diffie Helmann parameters

Apache used fixed parameters for Diffie-Hellman key exchanges with 1024 bit for a while. That's considered insecure, however there's no way in Apache before version 2.4.7 to change this except disabling DH exchanges at all. Apache 2.4.7 and above set the DH size to the certificate key size.

For TLS 1.3, only standardized DH groups are allowed, so this issue is obsolete.

CAA (Certificate Authority Authorization)

The domain uses Certificate Authority Authorization (CAA, RFC 6844) to bind certificate issuance to one certificate authority.

It also uses the Account URI and Method Binding Excensions (RFC 8657) to further lock down certificate issuance.

HPKP (HTTP Public Key Pinning)

HPKP allows a web page to "pin" a set of keys that a client can store and prevent connections with any other key. While in theory this provides strong protection against powerful attackers, it can break pages without a recovery option if a server administrator looses access to his keys.

HPKP has been removed from most browsers. We still send an HPKP header and pin to Let's Encrypt's root and intermediate certificates, including fallbacks.

Certificate Transparency

All certificates used are logged in Certificate Transparency logs. This is the default these days and required by browsers.


The Expect-CT header allows to signal to a client that it should only accept certificates with Certificate Transparency support.

This is no longer needed, as Certificate Transparency is required by default by modern browsers. We still send an Expect-CT header.

Content Security Policy

Content Security Policy is not directly related to TLS/HTTPS, but it contains one sub-feature that is relevant: The upgrade-insecure-requests flag prevents mixed content and auto-upgrades images and other resources to https if one tries to load them over http.

Subresource Integrity

Subresource Integrity (SRI) allows setting a hash to guarantee the integrity of CSS and Javascript resources. This is primarily useful for third-party resources. This page uses no third-party resources, but we still use SRI for the CSS file.


We set a cookie with the secure flag and the __Secure- prefix.

The cookie has no further purpose and is only servers as an example. It expires after a few minutes and contains no personal data.


What could be implemented to further improve security:

Who, what?

This test site was setup by Hanno Böck. You may also want to check out badkeys, an open source tool to detect and break known vulnerable cryptographic keys.

All content may be considered CC0 / Public Domain. The icon is from SVG Repo, also CC0.