Beyond the Padlock: What a TLS Audit Actually Reveals

You visit a website, see the padlock icon in the address bar, and assume you are safe. That assumption is dangerously incomplete. The padlock means your browser established a TLS connection with the server — it confirms encryption is in use. It tells you nothing about which protocol version was negotiated, whether the cipher suite is strong enough to resist modern attacks, whether the certificate chain is properly configured, or whether the server is hardened against known downgrade exploits.

A TLS audit goes far deeper than the binary "encrypted or not" signal. It examines every layer of the TLS handshake and the server's configuration to identify weaknesses that attackers actively exploit. Here is what that audit actually covers.

Protocol Versions Matter

TLS has evolved through several versions, and not all of them are safe to use. TLS 1.0 (1999) and TLS 1.1 (2006) were formally deprecated by RFC 8996 in 2021. TLS 1.2 (2008) is the current baseline, and TLS 1.3 (2018) is the preferred version, offering a faster handshake and a stripped-down set of strong-only cipher suites.

The danger with supporting legacy protocols is not hypothetical. The POODLE attack (2014) exploited a design flaw in SSL 3.0's CBC padding, allowing an attacker on the same network to decrypt sensitive data byte by byte. The BEAST attack (2011) targeted a CBC initialization vector weakness in TLS 1.0, enabling plaintext recovery of HTTP cookies. Both attacks worked by forcing a downgrade — if the server still accepted the old protocol, the attacker could manipulate the handshake to use it instead of a newer, secure version.

Many administrators leave TLS 1.0 and 1.1 enabled because "nothing seems broken." The problem is that these protocols are not broken for normal users — they are broken for attackers, who can silently exploit them. Every major browser has dropped TLS 1.0/1.1 support, so there is no legitimate client that needs them. Disabling legacy protocols costs nothing and eliminates an entire class of downgrade attacks — we explore the full scope of this risk in End-of-Life TLS: The Hidden Risk in Your Domain Configuration.

A proper TLS audit flags any server still accepting TLS 1.0 or 1.1, and it verifies that TLS 1.3 is available as the preferred option.

Cipher Suite Strength

Within a given TLS version, the cipher suite determines the actual cryptographic algorithms used for key exchange, bulk encryption, and message authentication. Not all cipher suites are equal.

Weak ciphers that should never appear in a modern configuration include RC4 (biases in the keystream allow plaintext recovery), 3DES (64-bit block size makes it vulnerable to Sweet32 birthday attacks), and any export-grade cipher (intentionally weakened to 40-bit or 56-bit keys under 1990s US export regulations, trivially crackable today).

Beyond avoiding weak ciphers, a strong configuration requires perfect forward secrecy (PFS). With PFS-enabled key exchanges like ECDHE or DHE, each session generates a unique ephemeral key. If an attacker later compromises the server's long-term private key, they still cannot decrypt previously captured traffic. Without PFS (using plain RSA key exchange, for example), a single key compromise exposes every past session.

The recommended approach for modern servers is to offer only AEAD cipher suites — AES-GCM and ChaCha20-Poly1305 — with ECDHE key exchange. TLS 1.3 enforces this by design, removing all non-PFS and non-AEAD options from the specification. For TLS 1.2, the server must be explicitly configured to prefer these suites and reject legacy options — our TLS protocol and cipher hardening guide walks through the exact configuration for Nginx, Apache, and HAProxy.

The tradeoff is compatibility. A small number of very old clients (Android 4.x, Internet Explorer on Windows XP) cannot negotiate modern cipher suites. In most cases, dropping support for these clients is the correct decision — the security cost of accommodating them is too high.

Certificate Chain and Trust

A TLS certificate does not stand alone. Trust flows through a chain: the leaf certificate (issued to your domain) is signed by an intermediate certificate authority, which is in turn signed by a root certificate authority that browsers and operating systems trust by default.

A surprisingly common misconfiguration is a missing intermediate certificate. The server sends only the leaf certificate, and some clients (particularly mobile browsers and API clients) cannot build the chain to a trusted root. Desktop Chrome may work fine because it caches intermediates from previous connections, masking the problem. The result is intermittent trust failures that are difficult to diagnose.

Expired certificates are a more obvious failure — they break trust entirely and produce a full-page browser warning. But partial expiry matters too. If an intermediate certificate expires before the leaf certificate, the chain breaks even though the leaf itself appears valid.

Certificate Transparency (CT) adds another layer of accountability. CT logs are public, append-only records of every certificate issued by participating CAs. By monitoring CT logs for your domain, you can detect unauthorized certificate issuance — for example, a compromised CA issuing a certificate for your domain to an attacker. A TLS audit checks whether the server's certificate has valid Signed Certificate Timestamps (SCTs) proving CT log inclusion. For a deeper look at managing certificates through their full lifecycle, see our TLS certificate management guide.

HSTS and Preloading

Even with a properly configured TLS server, there is a window of vulnerability on the first visit. If a user types example.com without the https:// prefix, the browser sends an initial HTTP request. An attacker on the network can intercept this request and serve a spoofed HTTP version of the site, stripping the HTTPS upgrade entirely. This is known as an SSL stripping attack.

HTTP Strict Transport Security (HSTS) closes this gap. When a server sends the Strict-Transport-Security header, the browser remembers that the domain must always be accessed over HTTPS. Subsequent visits skip HTTP entirely.

However, HSTS only takes effect after the browser has seen the header at least once — the very first visit is still vulnerable. HSTS preloading eliminates this by including the domain in a list hardcoded into the browser itself. To qualify for the preload list, a domain must serve HSTS with a max-age of at least one year (31536000 seconds) and include the includeSubDomains directive.

A TLS audit checks for the presence and correctness of the HSTS header, flags missing includeSubDomains, verifies adequate max-age values, and notes whether the domain is on the preload list.

CAA Records

Certificate Authority Authorization (CAA) is a DNS record type that specifies which certificate authorities are permitted to issue certificates for a domain. For example, if you only use Let's Encrypt, a CAA record stating 0 issue "letsencrypt.org" tells all other CAs to refuse issuance requests for your domain.

CAA is not a silver bullet — a compromised CA could ignore the record — but all publicly trusted CAs are required to check CAA records before issuance. It is a low-effort, high-value control. Setting up a CAA record takes a single DNS change and prevents a broad class of misissued certificates.

If no CAA record is present, any CA can issue a certificate for your domain. Every domain should have one, even if it lists multiple authorized CAs.

Key Size and Configuration

The cryptographic strength of a certificate depends on its key type and size. RSA keys below 2048 bits are considered weak and should not be used. The industry standard is RSA 2048, with RSA 4096 offering additional margin for long-lived certificates.

ECDSA keys (typically using the P-256 curve) provide equivalent security to RSA 3072 at a fraction of the key size. The smaller key translates directly into faster handshakes and lower bandwidth usage, which matters at scale. Many modern deployments use ECDSA as the primary certificate type with an RSA fallback for legacy clients.

Revocation checking is another configuration concern. Traditional Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) queries add latency and introduce privacy concerns (the CA learns which sites a user visits). OCSP stapling solves this by having the server fetch and cache its own OCSP response, then "staple" it to the TLS handshake. The client gets proof of non-revocation without contacting the CA directly. A well-configured server enables OCSP stapling and refreshes the stapled response before it expires.

What CyberShield's TLS Audit Checks

CyberShield's TLS scan evaluates all of the areas described above in a single automated assessment. It checks supported protocol versions and flags deprecated TLS 1.0/1.1 support. It enumerates accepted cipher suites and identifies weak ciphers, missing forward secrecy, and non-AEAD algorithms. It validates the full certificate chain from leaf to root, checks expiration dates, and verifies CT log inclusion. It inspects HSTS headers for correctness and adequate max-age. It examines key type and size. And it queries DNS for CAA records.

Each finding is classified by severity, so you know which issues to fix first. A missing intermediate certificate and an enabled TLS 1.0 are not the same level of risk, and the report reflects that. To turn these findings into a repeatable process, use our certificate lifecycle management checklist.

The padlock tells you encryption is present. A TLS audit tells you whether that encryption is actually protecting you. If you have not audited your TLS configuration recently, there is a good chance something in this list applies to your servers.