In order to get 100% in the Key Exchange bar on my server running Apache 2.4.7 and OpenSSL 1.0.1f, I had to also specify a curve with a 384-bit field strength, as the default curve secp256r1 has less equivalent strength than 4096bit RSA.
To see what 384 bit curves you support, run openssl ecparam -list_curves | grep 384; you’ll probably see secp384r1. In which case you can get the output of openssl ecparam -name secp384r1 and put it in your leaf cert’s pubic file between the cert and the dhparams (I’m not 100% sure you have to put it between, or if it could also work after the dhparams). Alternatively, you can put the output of that command in its own file and specify it in your Apache config with SSLOpenSSLConfCmd ECDHParameters; similar to SSLOpenSSLConfCmd DHParameters, I believe it only works with Apache 2.4.8 or later with Openssl 1.0.2 or later.
Nope the challenge was extra with the hint without tricks. Because it should show the users that it is not possible
to always reach different goals at the same time.
SSL-Labs does an handshake simulation that i can match via fingerprinting to one individual browser.
On the the side the pci test scan for ciphersuites like the rating part of ssla labs does and look at the found
cipher suites. So ist may not even possible (except ip based) to reach both 100% marks.
-> My trick is neither IP based nor test specific like saying the n’th connection from this server get other config.
well I just thought that a server must connect (i.e. send a clienthello) to see what you can do) and with that I thought you could serve specific to the tests
The server does an whole series of connection more than 50 to see all supported suited.
And ssllabs also do connections that are identical to existing browsers.
I still don’t understand why the first post is still that incorrect. E.g. I pinning the private key is completely brainless although I hope it is note a security risk, but I can’t say it is no one.
So again, if someone did not understand it until now: Do not follow this guide!
The code of the first post pin the public key (extracted from the private key). But the consequence of pinning the public key is that the private key is pinned too because they are linked : only the person having the private key can generate valid certificate for that pin. But yes, the wording of the post is confusing
Pinning the hash of a private key is useless anyway, because the client can only verify public keys by definition… Unless your webserver is doing very, very stupid things
EDIT
In addition, using 4096 RSA keys and DHParams are great. But the longer the key, the more resources are needed to handle it causing performance issues. Might not be noticeable in smaller implementations. That’s why the industry standard is 2048 since its already “enough” according to SSL Labs Best Practice . And that’s why we all can’t wait for letsencrypt to get ECC out!
