This site does not have a certificate!!!.

Hi, Domic Vo!!!

So, the problem is here???

In SSL certificate, It should say

befancatalogo.personal.corp

We need to make that change???

Thank you

Hello Lucas Peñaloza,

From the screenshots and the certificate details you’ve shared, the issue is not with the certificate itself but with how IIS is binding it to the site. The certificate clearly contains the correct Subject Alternative Names for befancatalogo.personal.corp and the other hostnames, so the SAN coverage is fine. The problem lies in the HTTPS binding configuration.

In IIS, the binding for befancatalogo.personal.corp is set to HTTPS on port 443, but the certificate selected is catalogo.personal.corp. Even though the SAN includes befancatalogo.personal.corp, IIS requires the binding’s hostname to match the certificate subject or SAN exactly. If the binding is not configured with “Require Server Name Indication (SNI)” checked, IIS will not correctly serve the certificate for that hostname, and clients will see the “connection reset” or “not secure” warning.

To fix this, you need to edit the HTTPS binding for befancatalogo.personal.corp and ensure that:

The SSL certificate selected is the one that actually contains befancatalogo.personal.corp in its SAN (which you already have).

The “Require Server Name Indication” option is enabled if multiple hostnames are bound to the same IP/port. Without SNI, IIS will only serve one certificate for all hostnames, which causes mismatches.

After applying, restart IIS (iisreset) to flush the binding cache.

If you are still seeing ERR_CONNECTION_RESET, that usually indicates the TLS handshake is failing. This can happen if the client rejects the certificate because the binding is serving the wrong one, or if there is a mismatch between the hostname requested and the certificate IIS is presenting. Double-check that the binding for befancatalogo.personal.corp is explicitly configured with the correct certificate and that SNI is enabled.

In short: the certificate itself is fine, but IIS is not serving it correctly for the requested hostname. Adjust the HTTPS binding with SNI enabled and the correct certificate, then retest the connection.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.

The browser message means the TLS handshake is failing before a certificate can be presented, even though a certificate is installed in IIS. The issue is typically with how the certificate is bound or trusted, not with the browser itself.

Based on the screenshots and the SAN list, check the following on the web server:

1. Verify the certificate chain and trust
   • Open the bound certificate in MMC → Certificates (Local Computer) → Personal → Certificates.
   • On the Certification Path tab, ensure the chain is complete and shows “This certificate is OK.”
   • If you see CERT_E_UNTRUSTEDROOT (0x800b0109) or similar when validating, import the issuing CA certificate into Trusted Root Certification Authorities on the server (and clients if needed).
   • Also confirm the certificate’s Enhanced Key Usage includes Server Authentication and that Enable all purposes for this certificate is selected, as described in Scenario 2.
2. Confirm the private key is usable
   • If the certificate does not have a private key, or IIS/HTTP.sys cannot access it, the handshake fails and the browser reports that the site has no certificate.
   • Check the System event log for Schannel errors like 36870 with codes 0x80090016 or 0x8009001a. These indicate problems accessing the private key.
   • If present, verify permissions on the MachineKeys folder and, if necessary, back up and replace the certificate with a new one that includes a valid private key, then rebind it to the site.
3. Validate the HTTPS binding and HTTP.sys registration
   • In IIS, the binding screenshot shows https on port 443 with host name befancatalogo.personal.corp and certificate catalogo.personal.corp. That is correct as long as the SAN list includes befancatalogo.personal.corp (which it does).
   • Next, ensure nothing else is listening on port 443:

          netstat -anob
     

     If another process is bound to 443, stop or reconfigure it, or change the site’s SSL port and test again.
   • Check the HTTP.sys SSL configuration:

          netsh http show ssl
     

     For the IP:port used by the site (for example 0.0.0.0:443), confirm there is a non‑empty Certificate Hash (thumbprint of the SSL cert) and a valid Application ID, not {00000000-0000-0000-0000-000000000000}.
     If the hash is blank or the GUID is all zeros, HTTP.sys is not correctly bound to the certificate, and the handshake will fail with “site does not have a certificate.” Recreate the binding in IIS or use netsh http delete sslcert / add sslcert to fix the HTTP.sys listener, then recycle the site.
4. Test with a different certificate
   • As a diagnostic, back up the current certificate, create a temporary self‑signed certificate, bind it to the site, and test HTTPS again.
   • If the site works with the test certificate, the original certificate or its key/chain is corrupted and should be replaced.

Once the certificate is trusted, has a valid private key, and is correctly registered in HTTP.sys for the IP:Port used by the site, the browser will see and validate the certificate instead of reporting that the site does not have one.

References:

• Troubleshooting SSL related issues (Server Certificate)
• SSL Certificate Trust Failure
• Certificate validation fails when a certificate has multiple trusted certification paths to root CAs