DEV Community: Nils Eriksson

TLS Configuration in 2026: What "Secure" Actually Means Now

Nils Eriksson — Wed, 10 Jun 2026 13:04:37 +0000

TLS Configuration in 2026: What "Secure" Actually Means Now

Meta: Having SSL/TLS is not a security posture. The green padlock tells users nothing useful. This article covers what "secure" actually means in 2026: why TLS 1.0 and 1.1 are dead, what TLS 1.3 actually improved, certificate management, cipher suites, HSTS, NIS2 context, and practical nginx/Apache configs.

Keyword: TLS configuration 2026, TLS 1.3 best practices, SSL TLS setup, NIS2 cryptographic requirements

A client showed me their SSL certificate last week. Green padlock. Certificate valid. Expiry date: 2027.

I checked the TLS version their server was advertising: TLS 1.0.

I told them they had a liability, not a security measure.

They looked confused. "But the lock is green," they said.

Yeah. And that's the problem with how most people think about SSL/TLS.

The Green Padlock Is Not Security

Let me be direct: having HTTPS is not a security posture. It's a basic requirement. Like having a front door. A locked front door keeps out opportunistic thieves, but it doesn't stop an intruder who knows the lock is broken.

The green padlock tells users: "The connection to this server is encrypted." That's true. It doesn't tell them:

Whether the encryption is any good
Whether the server is who it claims to be
Whether the site has other vulnerabilities
Whether the cipher suites are modern or ancient

A visitor sees the lock and feels safe. That feeling is mostly marketing.

Your job is to make the lock actually mean something.

TLS 1.0 and 1.1 Are Dead. Stop Running Them.

TLS 1.0 was ratified in 1999. That's 27 years ago. In cryptography terms, it's ancient.

TLS 1.1 came out in 2006. Still ancient.

Both have known attacks. Both are weak. And yet—I still see them in production.

Why they're bad:

TLS 1.0 and 1.1 use MD5 and SHA1 for message authentication, both of which are cryptographically broken.
They don't protect against various padding attacks.
They require cipher suites that modern attackers can break in reasonable time.
Every major browser has deprecated them or is actively phasing them out.

Why people still run them:

Usually legacy. An old device (POS terminal, printer, sensor) only speaks TLS 1.0. So they support it. The device works. Problem solved—until an attacker uses the device as an entry point.

What to do:

Disable TLS 1.0 and 1.1. I don't care if you lose 0.01% of traffic from devices that can't upgrade. That 0.01% is a security liability.

If you have a device that only speaks TLS 1.0, you have two options:

Upgrade the device.
Isolate it on its own connection, not the public internet.

There is no third option where it's acceptable to support TLS 1.0 in 2026.

TLS 1.2: The Status Quo

TLS 1.2 has been around since 2008. It's solid. Still widely used. Still secure if configured correctly.

The keyword is if configured correctly. Because TLS 1.2 is flexible, and flexibility means there are wrong ways to use it.

What can go wrong:

Using CBC ciphers without AEAD (authenticated encryption with associated data).
Supporting cipher suites that use DES, RC4, or other broken ciphers.
Not enforcing perfect forward secrecy (PFS).

The good news: if you're enforcing TLS 1.2 or TLS 1.3 and using modern cipher suites, you're fine. You're not using TLS 1.2 for the coolness factor. You're using it because some people on old systems need it.

TLS 1.3: What Actually Changed

TLS 1.3 shipped in 2018. It's been eight years. Most browsers support it. Most servers support it. If you're not using it, you should be asking why.

What TLS 1.3 improved:

Reduced handshake: TLS 1.2 takes two round trips to establish encryption. TLS 1.3 does it in one. This matters for latency, especially on high-latency connections.
Removed broken ciphers: TLS 1.3 only supports AEAD cipher suites. No more negotiation over broken algorithms. No cipher suite downgrade attacks.
Perfect Forward Secrecy by default: In TLS 1.3, every session gets a unique key. Even if someone steals your private key tomorrow, they can't decrypt past sessions. This should have been default all along.
0-RTT (kind of): You can send data in the initial handshake. This is great for latency. It's also dangerous if misused, but it's there.
Removed renegotiation: TLS 1.2 allowed mid-connection renegotiation, which opened attack vectors. Gone in TLS 1.3.

