My site " pi.carstens.in " is working without problems in Safari and IE (Certificat will be automatically accepted). In the actual Firefox Version comes the message " Dieser Verbindung wird nicht vertraut ". Is there a reason for this behavior?
(apache 2.4.x, debian)
Thanks for your help
Hi,
Connecting to pi.carstens.in works flawlessly from here (Firefox 44).
It should work on older browsers too, given that the Digital Signature Trust signed Let’s Encrypt’s CA certificate with their own.
Could you recheck and provide the exact error message, including the certificate chain causing the error?
I expanded my apache config:
Before (not working in Firefox):
SSLCertificateFile /etc/letsencrypt/live/exampl.es/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/exampl.es/privkey.pem
Now (working with all browsers):
SSLCertificateFile /etc/letsencrypt/live/exampl.es/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/exampl.es/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/exampl.es/chain.pem
Thanks
Hi @sven45,
you should take a look at your other server settings related to SSL/TLS, they are not okay.
https://www.ssllabs.com/ssltest/analyze.html?d=pi.carstens.in
Hi @sven45,
seems you improved your score a little but you’re still missing some items:
• server-enforced cipher order
• drop 112 bit ciphers
• drop non-FS ciphers (where possible)
• drop support for RC4
The following configuration lines would push you up the ladder significantly, in terms of security and rating at SSL Labs, while maintaining compatibility with most browsers:
SSLHonorCipherOrder on
SSLProtocol -All TLSv1.0 TLSv1.1 TLSv1.2
SSLCipherSuite CHACHA20:ECDHE+AESGCM:DHE+AESGCM:ECDHE+AES:DHE+AES
If you really, really need compatibility with IE 6/8 on Win XP you could use the following list. Note that the added entry is an explicitly listed cipher, not a pattern matching cipher, so requires dashes (-) instead of plus (+) signs between its elements.
SSLHonorCipherOrder on
SSLProtocol -All TLSv1.0 TLSv1.1 TLSv1.2
SSLCipherSuite CHACHA20:ECDHE+AESGCM:DHE+AESGCM:ECDHE+AES:DHE+AES:DES-CBC3-SHA
OTOH, if you can afford to lose some ancient clients you could limit your list to a current set of ciphers:
SSLHonorCipherOrder on
SSLProtocol -All TLSv1.0 TLSv1.1 TLSv1.2
SSLCipherSuite ECDHE+CHACHA20:ECDHE+AESGCM:ECDHE+AES256+SHA384:ECDHE+AES256+SHA
If you have a very limited audience that can make it to actually maintained major browsers on maintained operating systems, you could tighten security even further:
SSLHonorCipherOrder on
SSLProtocol -All TLSv1.2
SSLCipherSuite ECDHE+CHACHA20:ECDHE+AESGCMHi ecdsa-chacha20,
thanks for your help. Now i get an A as result 
This page has helped me with the correct settings
The link you refer to is … well … nice, but neither ‘correct’ nor perfect. And so is your setup.
• He uses ‘ECDH’ and ‘DH’ in the ciphers where he should use ‘ECDHE’ and ‘DHE’ instead. Perhaps he hasn’t understood that there are actually non-PFS key exchange mechanisms available in some ciphers actually which could be caught by these specifiers.
• His bashing of ECDSA is not adequate these days. Support for cheap ECC (ECDSA) certificates is there, and setup is just as easy as the setup of an RSA certificate.And the string would not increase at all since most of the well-written pattern matching specifiers would hit comparable ECDSA ciphers and RSA ciphers without modification. Some browsers like IE before Win10 would actually benefit from ECDSA keys as they support more recent ciphers with that kind of key, like TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c), which they do not support with RSA keys. Another benefit of ECDSA keys: DHE is completely gone and with it the dhparam file.
• Disabling DSS at the end is just stupid and obfuscates the pattern string unnecessarily. Without a DSA key, no DSA/DSS cipher would be chosen anyway.
• In total, he offers way too many ciphers.
Consequently, you’re offering 21 ciphers of which the listed web clients/browsers use a total of 9. The other 12 are completely useless and can be excluded from the list of offered ciphers: The less ciphers you have, the smaller is the attack vector if one of these unused ciphers is found to be vulnerable. Here is the list of ciphers you are offering but no client will ever use if he is not specially crafted to ignore better ciphers:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
Of the remaining ciphers 4 are used by ancient clients only. As you seem to be running OwnCloud I would suppose you tie it with some personally known PCs and recent smartphones, so we should be able to rule out these ancient clients and with them the ciphers required for supporting them:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) (Android 2.3)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) (IE8/XP)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) (Java 7u25)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) (OpenSSL 0.9.8)
Note: Of these four, you could think about enabling the DHE and ECDHE ciphers one by one if you really, really need them. However, I would definitely go for FS-only ciphers before supporting IE8/XP with its inferior RSA key exchange. And, yes, of the remaining three only Android 2.3 cannot upgrade. Java7 and OpenSSL 0.9.8 based clients should definitely go forward. It’s about time.
Leaves us with a list of a total of 5 ciphers actually used by current clients.
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
The respective cipher list can be described easiest as
SSLCipherSuite ECDHE+AESGCM:DHE+AES256+AESGCM:ECDHE+AES256
Some people insist that we’re in big trouble with AES256 compared to AES128. If you’re still wearing that same tinfoil hat you should limit your cipher list to AES128:
SSLCipherSuite ECDHE+AES128+AESGCM:DHE+AES128+AESGCM:ECDHE+AES128
As a side effect, this reduces the number of ciphers you offer to just 4 but increases your client coverage by Java7.
Finally, three more things you can optimize in your setup:
Add HSTS headers to your https server as I saw that http calls are already redirected to https. This would reward you an A+ instead of A by SSL Labs.
You should disable HTTP compression for fixing BREACH (CVE-2013-3587).
You could raise your score on Key Exchange by following http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcertificatefile and appending strong dhparam and ECparam values to your certificate. However, your server string is indicating Apache 2.2.22 which might not yet support this feature.
Note: later, when ECDSA keys are supported by LE (or when you can afford a fortune of about $13 total for a three-year DV ECDSA key) the SSLCipherSuite wouldn’t have to change at all for supporting the new key. But since DHE is not supported with ECDSA keys, you could drop this non-matching pattern so that the cipher string could become as short as the following:
SSLCipherSuite ECDHE+AESGCM:ECDHE+AES256
or, if you insist on pushing AES128 instead of AES256, a single pattern is sufficient to match the three ciphers you’d need:
SSLCipherSuite ECDHE+AES128Hi,
when i use this command in my ssl.conf
my apache server fails to start. I've no idea what's wrong. I can't find the problem in the apache access.log. Do you have an Idea?
error.log is the file you need here.
If I try that on a default install, I get an error of
SSL routines:SSL_CTX_set_cipher_list:no cipher match
What cipher do you really want ?
SSLHonorCipherOrder on
SSLProtocol -All TLSv1.0 TLSv1.1 TLSv1.2
SSLCipherSuite CHACHA20:ECDHE+AESGCM:DHE+AESGCM:ECDHE+AES:DHE+AES
provides good security whilst while maintaining compatibility with most browsers
What does openssl ciphers -V 'ECDHE+AES128+AESGCM:DHE+AES128+AESGCM:ECDHE+AES128' output?
(you could also try openssl ciphers -V 'ECDHE+AES128+AESGCM:DHE+AES128+AESGCM:ECDHE+AES128:!DSS:!ECDSA' to mask ciphers for irrelevant key types DSS/DSA and ECDSA)
you should get something like
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
openssl ciphers -V 'ECDHE+AES128+AESGCM:DHE+AES128+AESGCM:ECDHE+AES128'
Error in cipher list
140224240391840:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1314:
although I use SSLCipherSuite CHACHA20:ECDHE+AESGCM:DHE+AESGCM:ECDHE+AES:DHE+AES which seems to work nicely for me.
maybe you statically compiled a different version of openssl for apache versus system openssl.
I know the no cipher match message comes up for me as my centos system openssl uses openssl 1.0.1e variant but my nginx server uses openssl forked, libressl 2.2.4 so it supports chacha20 cipher natively
Hi @serverco, seems you’re running openssl 1.0.1. This version doesn’t support specifying kx as ‘ECDHE’ and ‘DHE’ but they have to be named ‘EECDH’ and ‘EDH’, respectively. Sigh, openssl had to go a long way from actually supporting DHE/ECDHE to supporting ‘DHE’ and ‘ECDHE’ in the ciphers string … https://groups.google.com/forum/#!msg/mailing.openssl.dev/ijjgngLkGlM/vUKOrHz_yBwJ
Please retry with the following string:
openssl ciphers -V 'EECDH+AES128+AESGCM:EDH+AES128+AESGCM:EECDH+AES128'
or
openssl ciphers -V 'EECDH+AES128+AESGCM:EDH+AES128+AESGCM:EECDH+AES128:!DSS:!ECDSA'Hi, You are correct - version 1.0.1f
Your suggested strings both work, thanks 