Windows Server 2025 / How to Configure HTTPS in IIS and Verify Certificates

IIS HTTPS requires a certificate matching the requested name, its private key on the server, and an HTTPS binding using that certificate. Also verify client trust, validity, revocation conditions, and the certificate actually presented after renewal.

Check the name, key, trust, and binding separately

HTTPS protects web traffic with Transport Layer Security (TLS). The server presents a certificate linking an identity to a public key, while clients validate its name, validity period, and issuing chain. The matching private key must be available on the server.

Using an IP address can fail name matching for a DNS-name certificate. The private .test name is for the lab; real services need names the organization controls and an appropriate certificate authority. IIS HTTPS guidance separates certificate preparation from binding configuration.

Create an isolated test certificate

First verify LabSite and DNS web.lab.example.test → 172.24.50.30. This example uses a self-signed certificate for an isolated, nonpublic test. Clients do not automatically trust it, and the exercise does not replace production issuance and validation.

Run in elevated PowerShell on WEB1 and record the thumbprint. The one-month lifetime is a lab choice; see New-SelfSignedCertificate for test certificates and store options.

$labCertificate = New-SelfSignedCertificate -DnsName 'web.lab.example.test' -CertStoreLocation 'Cert:\LocalMachine\My' -FriendlyName 'LabSite HTTPS test' -NotAfter (Get-Date).AddMonths(1)
$labCertificate | Select-Object Subject,Thumbprint,NotAfter,HasPrivateKey

In certlm.msc → Personal → Certificates, inspect the SAN, expiry, thumbprint, and associated private key. Distinguish certificates with the same friendly name by thumbprint. Record the created item instead of accumulating indistinguishable copies.

Add the HTTPS binding on port 8443

1. In IIS Manager → WEB1 → Server Certificates, refresh and locate the new certificate.
2. Open LabSite → Bindings → Add and select https, IP 172.24.50.30, and port 8443.
3. Enter web.lab.example.test and select Require Server Name Indication.
4. Select LabSite HTTPS test, confirming it corresponds to the recorded thumbprint.
5. Check for duplicate bindings and verify the site state.
6. Create firewall rule Lab-IIS-HTTPS-8443 for Domain profile, inbound TCP 8443, and remote subnet 172.24.50.0/24 only.

Server Name Indication (SNI) lets a client provide the requested name during TLS negotiation. It helps select certificates when sharing an IP and port. Review the binding and SNI attributes. Port 8443 separates this exercise from HTTP 8080; the default HTTPS port is 443.

Verify trust and the actual certificate on CLIENT1

Browse to https://web.lab.example.test:8443/. A warning is expected before CLIENT1 trusts this self-signed certificate. Inspect the presented thumbprint, name, and validity rather than treating bypassed warnings as successful validation.

1. On WEB1, export only the identified certificate as a public .cer without its private key.
2. Transfer it to CLIENT1 through a trusted lab path; do not distribute a PFX containing the private key.
3. Compare its thumbprint with the value recorded on WEB1.
4. Import only this test certificate into Current User → Trusted Root Certification Authorities on isolated CLIENT1. Do not deploy it to production PCs or domain-wide policy.
5. Reopen the browser and verify the same named URL connects without a certificate warning.

Adding a trust-store entry grants trust. Never add an unverified certificate merely to dismiss an error. If validation still fails, inspect SAN, time, expiry, the certificate actually presented, and any additional browser or organizational policy.

Test-NetConnection -ComputerName web.lab.example.test -Port 8443

A successful TCP connection does not validate TLS. Inspect the actual certificate thumbprint and chain in the browser and confirm the expected page content.

Include binding checks in renewal and cleanup

Issuing a replacement into the certificate store does not ensure IIS presents it. Check the new key, names, chain, and expiry, update the binding, and verify the new thumbprint from a separate client. Retain the old certificate until dependencies and rollback needs are understood.

• Assign ownership, renewal method, and failure alerts.
• Allow time for approval, deployment, and validation before expiry.
• Keep required revocation-status paths reachable by clients.
• Monitor binding updates as well as certificate creation when automating renewal.

For cleanup, remove the test HTTPS binding and 8443 rule, then remove only the identified test certificate after checking dependencies. Remove CLIENT1’s added trust entry by its recorded thumbprint. Do not delete other roots or certificates by similar names. Decide separately whether to retain HTTP or implement a verified HTTPS redirect.