0

A friend of mine (not technical person) moved an API of a web application from azure to liquidweb. Users with FireFox and Edge are able to see the website just fine. But users with Chrome get SSL issues . When I use Chrome to visit the api url https://api.example.com, I noticed that the address bar gave an exclamation mark instead of the usual lock icon. Clicking on the exclamation mark gave the typical Your site connection is not secure message. Again, this is not a problem in FireFox or Edge.

I looked at my friend's IIS settings which are shown here:

enter image description here

And the details of the certificate are all "green icon" except for key usage and basic constraints as shown here

enter image description here enter image description here

I personally have other websites hosted on the bluehost.com shared hosting which uses linux, nginx, and let's encrypt ssl that show the same settings for key usage and basic constraints that don't have the same problem.

What might be wrong with my friend's SSL set up that could be causing issues for Chrome?


ADDITIONAL

Here's what I see in Chrome:

enter image description here

Also, my friend's server uses Windows Server 2016 on build 1607 with IIS version 10.


ADDITIONAL 2

FireFox shows that the Subject Alt Name is the same as the Common name. Screenshot here:

enter image description here


ADDITIONAL 3

Also, here's a verification check from https://sslshopper.com/ssl-checker.html

enter image description here

8
  • can you post exact error message from Chrome?
    – Crypt32
    Mar 18, 2020 at 18:31
  • OK, updated with an image of what's in Chrome and also mentioned server versions. Mar 18, 2020 at 18:38
  • I would check the spelling of web address and if it is resolved to required IP address.
    – Crypt32
    Mar 18, 2020 at 18:40
  • I pinged the api url and it showing the ip address of our liquidweb server. Browsers will show 401, 403 or 404 errors until Authorization headers are sent. Mar 18, 2020 at 18:44
  • Chrome clearly says that it can't reach the address (404). It is something Chrome-related.
    – Crypt32
    Mar 18, 2020 at 18:57

2 Answers 2

0

This is probably because the domain name is not listed in the "Subject Alternative Name" (SAN) field of the certificate, and it's mandatory since Chrome 58 : https://support.google.com/chrome/a/answer/7391219?hl=en

Ensure that the domain name is listed in the Subject Alternative Name, even if the Subject Name is correct.

Or you are using a revoked Let's Encrypt certificate, check here: https://checkhost.unboundtest.com/

4
  • I updated my question to confirm that FireFox shows the Common Name is the same as the Subject Alt Name. Let me know if I made a mistake? Mar 18, 2020 at 18:51
  • 1
    I see that it's a Let's Encrypt certificate, I updated my answer because Let's Encrypt had to revoke a lot of certificates recently
    – Swisstone
    Mar 18, 2020 at 19:21
  • Ok checking now to see Mar 18, 2020 at 19:31
  • I tried the unboundtest.com and it told me The certificate currently available on ......com is OK. It is not one of the certificates affected by the Let's Encrypt CAA rechecking problem. Mar 18, 2020 at 19:53
0

Looks like the following IIS settings resolved my issues:

Go to SSL Settings for your app

enter image description here

Then change the radio option to ignore:

enter image description here

This answer gives more insight into why this works:

https://stackoverflow.com/questions/19383538/what-is-the-difference-between-requiring-an-ssl-cert-and-accepting-an-ssl-cert

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .