Windows Server 2016上IIS 10无TLS握手问题技术求助

Hey there, let’s walk through troubleshooting that 443 port issue you’re facing on Windows Server 2016’s IIS 10. You’ve already checked the basics (cert install/chain/binding, 80 works, Wireshark up and running), so let’s dive deeper into the most likely culprits:

Double-Check IIS SSL Binding Details #

Even though you confirmed the binding is successful, it’s worth verifying these easy-to-miss settings:

• Fire up IIS Manager, right-click your default site > Edit Bindings
• For the HTTPS entry, confirm:
  • The IP address is correctly set (avoid "All Unassigned" if you have multiple NICs/IPs—specify the exact one your site uses)
  • Port is definitely set to 443 (no accidental typos here!)
  • The selected SSL certificate is your GoDaddy wildcard cert—cross-check the thumbprint with what’s in Certificates > Local Computer > Personal > Certificates
  • Enable Require Server Name Indication (SNI) if you host multiple sites on the same IP; GoDaddy wildcard certs play nice with SNI

Rule Out Firewall/Network Blockages #

443 being blocked is the #1 suspect here:

• On the server, open Windows Defender Firewall with Advanced Security
• Make sure there’s an inbound rule allowing TCP port 443 for IIS (look for "World Wide Web Services (HTTPS Traffic-In)")
• If your server’s in the cloud (Azure/AWS/GCP), check the associated Network Security Group (NSG)—ensure inbound 443 traffic is allowed from your test source
• Run this Command Prompt command to confirm 443 is listening:

  netstat -ano | findstr ":443"
  

  You should see a line with LISTENING and the PID of w3wp.exe (IIS worker process) or inetinfo.exe. If nothing pops up, the binding isn’t actually active.

Dig Into Your Wireshark Capture #

Since you’re already running Wireshark, filter for HTTPS traffic (tcp.port == 443) and look for these red flags:

• No incoming SYN packets: Traffic isn’t reaching the server—recheck firewall/NSG rules
• SYN sent but no SYN-ACK: The server isn’t listening on 443 (confirm the netstat result above)
• TLS handshake failures: Keep an eye out for Alert (Level: Fatal, Description: ...) messages. Common issues here:
  • Incomplete certificate chain: Even if you thought it was complete, check the Certification Path tab in your cert properties to make sure all intermediate certs are installed in Local Computer > Intermediate Certification Authorities
  • Outdated TLS protocols: If IIS is still using TLS 1.0/1.1, some clients/networks block these. Enable TLS 1.2/1.3:
    1. In IIS Manager, go to Server Certificates > Server Settings
    2. Uncheck TLS 1.0/1.1, check TLS 1.2/1.3
    3. Restart IIS with iisreset in Command Prompt

Reinstall GoDaddy Intermediate Certificates #

GoDaddy wildcard certs rely on specific intermediate certs to build a valid chain. Even if you think they’re installed, reinstalling them can fix hidden issues:

• Grab the GoDaddy intermediate certs for your wildcard cert (you can get these from GoDaddy’s cert download portal)
• Install them into the Local Computer > Intermediate Certification Authorities store
• Restart IIS and retest

Test HTTPS Locally on the Server #

Eliminate external network issues by testing from the server itself:

• Open PowerShell and run:

  Invoke-WebRequest -Uri https://localhost/iisstart.htm -UseBasicParsing
  

  If this works, the problem is external (firewall, DNS, routing). If it fails, the issue is on the server (binding, cert, or IIS config).

Check IIS Logs for Clues #

Head to your IIS logs (usually at C:\inetpub\logs\LogFiles\W3SVC1) and look for HTTPS requests. Status codes like 403, 500, or connection reset entries can point you to exactly what’s failing.

内容的提问来源于stack exchange，提问作者richzilla