Troubleshooting Internet Explorer handshake failures

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: wilawlibrary.gov

I ran this command: Tried to access https://wilawlibrary.gov on Internet Explorer

It produced this output: The site will not load https links in Internet Explorer

My web server is (include version): linux

The operating system my web server runs on is (include version): Apache 2.4.34

My hosting provider, if applicable, is: TMD Hosting

I can login to a root shell on my machine (yes or no, or I don’t know): no

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): cpanel 74.0.6

I ran our new Let’s Encrypt SSL through SSLlabs and see there’s a fatal handshake error for some browsers, such as IE. (https://www.ssllabs.com/ssltest/analyze.html?d=wilawlibrary.gov) We currently have a shared IP address. Would a fixed IP address fix this issue? Or is there some other configuration that must happen to make https work in IE? Our hosting provider is claiming that it’s not their problem.

Thanks!

2

Hi @letsuserwi

the site works well - InternetExplorer 11 and Edge, Windows 10. And FireFox.

Do you have a snapshot of the error?

PS: You have only TLS.1.2 activated. So older browsers can't connect the page.

I would activate TLS 1.0 and 1.1.

3

Hi,

The reason you would get a handshake failure is TMDhosting’s cPanel TLS cipher configuration.

This is not an issue that you could fix… (Changing cipher would affect all clients on that cPanel server)

All three TLSv1.2 ciphers the hosting provider support is 0xc030,0xcca8, 0xc02f and those aren’t included in any of those “handshake failure” browsers…

This is not (fully) a dedicated IP thing since it would have the same result as SNI (except on XP) & it’s not fully a TLS protocol thing…

Two way to resolve this:

  1. Ask TMDhosting to enable more cipher on your shared hosting server
  2. Switch to a Hosting provider that support more cipher or get VPS / Dedicated Hosting

Thank you

2 Likes
4

Thanks! Very helpful overview.

5

Thanks, I’m using IE 11 on Windows 7 and get the following: https://wilawlibrary.gov/special/8-27-2018%208-26-42%20AM.png

That’s our staff environment, so it’s necessary that I support it! My version of IE 11 (at least according to the test of my browser I just ran on SSLlabs) has TLS 1.2 activated.

6

I would check that all the clients are using the latest available ciphers.
Although Microsoft Updates the O/S and IE, it doesn’t always automatically turn on the newly added “features”.
You can check your systems’ ciphers with:
https://www.nartac.com/Products/IISCrypto/
https://www.ssllabs.com/ssltest/viewMyClient.html

Note: SSLLabs results may be skewed if a proxy is in use.
But that opens a whole other discussion… relating to the proxy in use.

EDIT:
Actually the allowed ciphers will not match any that Windows Server 2012, nor Windows 7 can handle (Windows 10 should be fine).
They only support GCM with ECDSA (not RSA).
So, you might want to get your hosting provider to include (or switch to) ECDSA ciphers.
Seeing that they already support CHACHA20, their system must support ECDSA with GCM.

1 Like
7

Thank you, I’ll give that a try as well.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.