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

Closed
intgr opened this Issue Dec 2, 2015 · 72 comments

Projects

None yet
@intgr
intgr commented Dec 2, 2015

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:

letsencrypt-xp1
letsencrypt-xp2

@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
intgr commented Dec 2, 2015

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
intgr commented Dec 2, 2015

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
intgr commented Dec 2, 2015

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

letsencrypt-xp3

@bdaehlie bdaehlie was assigned by pde Dec 2, 2015
@jsha
Contributor
jsha commented Dec 3, 2015

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
intgr commented Dec 3, 2015

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

@intgr intgr changed the title from Is Chrome/IE8 with Windows XP officially broken with Let's Encrypt? to Let's Encrypt intermediate not accepted by Chrome and IE8 on Windows XP Dec 3, 2015
@jsha
Contributor
jsha commented Dec 3, 2015

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!

@jsha jsha closed this Dec 3, 2015
@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
intgr commented Dec 4, 2015

@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
Contributor
jsha commented Dec 4, 2015

@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
Depicus commented Dec 4, 2015

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
naox commented Dec 6, 2015

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

@soukicz
soukicz commented Dec 7, 2015

(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
naox commented Dec 7, 2015

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/

crap

@naox
naox commented Dec 9, 2015

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

@rugk rugk referenced this issue in EFForg/https-everywhere Dec 9, 2015
Merged

[Openresty.org.xml] New ruleset #3102

@mustenero

Opera has the same problem as Chrome.

@knyttl
knyttl commented Dec 16, 2015

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?

@knyttl
knyttl commented Dec 16, 2015

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
soukicz commented Dec 16, 2015

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

@knyttl
knyttl commented Dec 16, 2015

@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
Depicus commented Dec 16, 2015

@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
Member
pde commented Dec 18, 2015

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
dakusan commented Dec 31, 2015

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

@davidearl

One of my site visitors using Chrome 47 on Win XP has just hit this. I assume it's the same, the certification path window looks identical.

Are you sure this isn't as simple as the apostrophe (in "Let's Encrypt Certificate Authority X1") in the intermediate certificate name not being allowed by XP's certificate management? That's what the error message seems to imply.

@measlyweasel

+1 since this issue is closed it would be nice to have a replacement issue somewhere to monitor if this gets fixed or worked on in the future. Thanks!

@jsha
Contributor
jsha commented Jan 12, 2016

Hi all,

I've opened a community forum thread asking for help debugging the issue and a proposed fix: https://community.letsencrypt.org/t/windows-xp-support/8756. That's the best place to continue this conversation for now, and will be updated when we know more. Thanks!

@paour
paour commented Jan 13, 2016

Note that on renewal attempts, letsencrypt-auto fails on the RewriteCond rule because the parameters aren't quoted.

Use this syntax instead:

RewriteCond "%{HTTP_USER_AGENT}" "!(Windows\ NT\ 5\.1|Windows\ NT\ 5\.2)" [NC]
@anthony-o

Chrome on XP has still the same problem, why this issue has been closed?

@o5
o5 commented Feb 10, 2016

@anthony-o: I think here is some bug on github side, because @jsha closed this issue with his last comment.

@rugk
Contributor
rugk commented Feb 10, 2016

@o5 And what is the GitHub bug here?
Yes, @jsha closed it, but there is a community thread where this discussion is continued.

@o5
o5 commented Feb 10, 2016

@rugk: Sorry, I missed :))
screen shot 2016-02-10 at 19 07 55

@yonjah
yonjah commented Feb 25, 2016

So if I'll summarize this issue.
The only fix is if LetsEncrypt can find XP supported CA that will issue an Intermediate certificate that doesn't have any Name Constraints at all.

Is this a likely scenario or this issue is not likely to be resolved ?

@pedrosanchezpernia

However it works fine on XP with Firefox, so not to blame Windows after all,
but a lack of update from Chrome maybe ?
Which it should be "easy" to address, because Google Chrome is a Platinum Sponsor of Let's Encrypt...

@nitmir
nitmir commented Feb 26, 2016

