HOWTO: A+ with all 100%'s on SSL Labs test using apache2.4 (READ WARNINGS)


This is great commentary and I have learned a lot from the comments, but I feel I should remove this post as it’s dangerous and misleading at this point.


No. I think it is very insightful. Please leave it up.

Personally I think that any client that does not support encryption require to get an A+ grade is broken, out of date, and deserves to be locked out, blocked, left out in the cold, etc. Keep up to date or get left behind I say.


You don’t need a restrictive setup to get an A+, see


Right, but when you go for 100’s it gets very restrictive. The basic apache setup gets you an A+ iirc.


Basic setup with Mozilla Intermediate and HSTS, yes.


I’m curious about the 4096-bit RSA key and Diffie-Hellman parameters. In most current keylength recommendations those would be considered disproportionate to the security levels of other parts of the system. Would the SSL Labs site give an A+ for a 2048-bit RSA key and 2048-bit DH parameters? Do you have to go all the way to 4096 and 4096 for the A+?

I believe @kelunik’s setup is showing an A+ right now with 2048 and 2048.


Yes, 2048 and 2048 is enough for an A+.


[quote=“kelunik, post:17, topic:2436, full:true”]
Yes, 2048 and 2048 is enough for an A+.
[/quote] Yup it is, provided optimal cipher preferences the difference between A and A+ is usually whether HSTS is enabled or not


I also enabled mod_spdy losely following and CHACHA20-POLY1305 with… getting a little nuts over here.



after your comments of hpkp report i change the handling.
Now if gets logged and return an
405 “Method not Allowed” for anything other than POST
201 “Created” if there was an POST call.


or check out


@eva2000 nice page but since HPKP violations are not common. I would like to see two more topic on this page.

  1. An Test how some Page behave if they receive an HPKP report.
  2. An Tutorial how someone can test that his browser reports error for his domain.


Depends on the timezone, but you may be right. :smile:

And allow the attacker to intercept or modify all this data so you do not get any or a completely faked HPKP report. I think that’s not what you want.
That’s why you should use HTTPS and HPKP there too - obviously. Because if the client fails sending the report it should try it later again (if it’s following the specification).
Like already said by @eva2000 is a nice easy service for collecting such reports.


The issue is just that the connection will fail if your browser claims to support a TLS version (1.3) which it actually does not support… :neutral_face:
So if TLS 1.3 is supported by your browser you should obviously enable support for it.

Yes, you’re right. Maybe I did not looked carefully enough. :wink:


Here is a demonstration of this:

You can also test it yourself e.g. by using infamous AV SSL interception software. As most browser have an exception of HPKP to allow this kind of interception you mostly have to adjust the settings to be able to test it like this. In Firefox this can be done by changing security.cert_pinning.enforcement_level in about:config.
(And for you here is a German guide how to do this:


Hi, even if i came from germany i have no problem in reading English documentation.
The first link was what i was looking for. The point about hpkp reporting url i do not agree.
You are right that the browser does an retry. But lets think about an simple case. You are
in an hotel or company and they implement an bad proxy that mess with ssl. Than you
have no chance receiving the report via https. But there would be no block at http level.


Did I claimed something else?

The German guide is also a bit more comprehensive - that’s why I linked it mainly.

In this case you’ve already lost if you use their devices, because obviously they could have added many root certificates or modified other things, where TLS cannot protect you.
A much better situation is if you use your own device in their WLAN: If a connection fails, because they intercept it the HPKP report may be triggered and sent. If this does not succeed the Browser can still try it again - at some point you maybe use another Wi-Fi network.


Hi, i setup an test domain with invalid pin’s. In the firefox console log i get the warning “Public-Key-Pins: The site specified a header that did not include a matching pin.” But the lock stay green and there is no report submited.
Not the action i expected at all. (In have the Self Created CA in my Truststore).

security.cert_pinning.process_headers_from_non_builtin_roots = true
security.cert_pinning.enforcement_level = 2


Obviously this is out of scope of this thread and not related to Let’s Encrypt, but just a short answer:
In the sites I linked to you can see how it should work. You can also test it here: although this is only about preloaded pins and only works in the current Chrome/Chromium versions.
So to get back to your case: Maybe you loaded a site which loaded other assets from a domain with HPKP which are blocked as it is shown in the console.
The connection to currently fails. (timeout error, so not cause by HTTPS/HPKP)


I made an easy way to get the DH Parameter patched certificate updated. Put a small shell script on