My web server is (include version): IIS 10.0.17763.1
The operating system my web server runs on is (include version): Windows 2019
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
I have 4 apps hosted in IIS. website, mail and 2 node apps. They all have individual certs. I also have a node app running on the same server, bound to another IP with its own cert. When I test using the digitcert link it shows me a cert for leylan01.leylan.com which is not even on IIS. It is the cert I use for remote desktop.
So I'm looking for ideas to make sure that anything that contacts video.leylan.com is getting the cert for that subdomain. It is an Express server app if that matters.
Basically, don't use IP specific bindings unless you absolutely understand the impact. The preferred alternative is to use an SNI binding with a hostname set (matching a domain on your certificate) and IP set to All Unassigned or *, which internally maps to 0.0.0.0
In versions of windows prior to Server 2012 you had to add additional IP addresses if you wanted more certs on port 443 because you can only have one IP+Port+cert combination, but this became obsolete as soon as SNI was supported.
Keep in mind also that you can run https on any port as it's more about how the listening service is configured than the actual port used, you just have to remember to prefix the url with https to tell your browser to talk TLS, and include the port e.g. https://<yourdomain>:44300
Thanks, I'm reading about SNI now. I'll probably give that a try. At the moment most things are working but all this effort is for a particular solution I'm trying to implement. And I'm using port 8443 which works and I see the correct certificate.
The problem is this site needs to be accessible to a VRChat world and I haven't been able to find out if they permit (or expressly don't permit) ports other than 443. At the moment my VRChat world cannot connect to my service in native Quest. It does just fine with PCVR. Unfortunately I can't inspect what happens on the Quest at least not easily.
That sounds cool, if you do need to host on port 443 and that would conflict with other things then you either need to move all of your bindings to sni (with hostnames set and IP unset or 0.0.0.0) or add more IP addresses.
Personally I only ever use SNI bindings because most of the machines I manage only have one network IP and generally I'm hosting multiple sites/services per machine.
$ nmap -Pn video.leylan.com
Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-13 14:56 UTC
Nmap scan report for video.leylan.com (199.119.163.189)
Host is up (0.066s latency).
rDNS record for 199.119.163.189: 199-119-163-189.static.fullcontrol.net
Not shown: 703 filtered ports, 296 closed ports
PORT STATE SERVICE
8443/tcp open https-alt
Nmap done: 1 IP address (1 host up) scanned in 3.46 seconds
The chain doesn't contain any intermediate certificates
Report
Hostname: Matches Common Name or/and SAN
Expired: No (82 days till expiration)
Public Key: We were unable to find any issues in the public key of end-entity certificate
Trusted: We were unable to verify this certificate
Self-Signed: No, the end-entity certificate is not self-signed
Chain Issues: The chain doesn't contain any intermediate certificates
Weak signatures: No, certificates sent by the server were not signed utilizing a weak hash function
OCSP Status: OCSP Responder returned "good" status for the end-entity certificate
That's the one I was using due to the IIS issue. I should have that resolved now (I hope) I just haven't switched the service to verify. (edit: okay it uses 443 now so that's progress anyway.)
"We were unable to verify the certificate" sounds like a problem to me. Oh and that report has a OpenSSL Handshake section. Sounds like useful info to have and that there might be an issue.
Could I have a valid certificate "for some purposes" and not enough (like the chain stuff) or whatever for an app that really checked everything?
depth=0 CN = video.leylan.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = video.leylan.com
verify error:num=21:unable to verify the first certificate
verify return:1
Another day, another attempt, another failure... The good news is that I determined (I think) that I hadn't used the full chain pem file. I revised it in my Express app and this time SSL Server Test reported that it trusted my cert. SSL Checker still says it was unable to verify it.
As has been the case... none of this makes sense to me.
If you are talking about the DigiCert SSL Server Test in your first post that still says it is not trusted. And, SSL Checker still says you are sending only the leaf, not the leaf and chain.
I don't know anything about bindings so can't help there. Just wanted to add this.
I accept any and all clues So I've made another adjustment and now the Qualys checker gave me an A rating. The SSL Checker says it trusts it and finds the chain and it is happy with it.
Almost too nervous to check my VR app one more time but I'll have to get up the courage.
If you are referring to the sites I mentioned... there are (at least) two sites that validate a certificate. I just learned about these this week. They report things differently. One seems to summarize and one offers a lot of detail.
There is no mention (that I could easily see) of what constituted the "rules" so if there is a check mark next to "Trusted" I can't tell what it looked for. In any case they are both reporting full compliance at this point.
I know security, SSL and certificates are a very technical subject but due to their importance there really should be an easier way. I'm not dumb (nobody suggested that ) and if it takes me a week or two it is going to stump a lot of people, I think.
Yes, it seems to mean that I have needlessly included the root certificate. It isn't fatal and to my point you will notice that SSL Checker doesn't mention it. I'll pull it tomorrow...
But the big news (for me) is IT WORKS!
That was a whole lot of guesswork trying to find anything that could be causing an issue in the VRChat client. Turns out (as I understand it) that browsers can rectify the issue of not having the cert chain or at least it doesn't complain about it.
Thanks all for any and all clues and suggestions offered.
If you happen to be using Certify The Web for your certificate renewals we did have a bug in our Deploy to Generic Server and Deploy to Apache type tasks where the CA root cert would be included in the default fullchain export. This was fixed in the most recent versions (6.x).
In general nowadays you want to export the full chain as a single file,and the private key as a file, most applications that expect PEM files will accept this and it saves having an extra CA bundle for intermediates.
So I've made another adjustment and now the Qualys checker gave me an A rating. The SSL Checker says it trusts it and finds the chain and it is happy with it.
) and if it takes me a week or two it is going to stump a lot of people, I think.