Certificate & Protocol Analysis
Watch the TLS handshake unfold step by step. Inspect protocol versions, cipher suites, and the full certificate chain. Read the guide.
Every HTTPS connection begins with a TLS handshake. The client and server agree on a protocol version, select a cipher suite, and exchange cryptographic keys. The process completes in milliseconds but determines the security of everything transmitted afterward. TLS 1.3 streamlines this to a single round trip, while TLS 1.2 requires two. For a step by step breakdown, see our TLS handshake guide.
TLS 1.0 and 1.1 have known vulnerabilities (BEAST, POODLE) and are deprecated by all major browsers. TLS 1.2 is secure with strong cipher suites, and TLS 1.3 removes legacy algorithms entirely. If your server still accepts older versions, compliance frameworks like PCI DSS will flag it and browsers may show warnings. Disable TLS 1.0/1.1 and enable TLS 1.3 for the best security and performance.
SSL (Secure Sockets Layer) is the predecessor to TLS (Transport Layer Security). SSL versions 1.0 through 3.0 are all deprecated due to security vulnerabilities. TLS 1.0 was released in 1999 as an upgrade to SSL 3.0, and TLS has continued to evolve through versions 1.1, 1.2, and the current 1.3. When people say "SSL certificate" or "SSL connection" today, they almost always mean TLS. The terms are often used interchangeably, but TLS is the modern, secure protocol.
The process depends on your server software. For Nginx, set ssl_protocols to "TLSv1.2 TLSv1.3" in your server block. For Apache, use SSLProtocol with "all -SSLv3 -TLSv1 -TLSv1.1". For IIS, you can disable older protocols through the Windows Registry or using the IIS Crypto tool. After making changes, restart your web server and use this tool to verify that TLS 1.0 and 1.1 are no longer enabled.
For TLS 1.3, the cipher suites are fixed by the specification and all provide strong security. For TLS 1.2, prefer ECDHE key exchange for forward secrecy, AES-GCM or ChaCha20 for encryption, and SHA-256 or SHA-384 for hashing. Avoid cipher suites that use RSA key exchange (no forward secrecy), CBC mode (vulnerable to padding oracle attacks), RC4, DES, or 3DES. A good starting configuration for Nginx would be "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384".
An incomplete certificate chain means your server is not sending the intermediate CA certificates needed to verify your leaf certificate back to a trusted root. Most browsers can work around this by fetching intermediates on their own, but some clients (mobile apps, API clients, older browsers) cannot. To fix this, download the intermediate certificates from your CA and configure your server to send the full chain. Your CA's documentation will have the specific intermediate certificates you need.
Forward secrecy ensures that if your server's private key is compromised, attackers cannot decrypt previously recorded traffic. With forward secrecy enabled (using ECDHE key exchange), each session generates unique ephemeral keys that are discarded after use. Without it, an attacker could record encrypted traffic today and decrypt everything later if they obtain the private key. Most compliance frameworks require forward secrecy, and all TLS 1.3 cipher suites provide it by default.
You should check your TLS configuration after every server update, certificate renewal, or configuration change. Beyond that, a monthly check is a good baseline. New vulnerabilities in TLS implementations are discovered regularly, and certificate renewals can sometimes reset your configuration. Automated monitoring through the SiteSecurityScore API can alert you to changes in your TLS setup without manual checks.
A strong TLS setup is the foundation, but headers like CSP, HSTS, and Permissions Policy add critical layers of protection. Scan your site to get a complete security score.
Scan your website此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。