The practical benefit: TLS 1.3 is faster, more secure, and harder to misconfigure. If you can support it, you should.

Certificates: The Other Half of the Equation

A certificate proves that you own the domain. That's it. It doesn't prove your server is secure. It doesn't prove you're not exfiltrating data. It just proves: yes, this domain belongs to me.

Types of certificates:

Domain Validated (DV): Cheap, easy. The CA checks that you can receive email or modify DNS for the domain. That's all the verification they do. This is fine for most sites. It's what Let's Encrypt issues.
Organization Validated (OV): More expensive. The CA verifies that your organization exists. Browsers display "organization" info. This doesn't make you more secure. Most people don't see it.
Extended Validation (EV): Most expensive. The CA does extensive verification. Browsers used to show a green bar with your company name. That's mostly gone now because users didn't care. Don't bother.

Wildcard certificates: One certificate for multiple subdomains. *.example.com covers api.example.com, cdn.example.com, etc. Be careful with these—if one subdomain is compromised, the attacker has a valid certificate for all of them.

Practical recommendation: Use DV certificates from Let's Encrypt. Free, automated renewal, plenty of entropy. Wildcard if you have lots of subdomains.

Cipher Suites: The Meat of the Config

A cipher suite is the combination of algorithms that TLS uses. In TLS 1.2, you can choose from dozens. In TLS 1.3, the choice is much more limited (in a good way).

For TLS 1.3, use this:

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256

That's it. All three are solid. All three support perfect forward secrecy. Modern browsers support all three.

For TLS 1.2, if you have to:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305

See the ECDHE? That's elliptic curve Diffie-Hellman Ephemeral. The ephemeral part means the key is used once and discarded. That's perfect forward secrecy.

Anything without ECDHE (DHE instead, or no PFS at all) is weaker. Don't use it.

HSTS: Permanent Redirect

HSTS (Strict-Transport-Security) tells the browser: "Always use HTTPS for this domain. No exceptions. Even if the user types HTTP, force HTTPS."

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

What this does:

max-age=31536000 — Remember this for one year (in seconds).
includeSubDomains — Apply to all subdomains.
preload — Include me in the HSTS preload list (a hardcoded list in browsers).

Why it matters:

Without HSTS, an attacker can intercept the initial HTTP request, before the browser gets redirected to HTTPS. HSTS kills that attack—the browser refuses to connect via HTTP at all.

The warning:

Preload is optional but permanent. Once you're in the list, you can't get out quickly. If you enable HSTS with preload and then decide you need to serve some subdomains over HTTP (for legacy stuff), you're stuck. Browsers won't let you.

Only add preload if you're 100% sure you want HTTPS everywhere, forever.

Also: includeSubDomains is risky if you have any subdomain that doesn't support HTTPS. mail.example.com still on HTTP? HSTS will break it.

I've seen companies destroy services by enabling HSTS incorrectly. Get your HTTPS infrastructure solid first. Then enable HSTS.

Certificates: Expiry and Monitoring

Certificates expire. You need to notice before they do.

Why this matters:

When a certificate expires, the browser shows a warning. The user thinks the site is compromised (or just broken). Traffic drops. Users go somewhere else. You miss the outage because nobody tells you.

How to prevent it:

Automated renewal: Let's Encrypt + certbot automatically renews certificates before expiry. Set it and forget it.
Monitoring: Use a service that checks your certificate expiry and alerts you. There are free options (e.g., checking cert transparency logs, using curl to extract certificate dates).
Certificate Transparency: Your certificates are logged in CT logs (by law, in most jurisdictions). You can check what certificates exist for your domain. Unexpected certificate? That's a sign of account compromise.

NIS2 Context

The NIS2 directive (Network and Information Security Directive 2) came into effect for critical infrastructure in late 2024. For most SMBs, it's not directly applicable yet. But it's worth understanding the direction.

NIS2 requires "encryption of data in transit" for critical systems. It doesn't prescribe TLS. But TLS is the de-facto standard. NIS2 expects:

