Problems with Secure cert on an IIS 10 server
Hi,
I have a site on IIS 10 on a 2016 server that's been running with a wildcard secure cert. It expired and I renewed it. The secure cert works fine on the web server itself but nowhere else, even a workstation on the same lan pointing to the intranet IP address.
Any suggestions where to look on this one? The site is petcheckalert.com
Other sites with certs work fine on this server.
Thanks!
--Ben
I have a site on IIS 10 on a 2016 server that's been running with a wildcard secure cert. It expired and I renewed it. The secure cert works fine on the web server itself but nowhere else, even a workstation on the same lan pointing to the intranet IP address.
Any suggestions where to look on this one? The site is petcheckalert.com
Other sites with certs work fine on this server.
Thanks!
--Ben
HTTPS is finicky about connections and things that will pass via HTTP won't go with HTTPS.
Consider the case where "www.random.org" is located on 192.168.1.300. A wildcard certificate for "*.random.org" has been issued and installed.
Connecting to https://www.random.org ... works!
Connecting to https://192.168.1.300 ... fails!
In the first case, the connect succeeds because "www.random.org" is in the connect request and the wildcard certificate matches.
In the second case, the connect fails because "192.168.1.300" is in the connect request and the wildcard certificate does not match.
As a side note, that site should prefer HTTPS connections by setting the header
Strict-Transport-Security "max-age=31536000"
as my default connection came up HTTP and did not upgrade.
Finally, the incoming FQDN in the HTTPS initial request must match what the server has been told it is. If the server has been told it is "www.random.org", then it won't respond to "random.org." Under Apache this is handled with ServerName, ServerAlias and UseCanonicalName.
so that the server will respond to all likely incoming FQDNs in an HTTPS request.
Consider the case where "www.random.org" is located on 192.168.1.300. A wildcard certificate for "*.random.org" has been issued and installed.
Connecting to https://www.random.org ... works!
Connecting to https://192.168.1.300 ... fails!
In the first case, the connect succeeds because "www.random.org" is in the connect request and the wildcard certificate matches.
In the second case, the connect fails because "192.168.1.300" is in the connect request and the wildcard certificate does not match.
As a side note, that site should prefer HTTPS connections by setting the header
Strict-Transport-Security "max-age=31536000"
as my default connection came up HTTP and did not upgrade.
Finally, the incoming FQDN in the HTTPS initial request must match what the server has been told it is. If the server has been told it is "www.random.org", then it won't respond to "random.org." Under Apache this is handled with ServerName, ServerAlias and UseCanonicalName.
ServerName random.com:80
ServerAlias random.* www.random.*
UseCanonicalName onso that the server will respond to all likely incoming FQDNs in an HTTPS request.
ASKER
Wow. That's very odd. No, I can't get to it securely from my own lan. Frankly I'd much rather have that problem than the reverse.
I had the domain name mapped to the intranet IP address and it failed. Also failed from my workstation on the same lan using the public IP address.
I had the domain name mapped to the intranet IP address and it failed. Also failed from my workstation on the same lan using the public IP address.
ASKER
Oh, and I do have SNI enabled on this site.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Huh. Http->https redirection -was- working a while back; I'll need to find out what I broke on it. So apparently that was the root cause of this mystery. Never even suspected that.
Sigh.
Thanks to you both for stepping up to this and helping out!
--Ben
Sigh.
Thanks to you both for stepping up to this and helping out!
--Ben
You are most welcome ... It's always the little things that trip me up. :-)
Also, https://www.ssllabs.com/ssltest/analyze.html?d=petcheckalert.com reports you have problems with your HTTPS config.
As a first step, disable TLSv1.0 + TLSv1.1 to ensure visitors see content, rather than a suspicious site warning.
As a first step, disable TLSv1.0 + TLSv1.1 to ensure visitors see content, rather than a suspicious site warning.
ASKER
Whups. I thought I had caught all those. Thanks, David!
--Ben
--Ben
You're welcome!
I'm able to connect from my PC: