My certificat is working in Safari and IE, but not in Firefox

My site " " 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

1 Like


Connecting to 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/
SSLCertificateKeyFile /etc/letsencrypt/live/

Now (working with all browsers):
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
SSLCertificateChainFile /etc/letsencrypt/live/


1 Like

Hi @sven45,

you should take a look at your other server settings related to SSL/TLS, they are not okay.

1 Like

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

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

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

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

Hi ecdsa-chacha20,

thanks for your help. Now i get an A as result :smile:

This page has helped me with the correct settings

Hardening Your Web Server’s SSL Ciphers

1 Like

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_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_128_CBC_SHA256 (0x3c)

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_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.


The respective cipher list can be described easiest as


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:


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:

  1. 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.

  2. You should disable HTTP compression for fixing BREACH (CVE-2013-3587).

  3. You could raise your score on Key Exchange by following 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:


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+AES128
1 Like

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

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 …!msg/

Please retry with the following string:

openssl ciphers -V 'EECDH+AES128+AESGCM:EDH+AES128+AESGCM:EECDH+AES128'


1 Like

Hi, You are correct - version 1.0.1f

Your suggested strings both work, thanks :slight_smile: