Let's Encrypt intermediate not accepted by Chrome and IE8 on Windows XP

[intgr]

I know and I've heard all the caveats that Windows XP is unsupported, etc etc. But there's still a significant user base left on Windows XP.

If Let's Encrypt certificates are officially known to be broken on Windows XP, that's fine. But there should be a clear official statement of that fact somewhere (e.g. Let's Encrypt FAQ), so everyone who has this issue, knows that they're SoL.

Screenshots of Chrome on Windows XP with certificate details:

[aaronmehar]

It wouldn't be the certificate that is not compatible but the implementation of it, as the procurer of the certificate it would your job to ensure its works for your user base, for XP users, they should upgrade to 7-10 or use a proper OS, such as Fedora or Ubuntu. If they insist on using crap, you will need an IP per certificate, letsencrypt have chosen to use SNI (good for them), although SNI should work on Chrome6 in XP.. what service pack are you running?

[intgr]

If they insist on using crap, you will need an IP per certificate, letsencrypt have chosen to use SNI (good for them),

This is not an SNI issue, as you can see from the screenshots. I am being provided with the correct helloworld.letsencrypt.org certificate. It's just not verifying.

The screenshots are from my Windows XP virtual machine, that has SP3 and all available Windows updates applied. It's running Chrome version 47.0.2526.73 m.

[intgr]

If anyone wants to reproduce this issue, Windows XP virtual machines are available from Microsoft: https://dev.windows.com/en-us/microsoft-edge/tools/vms/linux/

aaronmehar is right that you can't test IE8 on helloworld.letsencrypt.org due to lack of SNI, but you can install Chrome or try other websites in IE8 like https://paymail.pm/

[intgr]

I found that the "Extended Error Information" gives some additional detail...

Missing Name Constraint for <DNS Name=helloworld.letsencrypt.org>
Missing Name Constraint for <Directory Address:CN=helloworld.letsencrypt.org>

It seems that it's getting confused by the .mil name constraint exclusion. The Name Constraints field shows:

Permitted=None
Excluded
     [1]Subtrees (0..Max):
          DNS Name=.mil

Notice how it thinks Permitted=None. Could this be fixed by adding an explicit permitted name constraint for all top-level domains?

RFC 5280 about x.509 Name Constraints: https://tools.ietf.org/html/rfc5280#section-4.2.1.10

[jsha]

I've confirmed this using the Windows XP VM from https://dev.windows.com/en-us/microsoft-edge/tools/vms/linux/. I'll update our FAQ, and we can look at how to fix the issue longer-term.

[intgr]

@jsha Thanks. Should I create a new issue to fix WinXP compatibility, or rename/edit this one?

[jsha]

Any fix is going to be an administrative/signing issue for Let's Encrypt, not something specific to either the client or the server. So I'm closing out this issue. The problem is documented on the community forums now, and we'll track any possible fixes internally. Thanks so much for digging into it!

[centminmod]

thanks @jsha for the clarification.. maybe this can make it into official manual too at https://letsencrypt.readthedocs.org/en/latest/intro.html ?

[intgr]

@jsha

The problem is documented on the community forums now, and we'll track any possible fixes internally.

That's not saying much. Will you be working to create a new intermediate certificate to enable Windows XP compatibility, or is this just a polite "wontfix"?

[jsha]

@intgr: Sorry I can't commit more! This is a polite "very busy with post-launch at the moment, need get together a quorum of colleagues to discuss the issue in detail." :-)

[Depicus]

For anybody with this issue it is possible to work round with Apache and mod_rewrite using the following code

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_USER_AGENT} !(Windows\ NT\ 5.1|Windows\ NT\ 5.2) [NC]
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}

Basically pop this in your :80 .conf and Windows XP users will not be redirected to https but everything else will. You can add other user agents as required.

[naox]

+1
Don't give up on supporting windows xp yet please.

[soukicz]

(Probably) the same problem is with Android 2.3. Certificate is loaded correctly (no SNI or protocol problem) but is refused because of "domain mismatch".

Forum topic: https://community.letsencrypt.org/t/san-domain-name-mismatch-android-2-windows-xp/4060

[naox]

I suspect that problem is not in intermediate certificate but actualy in the issued end certificate - in a X509v3 Certificate Policies field that windows xp certification managment tool see as hex gibberish (and in case of all other certificates on the internet it is not so). Owner of the project: please test by issuing end certificate without X509v3 Certificate Policies field or set it to something simpler or at least move it higher in the structure so its not directly below X509v3 Subject Alternative Name as its seem to interfere with it

            X509v3 Subject Alternative Name:
                DNS:xxxxxxxxxxxxxxxx
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org
                  User Notice:
                    Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/

[naox]

@Soukiii

(Probably) the same problem is with Android 2.3. Certificate is loaded correctly (no SNI or protocol problem) but is refused because of "domain mismatch".

There are no problems with certificate on android 2.3.6 stock browser as I tested.

[mustenero]

Opera has the same problem as Chrome.

[vojkny]

I think it would be very helpful if the generated apache configs would take these into account and WXP wouldn't redirect to https.

<VirtualHost *:80>
    DocumentRoot /www/domain.com
    ServerName domain.com
    ServerAlias www.domain.com
    RewriteEngine on

    RewriteCond %{HTTPS} off
    RewriteCond %{HTTP_USER_AGENT} !(Windows\ NT\ 5) [NC]
    RewriteRule ^ https://www.domain.com%{REQUEST_URI}
</VirtualHost>
<VirtualHost *:443>
    DocumentRoot /www/domain.com
    ServerName domain.com
    ServerAlias www.domain.com
    RewriteEngine on

    RewriteCond %{HTTPS} on
    RewriteCond %{HTTP_USER_AGENT} (Windows\ NT\ 5) [NC]
    RewriteRule ^ http://www.domain.com%{REQUEST_URI} [L]

    SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

[mustenero]

knyttl this configuration is for apache. Have you some idea how do that on haproxy?

[vojkny]

In the end it doesn't help as the :443 won't redirect on invalid certificate. Anyone who bumps into https:// will get the error. Now it seems to me that these certificates are completely useless.

[soukicz]

It cannot be solved with redirects. It doesn't work for links to https (from Google for example) and it is huge security risk.

[vojkny]

@Soukiii: Yes you are right, my mistage. This means there is no way to overcome this issue for WXP users. I can't imagine any website which could settle down for only non-wxp users.

[Depicus]

@knyttl Well if you want to be PCIDSS compliant you can no longer use TLSv1 which affects a lot more that XP users, it goes to IE10 on Windows 7. So while this bug is annoying lots of sites will have to exclude IE and Chrome on XP and a whole lot more if they want to take credit card details.

[pde]

For the folks who want a way to redirect some but not all of their visitors to HTTPS, there's a new ticket about that client functionality: #1942

[dakusan]

Since this ticket is closed, is there anywhere that we can subscribe to follow when WinXP becomes compatible?

[brianjking]

https://community.letsencrypt.org/t/upcoming-intermediate-changes/13106 @strigona-worksight Yeah, see here.

[duxsco]

