The padlock icon in your browser bar tells you almost nothing about the actual security of your TLS configuration. It means a valid certificate was presented and the connection is encrypted. It does not tell you whether the certificate chain is properly configured, whether your server still accepts connections from obsolete TLS versions, or whether mixed content on your page is leaking data over plain HTTP.

I have audited hundreds of sites that proudly display the padlock while running TLS 1.0 alongside their TLS 1.3 configuration, serving incomplete certificate chains that force browsers to fetch intermediate certificates separately, or failing to set HSTS so the first visit is still vulnerable to interception. The padlock is the floor, not the ceiling. Here is what you actually need to get right.

1. Certificate Chain Configuration

Your SSL certificate does not stand alone. It is part of a chain: your server certificate, one or more intermediate certificates, and the root certificate trusted by the browser. Your server needs to send the full chain minus the root (browsers already have root certificates built in).

The most common chain issue I encounter is missing intermediate certificates. When this happens, most desktop browsers will work fine because they cache intermediates or fetch them via the Authority Information Access (AIA) extension. But mobile browsers, API clients, curl, and older systems often fail with a "certificate verify failed" error.

To check your chain, use OpenSSL:

You should see at least two certificates in the output — your server certificate and the intermediate. If you only see one, your chain is incomplete. The fix depends on your CA: download the intermediate certificate bundle from your certificate authority and concatenate it with your server certificate in the correct order (server cert first, then intermediates).

2. Weak Cipher Suites and Protocol Versions

TLS 1.0 and TLS 1.1 were officially deprecated by RFC 8996 in March 2021. If your server still accepts these protocols, you are vulnerable to known attacks like BEAST and POODLE. Every modern browser has dropped support for TLS 1.0 and 1.1, so there is no legitimate reason to keep them enabled.

Beyond protocol versions, the specific cipher suites matter. Avoid anything using RC4, DES, 3DES, MD5, or SHA-1 for message authentication. Prefer cipher suites with forward secrecy (ECDHE or DHE key exchange) so that compromising your server's private key does not decrypt past traffic.

A strong Nginx configuration for 2024 looks like this:

TLS 1.3 further simplifies this because it removed all insecure cipher suites from the specification. If you can require TLS 1.3 only, you eliminate an entire class of cipher-related vulnerabilities. However, TLS 1.2 is still needed for some older but supported clients.

3. HSTS and Preloading

Having HTTPS configured means nothing if users can still reach your site over HTTP. Without HSTS (HTTP Strict Transport Security), the first visit to your site is always over plain HTTP until your server redirects to HTTPS. During that brief window, an attacker on the same network can intercept the request.

The HSTS header forces browsers to use HTTPS for all future requests. But there is still the first-visit problem. HSTS preloading solves this by hardcoding your domain into browsers themselves. To qualify for preloading: set max-age to at least 31536000 (one year), include the includeSubDomains directive, include the preload directive, and make sure every subdomain supports HTTPS.

Submit your domain at hstspreload.org after confirming all requirements. Be careful: getting on the preload list is easy, getting removed takes months. Make absolutely sure all your subdomains support HTTPS before submitting.

4. Mixed Content Issues

Mixed content happens when an HTTPS page loads resources (scripts, stylesheets, images, iframes) over plain HTTP. Active mixed content (scripts, iframes) is blocked by modern browsers entirely. Passive mixed content (images, video) may still load but will trigger warnings.

The sneaky sources of mixed content I find most often: hardcoded http:// URLs in database content (blog posts, CMS pages), third-party widgets that load over HTTP, inline CSS with background-image URLs pointing to HTTP sources, and legacy email templates referencing HTTP image hosts.

Fix mixed content systematically. First, add the upgrade-insecure-requests directive to your CSP:

This tells browsers to automatically rewrite HTTP requests to HTTPS. It is a safety net, not a fix — you should still update all URLs in your code and database to HTTPS, but this catches anything you miss.

5. Certificate Transparency and CAA Records

Certificate Transparency (CT) is a system of public logs where certificate authorities must record every certificate they issue. This means if someone obtains a fraudulent certificate for your domain, it will appear in the CT logs and you can detect it.

Monitor your domains in CT logs using services like crt.sh or Facebook's CT monitoring tool. Set up alerts so you are notified whenever a new certificate is issued for your domain or any subdomain. This catches both malicious certificates and accidental issuance by your own team.

CAA (Certificate Authority Authorization) DNS records specify which CAs are allowed to issue certificates for your domain. Without CAA records, any CA can issue a certificate for your domain:

The first record allows only Let's Encrypt to issue certificates. The second prevents wildcard certificate issuance entirely. The third tells CAs to email you if someone requests a certificate that violates your policy.

6. Certificate Expiry Monitoring

Let's Encrypt certificates expire every 90 days. Even if you have automated renewal set up, things break: cron jobs stop running, DNS validation fails silently, your orchestration platform rotates the pod and loses the certificate. I have seen major production sites go down at 3 AM because a certificate expired and nobody noticed until customers started calling.

Do not rely solely on automated renewal. Set up independent expiry monitoring that checks your certificate from the outside. Test what your users actually see, not what your server thinks it is serving. BlackSight's SSL scanner checks certificate validity, chain completeness, and expiry as part of every scan — configure it to run weekly and you will never be surprised by an expired certificate.

Pro tip: monitor not just your primary domain but every subdomain, every API endpoint, and every service that terminates TLS. The certificate that expires is never the one you are watching.

7. OCSP Stapling

When a browser connects to your site, it needs to verify that your certificate has not been revoked. Without OCSP stapling, the browser contacts the CA's OCSP responder directly, which adds latency, leaks your users' browsing activity to the CA, and fails if the OCSP responder is down.

OCSP stapling moves this check to your server. Your server periodically fetches the OCSP response from the CA and staples it to the TLS handshake. The browser gets proof of non-revocation without contacting any third party.

Enable it in Nginx:

Verify it works with:

Look for "OCSP Response Status: successful" in the output. If you see "OCSP response: no response sent," stapling is not working and you need to debug your resolver configuration or check that your CA supports OCSP.

8. Putting It All Together

A properly configured TLS setup is not just about having a certificate — it is a stack of defenses that work together. Your certificate must have a complete chain. Your server must reject obsolete protocols and weak ciphers. HSTS must be set with a long max-age and ideally preloaded. Mixed content must be eliminated. CAA records must restrict who can issue certificates for your domain. OCSP stapling must be enabled. And certificate expiry must be monitored independently of your renewal automation.

Start by testing your current configuration with BlackSight's SSL scanner or the OpenSSL commands in this article. Fix the most critical issues first: disable TLS 1.0/1.1, complete your certificate chain, and set HSTS. Then work through the remaining items. Each one closes a real attack vector that I regularly see exploited in the wild.