Chome use the windows certificate store while firefox use its own cert store. That's why it works with firefox.

@davidearl

Yes, Chrome and Internet Explorer share the same certificate technology and also access to sites via SNI, so both fail on XP in either case. Firefox has its own support for both, so Firefox works on XP in most cases the others don't.

HOWEVER, people who are stuck on XP are often there because they have few other choices. I don't think Chrome is so much the worry here, but Internet Explorer 8 users. Despite lack of support for XP and IE8, it is going to be around for a long time to come, and they are being locked out. Often the people with this kit are either forced to use a particular configuration by employers, possibly because they use old software which is essential to their business but won't work on newer OS or they won't invest in new hardware, or, more seriously in my opinion, because they are among the most disadvantaged, often in poor countries, and least knowledgeable people - they can't afford to upgrade, and they haven't a clue why things don't work any more. Or it is older people who find change very difficult - they have understood their computer, just about, over a long period, and they can't face the prospect of change, even quite minor change.

One of the really pernicious things about this problem is that there is no opportunity to say what's gone wrong and to offer advice (e.g. "use Firefox, it's got a longer shelf life on your hardware"), and worse, what does happen is extremely frightening for these users - it's all about how someone is attacking you (same is true of SNI on XP/IE8).

So I think we do the people least able to sort out their situation a huge disservice by not addressing this issue with some importance. There's an equality and fairness problem behind the technical one.

@as-com
as-com commented Feb 26, 2016

@davidearl Agreed. Sometimes, we developers forget how clueless users can be. Also, for me, the htaccess workaround doesn't work for me, because my sites use HSTS and are in the preload list and will not fall back to plain HTTP..

Maybe I should probably go back to StartSSL, because it seems to work fine on XP.

@rugk
Contributor
rugk commented Feb 26, 2016

and are in the preload list

But users on Windows XP won't have an IE with this preload list...

@as-com
as-com commented Feb 26, 2016

@rugk but many of them run Google Chrome, which does have the reload list.

@rugk
Contributor
rugk commented Feb 26, 2016

Okay.

@hwdsl2
hwdsl2 commented Mar 2, 2016

Good news: Upcoming Features - Certificate Compatibility with Windows XP
https://letsencrypt.org/upcoming-features/

@yonjah
yonjah commented Mar 3, 2016

πŸ‘ Great news

@as-com
as-com commented Mar 3, 2016

πŸŽ‰

@jkellererwsu

I see that it is an upcoming feature that should come out in a week, my question, will this automatically work, or will I just need to rerun the cert?

@intgr
intgr commented Mar 15, 2016

@jkellererwsu Yes, you will need to renew the certificate.

@paulocastellano

This fix is out?

@paulocastellano

I waiting for this fix, we have around 20 computers with win XP and Chrome with this bug.

Note:*

With WinXP + Firefox is working normally

@dasa123
dasa123 commented Mar 25, 2016

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
soukicz commented Mar 25, 2016

@dasa123 That's just wrong.

@dasa123
dasa123 commented Mar 25, 2016

@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
soukicz commented Mar 25, 2016

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.

@dasa123
dasa123 commented Mar 25, 2016

@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:

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
yonjah commented Mar 26, 2016

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.

@dasa123
dasa123 commented Mar 26, 2016

@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
yonjah commented Mar 26, 2016

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 )

@dasa123
dasa123 commented Mar 26, 2016

@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
arzeth commented Mar 26, 2016

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
Contributor
jsha commented Mar 26, 2016

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
Contributor
rugk commented Mar 27, 2016

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. πŸ˜ƒ

@bdaehlie bdaehlie was unassigned by intgr May 6, 2016
@xiaobailong24

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

@Chupaka
Chupaka commented Nov 6, 2016

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
Chupaka commented Nov 6, 2016

I hope, "win7" is not XP :)

@xiaobailong24

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

@Majkl578
Majkl578 commented Nov 7, 2016

@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
Lohoris commented Dec 7, 2016 edited

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
Contributor
jsha commented Dec 8, 2016

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment