15

Normally I don't use Internet Explorer at all. I use it only in design time for interface tests (development machine and with unencrypted http). Every week I run the SSL Labs server test which says IE11 is able to access my sites.

Today I discovered an issue with one of my 3rd party services. Some special function is not working with Chrome or Firefox so I launched IE11 on my Windows 7 machine. And IE11 shows me a builtin error page witch basically only says "the page could not be shown". And the typical dummy bla bla like check the DNS and so on. There was absolutely no sign of an encryption related issue on the entire error page (like normal browser would do).

Back a couple of month there was this schannel issue which prevents TLS1.2 enabled IEs to access HTTPS sites. From that point in time my "WTF checklist for IE" contains "disable TLS1.2" as a checkpoint. And what should I say... disabling TLS1.2 within IE worked and my site is available again. But I can't do this on my visitors browsers.

Now to the real questions: Why Why does Internet Explorer 11 is unable to connect to my HTTPS site when TLS 1.2 is enabled within IE? And how to fix it on server side? SSL Labs is telling that everything is fine on my site.

Imporant Edit: It seems that IE11 can handle only the non-prefix domain and not the prefixed domains when TLS1.2 is enabled. domain without prefix (www) works while domain including prefix (www) won't work.

On the server side I'm using debian/7 nginx/1.7.8 openssl/1.0.1e

Available ciphers are: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:-DES:!RC4:!MD5:!PSK:!aECDH:EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

burnersk
  • 1,966
  • 4
  • 25
  • 38
  • 3
    I might be related or not: your certificate has duplicate SAN entries for ssl.dev5media.de. Maybe IE11 croaks about that? Apart from that the CN is ssl.dev5media.de, i.e. has the ssl prefix and not no prefix as you describe. – Steffen Ullrich Mar 22 '15 at 10:01
  • Thanks for pointing that out, @SteffenUllrich. CN was without prefix before my last certificate rotation a couple of weeks ago. I will remove the CN part within the question. But **anyway**... it is working when TLS1.2 is disabled. Shouldn't the certificate validation be in a shared library and not within the encryption method implementations (TLS1.0, TLS1.1, TLS1.2)? – burnersk Mar 22 '15 at 10:02
  • 1
    The site `www.dev5media.de` works for me on IE11, Win7 with TLS 1.2 and cipher `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` according to a package capture. Which OS do you use and can you do a packet capture for both the working and the non-working name to see the difference? – Steffen Ullrich Mar 22 '15 at 10:16
  • @SteffenUllrich: I'm not an Wireshark expert but I looks like the www.dev5media.de handshake (with `TLS_DHE_RSA_WITH_AES_128_GCM_SHA256`) is done successfully. But after `Server Hello Done` there is no communication from client to server. – burnersk Mar 22 '15 at 10:32
  • As mentioned above I'm using Windows 7 (Professional x64) and Internet Explorer 11(.0.9600.17691). – burnersk Mar 22 '15 at 10:38
  • 2
    Fwiw, I tried with IE11 (11.0.9600.17690) on Windows 8.1 and got the generic "This page can’t be displayed" error for both `https://dev5media.de/` and `https://www.dev5media.de/`, so somehow I got a more consistent result. – Håkan Lindqvist Mar 22 '15 at 10:41
  • Not directly addressing the question but you may want to consider taking inspiration from https://wiki.mozilla.org/Security/Server_Side_TLS – Håkan Lindqvist Mar 22 '15 at 10:44
  • @HåkanLindqvist My cipher list should be (excluding two "teaks") exactly the same what comes out of the Mozilla config generator. – burnersk Mar 22 '15 at 10:47
  • Microsoft had a lot of problems with their recent patches to SecureChannel, so I suggest it has something to do with it (my Win7 was just a VM which is probably not up to date with patches). See http://www.infoworld.com/article/2883756/security/microsoft-s-ssl-3-0-poodle-busting-patch-kb-3023607-breaks-cisco-s-popular-vpn-client-anyconnect.html. I would suggest you disable the GCM, SHA256 and SHA384 ciphers for now. – Steffen Ullrich Mar 22 '15 at 10:52
  • @burnersk I just had to ask, does it work without the tweaks? – Håkan Lindqvist Mar 22 '15 at 10:58
  • @HåkanLindqvist: unfortunately, it does *not* work :( Switching back to my version. – burnersk Mar 22 '15 at 11:06
  • @burnersk I'm at a bit of a loss then. Their 'modern' config works for me. – Håkan Lindqvist Mar 22 '15 at 11:32
  • @burnersk: have you tried to disable GCM, SHA256 and SHA384 ciphers? These are all TLS1.2 ciphers but you can get TLS1.2 even without these ciphers. – Steffen Ullrich Mar 22 '15 at 13:28
  • 1: Is a CNAME required for www (vs A)? nginx can have both names in the same server block. Microsoft has had issues with schannel and canonicals as alias names (LDAP): http://answers.microsoft.com/en-us/office/forum/office_2013_release-outlook/cannot-connect-to-ldap-ssl-with-error-81-on-server/78999b14-c4fc-46ce-bddc-36307bd156ed – ǝɲǝɲbρɯͽ Mar 28 '15 at 21:43
  • Today I had the problem with "ssl_session_tickets off;" and certificate authentication (in virtualhosts with the same CN on different ports). I used [Mozilla Server Side SSL Configurator](https://mozilla.github.io/server-side-tls/ssl-config-generator/) Intermediate profile which DOES recommend the use of this directive. But it doesn't worked with IE11/Win8.1. I had to comment it out. – erny Oct 17 '16 at 08:07
  • Another case like this: IE11 / Windows 7 does'n connect: I had to disable session cache. I had no time to debug this, but I fear that SSL sessions are shared between different ports, such that if I start with a SSL connection without cert authN and then jump to another with cert authN, no client certificate is requested. Currently I have to comment out "ssl_session_tickets off" and "ssl_sessio_cache ...shared...". – erny Oct 18 '16 at 11:00

3 Answers3

5

Do you also have SSL 2.0 enabled?

According to http://support.microsoft.com/en-us/kb/2851628 "SSL 2.0 and TLS 1.2 are not compatible with each other in Windows 7 and later operating systems. To use client-side certificates to establish an HTTPS connection over TLS 1.2, you must disable SSL 2.0".

John Ball
  • 481
  • 4
  • 3
3

Ran into this issue today with IE11 on Win 7 (fully updated with important updates, but not optional ones), when using Mozilla's Intermediate suite, which works fine with IE8 on XP and is supposed to work with IE7+. Thought I'd post here is this issue doesn't turn up much else on google.

Spent some time with wireshark figuring out the minimum modification required to make it work. Disclaimer: I am not a crypto expert, there could be a better way to do this. But it did not change my ssllabs.com rating at all.

Move ECDHE-RSA-AES128-SHA256 (the first one that works for IE11) up above kEDH+AESGCM and DHE-RSA-AES128-GCM-SHA256, for the intermediate suite resulting in:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
aaron-bru
  • 31
  • 1
  • 's answer should be as accepted. Just move ECDHE-RSA-AES128-GCM-SHA256 to be the first in the list. I had the same problem in nginx-ingress in k8s and changed in cofigmap: ssl-ciphers: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 ssl-protocols: TLSv1.3 TLSv1.2 – denis111 Jan 29 '20 at 11:51
0

The only solution I have found: http://www.techsupportall.com/solved-cannot-access-secure-sites-https-websites-not-opening-view/
There is instruction how to REGSVR to Internet Explorer.

T.Todua
  • 204
  • 4
  • 14