I noticed that I forgot to set the key-strength from 2048 to 4096, so I want to creat new keys for my website. What’s the best way to do it without to get into trouble?
As far as I know, you should be able to generate a new certificate for the same domain name (as long as you stay under quota per week). Just request it with the correct key pair.
1 Like
What exactly do you mean with “correct key pair”? I need the current privkey.pem and the fullchain.pem to request a new for my domain? Any example request-string?
Correct - meaning 4096 bit 
If can’t find a cli.ini anywhere to change the settings to 4096 bit.
Locations I checked:
/etc/letsencrypt/cli.ini
$XDG_CONFIG_HOME/letsencrypt/cli.ini
~/.config/letsencrypt/cli.ini
I also used whereis but no result.
EDIT: Oh, might it be, that there isn’t one and I have to create one.
There’s no point in using a 4096 bit key as long as the intermediate certificate is “only” 2048.
3 Likes
Yes, that’s what I recognized too, after creating my new 4096 key.
I would be interested in getting 100 points on https://www.ssllabs.com/ssltest for “key exchange” and "cipher strength. Just for fun. Not because it matters. I am already A+ since supporting HSTS. I already read their Server Rating Guide, but I don’t know if I have influence on cipher strength NOR key exchange. I guess it’s all up to LE. My results for cipher strength e.g.:
Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites at the end)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 4096 bits FS 128
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 4096 bits FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 4096 bits FS 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 4096 bits FS 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 4096 bits FS 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 4096 bits FS 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88) DH 4096 bits FS 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 4096 bits FS 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
1 Like
LE doesn’t have anything to do with the cipher or key exchange, that’s configurable on your server. The most it influences things is enforcing SHA2 signing on the certificate.
For webserver configuration, I will point you to the Mozilla SSL Configuration Generator. Set the right version numbers of your software and choose “modern” to get a pretty restrictive setup. You may still have to do a bit of adjustment to get a full 100%, but that should take you most of the way.
Be warned that a lot of stuff will fail to connect with such a setup, so it’s not advised for a realistic public-access site. If you have full control over both ends of the connection, then do as you see fit.
3 Likes
Offtopic
For 100 % on cipher strength, you’ll need to enable only 256 bits ciphers… So indeed, ditch 128 bits AES-GCM… That’s not a good setting for production servers, as the GCM mode of operation (actually, an AEAD) is way more secure than the CBC mode of operation… And some browsers, such as Chrome, don’t support 256 bits AES-GCM for “performance reasons”… 
For 100 % key exchange, you’ll need to add secp384r1 and/or secp521r1 to the accepted ECDHE parameters of Apache… (Now, it only exchanges keys with 256 bits of ECDH, which is equivalent with 128 bits of symmetric cipher strength.) In my setup (Apache 2.4.18), this was good enough:
SSLOpenSSLConfCmd ECDHParameters Automatic
SSLOpenSSLConfCmd Curves secp521r1:secp384r1:prime256v1
I don’t know the influence of those RSA key exchange ciphers in your list, so YMMV…
1 Like
@punkrock Apart from from the certificates (which are great as is tbh), I recommend to harden your HTTP response headers. There is more than HSTS -> X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Content-Security-Policy and Public-Key-Pinning. Scan your site here and fix it: https://securityheaders.io/
3 Likes
@effg: Yes, I don’t will change anymore to get 100 on SSLlabs. It’s all fine as it is. Thanks for the infos about hardening my HTTP-headers. I set all headers except for HPKP. I am not really sure, if I want this, because till now I don’t understand it. Am I right with:
I create one more complete certificate (cert.pem, chain.pem, fullchain.pem, privkey.pem) with LE and get the Base64-string from the current used cert.pem and from the new cert.pem and put both into this command?
Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"
Is this correct? Or am I missing something?
The problem with doing it that way is that the official client creates a new key on every renewal so it’ll break your site. Your options are to use a different client that reuses the same key or to pin the intermediates so that any cert from LE is accepted (along with a backup leaf). Also it’s best to test it in report only mode until you’re sure renewals work.
For example mine is:
Header always set Public-Key-Pins "pin-sha256=\"YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=\"; pin-sha256=\"sRHdihwgkaib1P1gxX8HFszlD+7/gTfNvuAybgLPNis=\"; pin-sha256=\"9QMO6c7nQA5db5/N4YNrny+WyoVaYuOXn4OaAtpMcuY=\"; max-age=7776000; includeSubDomains; report-uri=\"https://report-uri.io/report/cool110\""
The 1st 2 are Let’s Encrypt Authority X1 and Let’s Encrypt Authority X2. The 3rd is a cert I generated manually and isn’t stored on my server, for use in case I need to change to a different CA.
So you can copy that and change the 3rd pin to your backup cert, the report-uri to whichever service you use and change “Public-Key-Pins” to “Public-Key-Pins-Report-Only” until you’re completely sure it’s right.
1 Like
There can be if you use a pinning mechanism, which can limit the avenues of attack available to an attacker again a user whose client is aware of the pin.
1 Like
I know this thread turned toward other topics, but if people are interested in generating 4096-bit keys, you can cause it to happen by supplying the option --rsa-key-size 4096 when running the client (in addition to configuration file methods). In the forthcoming client release, preferences specified this way will be saved and become defaults for that particular certificate if renewing with letsencrypt renew (it’s not obvious to me whether or not it would also affect renewal with letsencrypt certonly).
(edit: correct form is --rsa-key-size, I left out one of the dashes)
3 Likes
As for HPKP please have a look in this forum a bit. E.g. here you can find one topic with many links:
1 Like