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:
(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.
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.
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:
Thanks. This helped a lot, although not enough. Things that work now:
WinXP support (yay)
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.
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.
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.