Hello folks,
I had the impression that the problem of the Let’s Encrypt certificates being incompatible for WinXP clients using IE or Chrome was supposed to be resolved a couple of weeks ago?
Our site’s certificate just got renewed (so, it’s supposed to have the new, compatible certificate), but if you follow the link
from IE running on WinXP, the site is inaccessible. (The same link with http instead of https will work, but that’s not the point.) Any ideas?
Windows XP SP3?
Your Apache SSL configuration looks to be wrong. Maybe you can post it here.
And use the fullchain.pem certificate.
Btw... Why you have MySQL PMA open for World?
I see the Problem… You have only TLS 1.2 active.
Windows XP only Support TLS 1.0 or SSLv2/v3 (don’t activate it) by default.
Try to activate TLS 1.2 in you Internet Explorer (Advanced Settings).
But still, there are Handshake issues. Please check your mod_ssl configuration
Practically, yes. I am testing it currently from the "Windows XP mode" virtual machine that comes with Win7 Pro; I don't have a real WinXP machine handy right now. The virtual one announces itself as Windows XP Professional Version 2002 Service Pack 3.
I can't do that right now; I don't have access to it. Will have to wait until the webadmin is available.
I think we do that already. (Means serving the certificates of the intermediaries together with the certificate of the site, right?)
I'm afraid I don't know what this means. Could you please elaborate? Like, what it is, why it is bad, and how to fix it? Links, etc.?
There is a reason for that. I think if we don't do it, Chrome reports in a tooltip that the site is using "obsolete ciphers" or something like that.
Ah, how do I do that? WinXP uses IE8. In the Advanced options, there are checkboxes for Use SSL 2.0, Use SSL 3.0 and Use TLS 1.0 - nothing about TLS 1.1 or 1.2. Are you sure that this can be done on WinXP?
But, anyway, if it is not done by default, we can't afford to do this. We can't tell our WinXP users how to configure their browsers, if they cannot access our site to begin with. I guess we'll have to degrade to TLS 1.0 and live up with the Chrome warning... 
Then adjust the cipher suite to be something Chrome doesn't consider obsolete. It is most certainly not the case that a web server (even an Apache web server) with TLS 1.0 enabled will necessarily give this error in Chrome. I can say this with certainty because I'm running an Apache web server with TLS 1.0, 1.1, and 1.2 enabled, and I use Chrome as my primary browser, and I don't get any such error. I can also access my server using IE8 on WinXP without any certificate errors.
It may be relevant to your problem that your site is serving the incorrect intermediate cert--it's serving the X1 cert, while it should be serving the X3 cert. You also have both TLS 1.0 and TLS 1.1 disabled, which seems unnecessary.
I'll have to discuss this with the webadmin but at the time disabling everything besides TLS 1.2 turned out to be the most reliable way of resolving the issue.
It's not an "error". I mean, the pages on the site are accessible just fine. It's a warning displayed in the information message that is shown when you click on the padlock sign. See, for instance, this:
https://community.qualys.com/thread/15723
(Although in that example the site uses TLS 1.2 and still gets the problem. It disappeared for us when we switched to TLS 1.2-only.)
Can you give me a link to test?
Do you mean that we are serving the certificate of the root instead of the certificate of the intermediary?
Some of the problems are probably the result from the fact that we had to hack things together, in order to use Let's Encrypt certificates on our Windows server. The fully automated scripts are currently designed for Linux only and we had to figure out what they are supposed to do and how to do it on our Windows platform. I can't wait for a Windows-oriented version of the scripts (I understand a PowerShell-based one is in the works). And, no, switching to Linux is not an option for us.
Try using Ivan Ristić’s very helpful SSL Server Test: https://www.ssllabs.com/ssltest/analyze.html?d=nlcv.bas.bg. For your site, it shows “Chain issues: Incomplete, Extra certs.” If you look closer, you’ll see that the server is providing the “Let’s Encrypt Authority X1” certificate, when it needs to be using the new “Let’s Encrypt Authority X3” certificate. The official client should have output the new certificate under chain.pem. If you’ve got some special scripts, they may not be correctly updating the chain on renewal.
You’ll also need to enable TLS 1.0 support. SSL Server Test shows your server currently supports only TLS 1.2, which is not supported by Windows XP clients by default. And I believe you will also need to enable at least one older cipher suite, e.g. DES-CBC3-SHA, that is supported on XP.
The long and the short of it is: Our intermediate certificates now work with XP, but you need to do some extra work to create a compatible configuration. There’s an open issue to make that easier.
Sure, although there's no content there right now: https://www.familybrown.org.
No, I mean you're serving the wrong intermediary cert. The way that WinXP compatibility was achieved involved creating new intermediate certs, and any new certs signed since that date are signed with the new intermediate. The old intermediate was X1 with a backup of X2; the new one is X3 with a backup of X4. Your cert was issued by X3, but you're serving the intermediate of X1.
Apologies for the late reply; I was down with a rather nasty flu… 
OK, we fixed a few things. (Look at madmaxsoft.net, this is a test site where we’re testing the configurations.)
We are now serving the correct intermediate certificate.
We have enabled TLS 1.1 and 1.0.
As a result, when checking the site with SSL Labs’ tool, many more platforms are now supported:
https://www.ssllabs.com/ssltest/analyze.html?d=madmaxsoft.net
Unfortunately, WinXP still isn’t. I suspect that the reason is in the set of ciphers we allow (and maybe also in their order). We are using an Apache server running on Windows. The supported ciphers are determined by the SSLCipherSuite line in http-ssl.conf, right? Here is how ours looks like:
SSLCipherSuite “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA EECDH EDH+aRSA !aNULL !eNULL !LOW !MD5 !EXP !PSK !SRP !DSS !RC4”
Unfortunately, I couldn’t quite figure out the syntax and meaning of all this from the documentation. How should I change this line, in order to support the ciphers you are supporting?
Also, I see that you have HSTS enabled on your server. Any hints how to do that?
Take a look at the Mozilla SSL Configuration Generator. The “Old” setting will yield a cipher suite with XP support. It also supports HSTS (the config line with Strict-Transport-Security).
With Windows XP SP3 you need to enable support for Triple DES. You can also do it by enabling RC4 but this is not recommended.
This is the configuration I use. Notice the +3DES within it:
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW +3DES 3DES !MD5 !EXP !PSK !SRP !DSS !RC4”
Thanks. This helped a lot, although not enough. Things that work now:
WinXP support (yay)
HSTS
I had to edit the configuration suggested by the SSL config generator by replacing “SEED” with “!SEED”, in order to disable two ciphers.
One thing still doesn’t work. According to the SSL Labs testing tool, the “Java 6u45” platform (whatever that is) is still not supported - while the site www.familybrown.org supports it. The error listed is “Client does not support DH parameters > 1024 bits | RSA 4096 (SHA256) | TLS 1.0 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA | DH 4096”, whatever that means. Any idea how to fix this?
Also, according to the SSL Labs tool, our site now supports exactly the same ciphers as www.familybrown.org, but their order is different. Unfortunately, I could not map the cipher names reported by the SSL Labs tool with the names used in the Apache config file, so I have no clue how to re-order them.
I would still like to see the SSLCipherSuite line used by www.familybrown.org.
Ask and ye shall receive:
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
Do you access your site programmatically with Java? If not, that's probably not a concern. Additionally, the DST root certificate is not included in the Java trust store, so even if you could get a TLS connection working in Java 6, it wouldn't be trusted unless you manually modify the trust store.
DH stands for Diffie-Hellman, a method by which two people can agree on a secret without a potential eavesdropper who can listen to all of their conversation learning the secret too. To do this a large prime number is used, the larger the prime number, the harder it is for an eavesdropper to learn the secret. "Logjam" was among other things the brand name for the idea that probably a rich industrialised nation like the United States of America can do the hard work to sometimes listen in when a 1024 bit prime is used, so people began using larger primes. Unfortunately version 6 of Java doesn't know how to handle such large prime numbers so it can't perform DH any more if you insist on a larger prime. This (as with the enabling of 3DES earlier) is a compromise between security and accessibility.
You don't need to understand that though, it's just in case you're interested.
As pfg pointed out, very few web sites need Java 6 to be able to access them. Humans won't be accessing your site with Java 6, they'd have a web browser like Firefox instead. So most likely you don't care. Also, again as pfg pointed out, Let's Encrypt certificates aren't trusted by Java 6 anyway.
Thanks. OK, we changed it to be like this, but it had no effect! I mean, I still get the line that says our site is incompatible with the "Java 6u45" platform and the ciphers, although the same as yours, are not ordered the same way, according to the SSL Labs tool.
Any ideas what else might be wrong?
Oh, I am quite familiar with Diffie-Hellman and crypto in general. What I am not familiar with is Apache configuration. I don't understand the syntax of this line, I can't map the cipher names listed by the SSL Labs tool to the cipher names used on this line, and I don't understand how to change the order of the ciphers.
Sadly, the person who is currently administering the site isn't a professional webadmin, either - he's just a web site designer. We know enough about security to want the most secure setting that is still as widely compatible as possible (we understand why supporting WinXP+IE6 is a bad idea, for instance) - but we lack the knowledge and experience to actually implement it.
Yes, I understand. It's not a priority. (While WinXP+IE compatibility was a priority.) Still, the site www.familybrown.org is compatible with this client, so I would like ours to be, too. Not important; just th perfectionist in me speaking. 
I would strongly advise you not to use 1024-bit DH because of Logjam.
That being said, this serverfault answer describes how to switch from 1024-bit to 2048-bit DH, so you could most likely use it in the reverse direction as well: http://serverfault.com/a/693244