With the following Javascript code, the browser tries to load a file over https. If that works, the user gets redirected to https (source: http://stackoverflow.com/a/27896066). This might be useful if you only want to redirect browsers that support your cipher suites. In contrast to above approach (#1660 (comment)), this code also redirects visitors that use Firefox in Windows XP.

<form style="display:none;" method="get" name="redirect"></form>
<script type="text/javascript">
if (window.location.protocol != "https:") {
        var img=document.createElement('img');
        img.src='https://' + window.location.hostname + '/favicon.png';
        img.onload = function() {
                var redirect_form = document.forms["redirect"];
                redirect_form.action = "https:" + window.location.href.substring(window.location.protocol.length);
                redirect_form.submit();
        }
        img.style.display='none';
        document.body.appendChild(img);
}
</script>

[soukicz]

@dasa123 That's just wrong.

[duxsco]

@Soukiii I know it's not an ellegant solution. I myself just use the following on my webserver:

server {
        listen 80;
        return 301 https://example.org$request_uri;
}

But, the approach might be a viable option if you don't want to think about which browsers support SNI.

[soukicz]

No, it's not. Visitor clicks on HTTPS link in Google and gets error page - javascript doesn't even load. Https would be totally pointless if it could be disabled by untrusted certificate.

[duxsco]

@Soukiii

Visitor clicks on HTTPS link in Google and gets error page

Not everybody wants to take the risk of a big bang deployment of https-only website access and thus might set their Google Webmaster Tools and robots.txt up accordingly in order to get http links listed in the search engine results. You can't assume that every webmaster wants their website linked via https.

javascript doesn't even load

The code/redirect isn't supposed to run over https anyway:

• if (window.location.protocol != "https:") (Let's Encrypt intermediate not accepted by Chrome and IE8 on Windows XP #1660 (comment))
• <VirtualHost *:80> ... (Let's Encrypt intermediate not accepted by Chrome and IE8 on Windows XP #1660 (comment))
• listen 80; (Let's Encrypt intermediate not accepted by Chrome and IE8 on Windows XP #1660 (comment))

Https would be totally pointless if it could be disabled by untrusted certificate.

And https-only access protects you?! To prevent this: HSTS, HPKP, DANE, DNSSEC/TLSA Validator, certificate transparency

[yonjah]

The thing is @dasa123 , if you can afford to initiate insecure connection if ssl fails why can't you just do it for everyone else and drop ssl support completely?

And if the data going on the line is half critical, how can you afford to compromise users just to have more traffic ?

I think security best practice learned us that if you can't serve on a secure connection you should fail the connection with as much bells and whistles. It is in the user best interest not to interact with your site if the connection is not secure.

And you are right that https-only is only making one link in the security chain stronger, but I don't see how this is a case for making it weaker.

[duxsco]

@yonjah Like I said, big bang deployment is not a solution for everybody. https deployment is always a tightrope walk between security and usability. If Google would follow your argumentation, they would drop RC4 based ssl ciphers. But, they want to support legacy systems and still support insecure ciphers (https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com&hideResults=on). You as a security focused person are often not the sole policy maker. This is especially true if you are responsible for a company website where the company managers, important customers etc. have a say, too.

The thing is @dasa123 , if you can afford to initiate insecure connection if ssl fails why can't you just do it for everyone else and drop ssl support completely?

You can grant website visitors different levels of usage rights, e.g.:

• Windows XP without https support => Leave them on http and inform them to switch their operating system or at least move to current Firefox version. Disable "login" and "register" functionality.
• Windows XP with Firefox => Redirect to https and inform them to use https in the future via HSTS
• Modern systems => Allow only https

If hardly any website visitor comes without https support, you make the switch to https-only access.

And if the data going on the line is half critical, how can you afford to compromise users just to have more traffic ? I think security best practice learned us that if you can't serve on a secure connection you should fail the connection with as much bells and whistles. It is in the user best interest not to interact with your site if the connection is not secure.

You might not be the sole decission maker. The company might earn their money with the website...
What do you think is the reason for amazon.com still supporting http alongside https?

And you are right that https-only is only making one link in the security chain stronger, but I don't see how this is a case for making it weaker.

https is flawed by nature. Just because you allow access only over https doesn't mean that the connection can't be "disabled by untrusted certificate" (#1660 (comment)). A recent case: https://security.googleblog.com/2015/03/maintaining-digital-certificate-security.html

[yonjah]

If Google would follow your argumentation, they would drop RC4 based ssl ciphers.

@dasa123 Google are in the process of dumping rc4 -
https://security.googleblog.com/2015/09/disabling-sslv3-and-rc4.html

Also there is huge different between using rc4 which will offer a bit less secure connection to small part of your users (users using evergreen browsers without rc4 support are not affected, and even if an rc4 connection is made, a real world attack is hard to implement (best I know is ~50 hours for decrypting a cookie). Compare to your suggestion where XP users by design don't have any security at all, and all a MITM has to do is to drop ssl connections and now any users will not have any secure connection at all.

You can grant website visitors different levels of usage rights, e.g.:

• Windows XP without https support => Leave them on http and inform them to switch their operating system or at least move to current Firefox version. Disable "login" and "register" functionality.
• Windows XP with Firefox => Redirect to https and inform them to use https in the future via HSTS
• Modern systems => Allow only https

I think this approach is totally OK if you need to have maximum availability and don't have any other choice. But your JS code (and any other solution that was offered here ) doesn't offer this solution. Any one who wish to implement this kind of solution will have to probably write it specifically for their infrastructure and the little code you have here to detect ssl has little value to none in that context.
So this solution is a bad idea since it only offers users who don't know any better a copy paste solution which is totally insecure in its published context.

If we go back to the company that want maximum availability and security for there users, they shouldn't use Letsencrypt until an xp support is available, since there are a lot of CAs out there that support XP this is a no brainer.
Thats why its vital for Letsencrypt to support XP (and hopefully they due, I'll check the new certs after the weekend )

[duxsco]

@dasa123 Google are in the process of dumping rc4 -
https://security.googleblog.com/2015/09/disabling-sslv3-and-rc4.html

... and they don't make it via big bang deployment which was the main point of this argument. They first announce, wait, test etc.

Compare to your suggestion where XP users by design don't have any security at all, and all a MITM has to do is to drop ssl connections and now any users will not have any secure connection at all.

If there is somebody having the motivation to act as a MITM and attack your website, you will not be protected by https-only either unless in some scenarios where such technologies as HPKP, HSTS, DANE etc. come into play. I didn't deny that the redirect is problematic.

But your JS code (and any other solution that was offered here ) doesn't offer this solution.

... and that's not what I claim.

So this solution is a bad idea since it only offers users who don't know any better a copy paste solution which is totally insecure in its published context.

Anybody who just applies brainless copy and past should just use the services of professionals, pay their monthly fee and avoid implementing Let's Encrypt on their system.

there are a lot of CAs out there that support XP this is a no brainer.

Even if you use such a CA, there might be other web clients not supporting your chosen webserver https settings or people still might want to redirect if possible. I think it's unrealistic to switch from http to https-only from one day to another.

[arzeth]

They fixed the incompatibility (not completely because it currently requires a little tweak — see below): https://community.letsencrypt.org/t/upcoming-intermediate-changes/13106!

I renewed my certificate (by the way, I have one cert for multiple domains):

./letsencrypt-auto renew --force-renewal

Then I changed nginx' parameter ssl_cipher (see https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations) (the following one doesn't support IE6):

ssl_cipher 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';

Then I tested my websites with Chrome and IE8 on Windows XP SP3 (no warnings, no errors).

[jsha]

Thanks for the input all! I'd encourage you to use the community forum to continue the conversation about how and whether to run a web server that supports both XP and newer operating systems.

[rugk]

You can't assume that every webmaster wants their website linked via https.

But it would be clever of them to do so as Google ranks HTTPS sites higher. 😃

[xiaobailong24]

win7 Chrome 53 with "This page is insecure (broken HTTPS)."
win7 Firefox no this problem

[Chupaka]

xiaobailong24, what page?

[davidearl]

Let's Encrypt fixed the original problem. Perhaps this is more likely to be SNI, which will still produce errors in Chrome and IE, but not Firefox, on WinXP for VirtualHost's other than the first one. If it's that, it's an XP problem, not a Let's Encrypt one.

[Chupaka]

I hope, "win7" is not XP :)

[xiaobailong24]

@Chupaka Thanks for your reply. My test page is https://www.aigoogle.club

[Majkl578]

@xiaobailong24 your domain does not match the certificate - it's issued only for aigoogle.club, not for www.aigoogle.club.

[xiaobailong24]

@Majkl578 Thank you a lot. That's my mistake. It's OK now!

[Lohoris]

Chrome 54 on Android has the same problem, and that's not exactly an old platform…

oddly, Chrome 55 on desktop works fine instead…

[jsha]

@Lohoris: Most likely you're experiencing a different problem. Chrome 54 on Android usually works fine with Let's Encrypt. Can you post at https://community.letsencrypt.org/ with the name of the site you're having a problem with, and a screenshot of the error?

[Lohoris]

Ok, I've opened a new issue over there, thanks.

https://community.letsencrypt.org/t/invalid-certificate-on-mobile-works-on-desktop/24295

[baptx]

When testing a website created with certbot on https://www.ssllabs.com/ssltest/analyze.html, I can see a confirmation that it works for Firefox and Chrome on Windows XP but not Internet Explorer:
IE 8 / XP - No FS - No SNI - Server sent fatal alert: handshake_failure
Will full Windows XP support be added in the default configuration or will we always have to do it manually? (explained here: #1660 (comment))

[davidearl]

The LetsEncrypt certificate problem with XP was fixed a long time ago. Your problem is that SNI is not supported in IE (or Chrome, I thought) in XP for https sites, which is nothing to do with LetsEncrypt.

[baptx]

Thanks, so even with the manual configuration, Let's Encrypt will never work with Internet Explorer on Windows XP?

[Chupaka]

It does work on Windows XP. It just won't work if there are several TLS sites on single IP address.

[jsha]

@baptx Please post about your site (including the full domain name) at https://community.letsencrypt.org/ and hopefully people will be able to help you debug your issue there. Thanks!