I used one of the helper apps someone put together to install a certificate on my IIS 8.0 platform and everything works great in all web browsers with the exception of my Samsung S5 running Android Lollipop. When my phone is connected to the Verizon network I get the following error in Google Chrome ERR_SSL_PROTOCOL_ERROR Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don’t have. I tried using the Dolphin HD browser on my phone and it is also unable to connect though it does not give me as much information as Chrome Mobile does.
As soon as I connect to an xfinitywifi hotspot or any other wifi hotspot it works perfectly and I can connect to my website through HTTPS.
Some other notes from what I have tried.
I can connect to my site just fine from a computer that is using a Verizon FiOS business connection.
I enabled the wifi hotspot on my phone, and connected to it from a different computer. That computer is ALSO unable to connect to my site VIA HTTPS when on my hotspot connection.
I borrowed a co-workers Sprint Samsung S6 with all the latest updates and his phone cannot connect as well.
I checked my APN settings for a proxy server entry. I only have one APN and all of the settings are disabled, but the proxy server setting shows “Not Set”. So, I don’t believe there is a proxy.
My phone has the following certificate in the System store and it is enabled. “Digital Signature Trust Co.” DST Root CA X3
My phone is running the following version of Android LRX21T.G900VVRU2BOG5. Is there a way in IIS to specify what outgoing ports the secure connection should use after the connection is established on 443? I know with the FTP server this can be done, not sure about the web server.
I’m open to any and all advice as I really want to get some sort of secure service on my webserver but it just does not play nice with my phone and that is a critical aspect for me.
The ‘B’ rating is because the server supports weak Diffie-Hellman (DH) key exchange parameters (which could be related to your issue if for some reason verizon blocks those - I’ve no idea if they do though).
Your site also fails for me over Verizon LTE from an iOS 9.2 iPad using Safari. Error is generic with no indication of cause. Works over wi-fi. The non-https version works on both.
My personal site using a let’s encrypt cert works over Verizon LTE. It’s hosted on Linux running NGINX.
Thanks. I’m at a complete loss as to the cause. I’ve since locked down more of the ciphers so my site now gets an A rating. No change in behavior though.
If you want to compare, my site is www.vanhaaren.net, I currently get an A-.
However running ssl labs on your site I notice there appears to be 2 servers. One at an IPv6 IP address that does not support SSL and one on a IPv4 IP address that does. I’m guessing verizon wireless is directing to the IPv6 site?
Oh yes, I also confirmed that your site does work over T-Mobile LTE.
Oh that’s because I enabled http/2 and have been screwing around with it but I’m having problems getting a set of ciphers that work with both chrome and safari for some reason. I disabled http2 again. should work for you now.
No, I have one ECDHE cipher specified while trying to nail down the issue i’ve been messing with. But Chrome doesn’t like the other ciphers in my list.
I have a problem with safari working with SSL and PHP (over fastcgi) if I disable TLSv1 or don’t have non-FS AES certs in my ciphers list. But if even if I have ECDHE ciphers listed, if I have the AES certs in my cipher list and http2 enabled then Chrome throws that SPDY error about blacklisted ciphers.
Even using the Mozilla recommended latest cipher listing doesn’t seem to fix it. I’m pretty sure it’s something in php/fastcgi/openssl that just isn’t right for me causing the Safari issue. The SPDY problem was just a side issue. I disabled http2 again.
HTTPS started working today! I’m not exactly sure why as I didn’t change anything else on my end, but it’s,working great now. Thanks Kevin! I think Verizon was trying to use the IPV6 DNS record instead of the IPV4. Maybe it took a lot longer for their DNS to update.