Encryption of data in transit (TLS).
Encryption of data at rest (separate topic, but included).
Regular security assessments.
Incident reporting.

For your purposes: if you're encrypting data in transit with TLS 1.2+ using strong ciphers, you're compliant. If you're running TLS 1.0 or weak ciphers, you're not.

The directive is general enough that it doesn't prescribe specifics. Your security posture matters more than the certificate.

Practical: Nginx Config

Here's a reasonable nginx configuration for 2026:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

    # Certificates (from Let's Encrypt)
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # TLS protocol: 1.2 and 1.3 only
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher suites: strong ciphers first
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;

    # Perfect Forward Secrecy
    ssl_dhparam /etc/ssl/dhparam.pem;
    ssl_ecdh_curve secp384r1;

    # Session settings
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_tickets off;

    # HSTS (be careful with this)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # Other security headers
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "DENY" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Your app config here
    location / {
        proxy_pass http://backend;
    }
}

# Redirect HTTP to HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

Generate dhparam once:

openssl dhparam -out /etc/ssl/dhparam.pem 2048

Practical: Apache Config

For Apache, use this in your VirtualHost or .htaccess:

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

    # TLS protocols
    SSLProtocol TLSv1.2 TLSv1.3

    # Cipher suites
    SSLCipherSuite 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'
    SSLHonorCipherOrder On

    # DH parameters
    SSLOpenSSLConfCmd DHParameters "/etc/ssl/dhparam.pem"

    # Session
    SSLSessionCache "shmcb:logs/ssl_scache(512000)"
    SSLSessionCacheTimeout 300

    # HSTS
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    # Other headers
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "DENY"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Your config here
</VirtualHost>

# Redirect HTTP to HTTPS
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Testing: Verify You Did It Right

Quick command line test:

openssl s_client -connect example.com:443 -tls1_3

Look for:

Protocol: TLSv1.3 (or TLSv1.2 if 1.3 isn't available)
Cipher suite information (should show AES-GCM or ChaCha20-Poly1305)
Certificate info (expiry date, subject)

Web-based test:

Go to SSL Labs by Qualys (https://www.ssllabs.com/ssltest/). Enter your domain. It'll scan your server and grade it. A grade is a rough measure. A's are good. C's and below means you've got problems.

Browser devtools:

Open your site in a browser, hit F12, go to Security tab. It'll show certificate info and any TLS warnings.

The Common Mistakes

Mixing HTTP and HTTPS: You have HTTPS on the main page but load CSS, JavaScript, or images over HTTP. Browsers block this (mixed content). Enable HSTS and keep everything HTTPS.
Not renewing certificates: The certificate expires, users see a warning, you lose traffic. Automate renewal.
Using self-signed certificates in production: They don't prove anything. Use Let's Encrypt.
Setting HSTS too aggressively: If you enable HSTS with preload and then need to rollback, you're stuck for months. Start with max-age=3600 (one hour), test it, then increase.
Supporting too many legacy ciphers: I've seen configs that support RC4 and DES "just in case." They don't need to. Disable them.

The Checklist

Before you deploy:

[ ] TLS 1.2 and 1.3 only. No 1.0, 1.1, or SSL.
[ ] Strong cipher suites with ECDHE or DHE (PFS).
[ ] Certificate from a trusted CA (Let's Encrypt is fine).
[ ] Certificate valid for your domain (no warnings).
[ ] HSTS enabled (but test with short max-age first).
[ ] Automated renewal (certbot for Let's Encrypt).
[ ] Test with SSL Labs (aim for A or A+).
[ ] HTTP redirects to HTTPS.
[ ] No mixed content warnings.

That's security in 2026. Not complicated. Just discipline.

Nils Eriksson is a Stockholm-based security consultant. He writes about web security, bad practices, and the occasional existential crisis caused by production deployments.

Your Web Server Is Leaking: The Security Headers Most Developers Forget

Nils Eriksson — Wed, 10 Jun 2026 13:04:35 +0000

Your Web Server Is Leaking: The Security Headers Most Developers Forget

Meta: Learn the critical HTTP security headers developers skip. CSP, HSTS, X-Frame-Options—what they do, why they matter, and how to implement them. Production checklist included.

Keyword: HTTP security headers checklist, Content-Security-Policy, HSTS, web server security

I walked into a consulting call last week. Nice company, decent traffic, been running for three years. First thing I did: dumped their HTTP headers.

Nothing. Zero security headers. Not even the basics.

The CTO looked at me confused. "Wait, that matters?"

Yeah. It matters. And judging by how often I see this, I'm not the only one cleaning up after this particular oversight. So let's fix it.

Why Headers? Because Browsers Need Rules

Here's the thing most developers don't get: your browser is inherently trusting. It'll run whatever JavaScript you give it. It'll load resources from wherever. It'll let parent pages mess with your iframe. None of that is bad in isolation—it's flexibility. But without guardrails, it's a security disaster.

HTTP security headers are those guardrails. They're instructions you send back with every HTTP response that tell the browser: "Here are the rules for my site. Follow them."

The beauty is they cost nothing. No performance hit. No infrastructure change. Just a few lines of config. And yet somehow, most sites don't have them.

Content-Security-Policy: The Heavyweight Champion

If you only implement one header, make it this one. CSP is the most powerful and most misunderstood security header out there.

What it does: whitelists which sources the browser is allowed to load resources from. Inline scripts? Blocked by default. External stylesheets from random CDNs? Nope. Iframes pointing to sketchy domains? Denied.

Why it matters: if an attacker injects malicious JavaScript into your page (through a vulnerable plugin, a compromised dependency, bad input sanitization—pick one), CSP stops them cold. They can't run their code. They can't exfiltrate data.

The basic policy:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'

Let's break this down:

default-src 'self' — everything comes from your own origin by default
script-src 'self' 'nonce-{random}' — only your own scripts run, plus inline scripts with a nonce (more on that)
style-src 'self' 'unsafe-inline' — this is the compromise line. Ideally, no inline styles, but CSS-in-JS and older frameworks need this
img-src 'self' data: https: — load images from your origin, data URIs, or HTTPS anywhere
connect-src 'self' — XHR/fetch only to your origin (blocks exfiltration)
frame-ancestors 'none' — don't let anyone iframe your site

About nonces: if you need inline scripts (and most modern SPAs do), use a nonce instead of 'unsafe-inline'. Generate a cryptographic random string, include it in your CSP header, and add it to your script tags:

<script nonce="aj5k9s8d7f6">
  console.log('This runs because I have the nonce');
</script>

The nonce should be unique per request. Yeah, it's extra work, but it means you can allow specific inline scripts while blocking injected ones.

Pro tip: start with Content-Security-Policy-Report-Only header first. Same policy, but violations get logged instead of blocked. Let it run for a week, check your logs, fix the issues, then flip to the real header. I've seen too many sites go live with a broken CSP and break half their features.

Strict-Transport-Security: Never Go Back to HTTP

HSTS is simple: tell the browser "always use HTTPS for this domain, no exceptions."

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

What this means:

max-age=31536000 — remember this for one year (in seconds)
includeSubDomains — apply this to ALL subdomains
preload — I want to be in the HSTS preload list (a hardcoded browser list of sites that always use HTTPS)

Why it matters: if someone intercepts the initial HTTP request before they get redirected to HTTPS, an attacker can steal cookies and credentials. HSTS kills that vector—the browser refuses to connect via HTTP at all.

Word of warning: includeSubDomains is essential for security, but it's also a gun pointed at your foot. Every subdomain has to support HTTPS. If you have some ancient mail.yoursite.com still running on HTTP, HSTS will break it. I've seen companies shoot themselves in the foot here. Get your house in order first, then enable HSTS.

Also: preload is optional but good. You're volunteering for a hardcoded list in Chrome, Firefox, Safari, and others. Once you're in, you can't get out quickly—it's essentially permanent. Only do this if you're 100% committed to HTTPS forever.

X-Content-Type-Options: Stop MIME Type Sniffing

One line. That's it.

X-Content-Type-Options: nosniff

What it does: tells browsers "only run files as the MIME type I say they are." Without this, if you serve a file as text/plain that's actually JavaScript, older browsers will sniff it and run it anyway.

This is old-school security theatre by now—modern browsers are smarter. But it costs nothing, so add it.

X-Frame-Options (and frame-ancestors in CSP)

Two ways to say the same thing:

X-Frame-Options: DENY

Or via CSP:

Content-Security-Policy: frame-ancestors 'none'

What it does: tells the browser "don't let anyone embed this page in an iframe." This blocks clickjacking attacks where an attacker overlays a transparent iframe over your login button, tricks users into clicking it, and steals their credentials.

If you DO need to allow certain sites to iframe you:

X-Frame-Options: ALLOW-FROM https://trusted-partner.com

But ALLOW-FROM is deprecated. Use CSP instead:

Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.com

CSP is the modern way. Drop both headers if you're CSP-only, but set both if you want to support older browsers.

Referrer-Policy: Control What You Leak

When you link to another site, browsers send the Referer header (yes, it's a typo from 1994—we're stuck with it). That header includes your full URL, including query parameters.

If your URLs contain sensitive data, that's leaking. Use:

Referrer-Policy: strict-origin-when-cross-origin

What this means: only send the origin (domain) when linking cross-site, send the full URL within your own site. It's the sensible default that doesn't break anything.

Other options:

no-referrer — tell the browser nothing about where we're linking from (might break some analytics)
same-origin — only send referrer for same-site requests
strict-origin — only send the origin, never the full path

I use strict-origin-when-cross-origin as the default. It's protective without being paranoid.

Permissions-Policy: Lock Down Browser APIs

This one's newer, and most developers ignore it. Bad idea.

Permissions-Policy: microphone=(), camera=(), geolocation=(), payment=()

What it does: tells the browser "my page doesn't need these APIs." If a third-party script somehow loads and tries to access your user's microphone, camera, or location, it gets denied.

If you actually need one of these (video calls, location services), be specific:

Permissions-Policy: microphone=(self "https://trusted-service.com"), camera=(self), geolocation=()

This is especially important if you're running third-party ads or embeds. You're not denying the APIs outright; you're denying them to untrusted code.

How to Actually Implement This

Nginx

Drop this in your server block:

server {
    listen 443 ssl http2;
    server_name yoursite.com;

    # TLS config here...

    # Security Headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "DENY" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "microphone=(), camera=(), geolocation=(), payment=()" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'" always;

    location / {
        proxy_pass http://backend;
    }
}

Note the always directive—that ensures headers get sent even on error responses (like 404).

Apache

In your .htaccess or VirtualHost:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "DENY"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "microphone=(), camera=(), geolocation=(), payment=()"
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'"
</IfModule>

Reload your server and you're done.

Testing: Verify You Actually Did It

Open your site in a browser, hit F12, go to the Network tab, click the main page request, and scroll down to Response Headers. You should see all the headers you just added.

For a quick audit, hit securityheaders.com and enter your domain. It'll grade you and tell you what you're missing. It's free and it'll give you a reality check.

The Checklist

Before you deploy, verify:

[ ] Strict-Transport-Security set with includeSubDomains
[ ] X-Content-Type-Options: nosniff
[ ] X-Frame-Options: DENY or CSP frame-ancestors 'none'
[ ] Content-Security-Policy with sensible defaults (start with Report-Only)
[ ] Referrer-Policy set to strict-origin-when-cross-origin or stricter
[ ] Permissions-Policy locks down microphone, camera, geolocation, payment
[ ] Test with securityheaders.com and browser devtools
[ ] Monitor CSP violations if you're using Report-Only

The End

I walked out of that client call with a config file and a promise to check back in a week. Week later, they're running an A rating on securityheaders.com. Their users don't see the difference, but now an attacker would have a much harder time. That's the whole point.

Security headers aren't sexy. They don't ship features. But they're the security equivalent of wearing a seatbelt—cheap, effective, and something you'll regret not doing if something goes wrong.

Go add them. Your future self will thank you.

Nils Eriksson is a Stockholm-based security consultant. He writes about web security, bad practices, and the occasional existential crisis caused by production deployments.