I don’t know enough about SSL to know what’s going on but I have a suspicion:
I installed the SSL cert for Apache a while back and just now moved to Nginx for it’s http/2 support. As the nginx plugin is not stable yet I had to install the cert myself and this is what I did:
In my nginx config (/etc/nginx/conf/default.conf) I added:
With HSTS you should usually get an A+. You can add add_header Strict-Transport-Security max-age=15768000 always; if your Nginx version allows for always.
HTTP/2 implies TLS in practice, because all browser vendors decided to implement it only with TLS.
I wonder if skipping ssl means that only clients supporting HTTP/2 can use TLS, though. Would be surprising if SSL Labs doesn’t catch that. Might be a good idea for @dominikwilkowski to try the site with a client without HTTP/2 support, just in case.
Excellent question!
I had lots of questions like yours, i.e. HTTP/2 with NGINX frequently, so I decided to write a post about it:
The Diffie-Hellman with 1024 and 2048 is considered weak, because using massive precomputation (with clouds like AWS, Azure and Google Cloud) that’s no longer state of the art.
Besides you should also stay away from SSL v2, SSL v3 and TLS 1.0. Secure as of today are only TLS v1.1 and v.1.2!
So in the NGINX conf it looks like this:
ssl_protocols TLSv1.1 TLSv1.2;
How to Activate HTTP/2 with TLS Encryption in NGINX for Secure Connections without a Performance Penalty
Wow, congratulations, you got on top of it in no time:-)
& bg sends the task to the background (longer keys tend to take some measurable time, so should the remote connection be interrupted, your remote machine will still get to complete the Diffie-Hellman group even though your shell is no longer active).
You may also want to deactivate TLS 1.0, as it is vulnerable to downgrading attacks. Adding security headers and pinning the certificates can also enhance security. Here is more on that:
Glad you liked the other article:-) Hopefully this one will also be of help. Should you have any questions, please feel free to shoot a comment!
We also implemented HTTP Public Key Pinning (HPKP) as you can see in the attached screenshot and described in:
"Pin your public keys
The Public Key Pinning Extension for HTTP (HPKP) tells a web client to associate a specific cryptographic public key with a certain web server so as to prevent MITM (man-in-the-middle) attacks with forged certificates.(…)"
I did but I still have issues with the header. I think @CloudInsidr is right, we need to take this into a NGINX forum rather than here as it has nothing to do with letsencrypt.
Thanks guys for the help.
I’ll post a follow up once I get it all sorted to close this off here.