Linux: Tips n Tricks: TLS

Showing posts with label TLS. Show all posts

Tuesday, April 14, 2026

Certificate Changes in 2026: My Full Linux Admin Blog Series

A complete series covering TLS basics, DigiCert trust changes, certificate lifetime reductions, and automation for Linux users.

Introduction

Over the past few posts, I have covered the basics of TLS certificates, the DigiCert trust-chain changes affecting older hierarchies, the real certificate validity timeline, and practical automation steps for Linux admins.

Full series

This is a good time for admins to review their live certificate chains, move away from affected old trust paths, and make renewal automation part of normal operations.

My 2026 Certificate Checklist for Linux Admins and Website Owners

Part 6 of 6

A practical 2026 checklist for TLS certificate trust changes, DigiCert chain updates, automation, and monitoring.

Introduction

If you do not want all the background detail and only want the practical action plan, this is the post to save.

2026 is important for two reasons: some older DigiCert trust paths are losing browser trust, and certificate lifetimes are on a path toward becoming much shorter.

The checklist

Start by listing every public HTTPS service you manage. That includes websites, blogs, reverse proxies, APIs, dashboards, VPN portals, and mail-related TLS endpoints.

Next, inspect the live certificate chain for each service. Do not assume that a non-expired certificate means everything is fine.

Then check whether any system still depends on older DigiCert G1-rooted issuance before the April 15, 2026 distrust deadline. Also review whether any affected intermediate or cross-signed certificate components need action before the published May 15, 2026 revocation event.

After that, look for custom trust logic in your environment:

pinned roots
pinned intermediates
bundled CA stores
Java keystores
container images
mobile apps
internal software that assumes a specific trust chain

Then move to renewal automation. If you still renew manually, start testing ACME-based renewal now.

Finally, add monitoring. At a minimum, monitor for:

upcoming expiry
failed renewals
unexpected chain changes
missing intermediates
service reload failures after renewal

Closing thoughts

Certificates used to be something many admins could ignore until close to expiry. That is no longer a good strategy.

The safer approach now is clear: understand the chain, update old trust paths, automate renewal, and monitor the process properly.

Series complete.

How to Automate TLS Certificate Renewals on Linux Before Short Lifetimes Become a Problem

Part 5 of 6

Shorter TLS certificate lifetimes mean manual renewal is no longer enough. Here is how Linux admins can automate renewals safely.

Introduction

Once certificate lifetimes start shrinking, the obvious question becomes: how do we keep up without turning certificate renewals into a monthly headache?

The answer is automation.

Use ACME-based renewal

Most modern certificate automation is built around ACME, the protocol used by tools such as Certbot, acme.sh, and lego.

For many Linux users, Certbot is the easiest starting point. A simple test command is:

sudo certbot renew --dry-run

This is useful because it checks whether your renewal process works before expiry becomes urgent.

Use systemd for automation

# /etc/systemd/system/tls-renew.service
[Unit]
Description=Renew TLS certificates

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet
ExecStartPost=/bin/systemctl reload nginx.service

# /etc/systemd/system/tls-renew.timer
[Unit]
Description=Run TLS renewal twice daily

[Timer]
OnCalendar=*-*-* 03,15:00:00
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

This pattern is useful because renewal becomes automatic, Nginx reloads after successful renewal, the timer spreads load with a random delay, and the system keeps working after reboots because the timer is persistent.

Choose the right validation method

HTTP-01 is often easiest for standard websites.

DNS-01 is usually needed for wildcard certificates and more complex environments.

The important mindset change is this: do not treat certificate renewal like a note on your calendar. Treat it like a routine automated operating task.

Closing thoughts

The admins who automate early will handle future certificate lifetime reductions much more easily than the ones still renewing by hand.

Are TLS Certificate Lifetimes Really Dropping to One Month? Here Is the Real Timeline

Part 4 of 6

People keep saying certificate validity is dropping from one year to one month. Here is the real public TLS timeline and what it means.

Introduction

I keep hearing the same claim: certificate validity is going from one year to one month. That is not the full story.

The real change is more gradual, but it is still a big operational shift.

The actual timeline

Before March 15, 2026: maximum validity is 398 days
From March 15, 2026: maximum validity becomes 200 days
From March 15, 2027: maximum validity becomes 100 days
From March 15, 2029: maximum validity becomes 47 days

So no, the industry is not jumping straight from one year to one month tomorrow.

Why shorter lifetimes are happening

The long-term direction is very clear: certificates will live for much shorter periods than many admins are used to.

Why is this happening? Because shorter lifetimes reduce risk. If a certificate is misissued, or a private key is compromised, or validation data becomes stale, a shorter lifetime reduces how long that problem can remain active.

What this means for Linux admins

For Linux admins and small website owners, the practical message is easy to understand:

Manual renewal might still work today. But it will become less practical every year.

Closing thoughts

The “one month” wording is not correct as an immediate change, but the bigger message is true: the future of public TLS is shorter-lived certificates and more frequent renewal.

How to Check If Your Linux Server Uses an Affected DigiCert Certificate Chain

Part 3 of 6

A practical Linux guide to inspecting TLS certificate chains with OpenSSL before DigiCert trust changes cause browser errors.

Introduction

Once you know that browser trust changes are coming, the next question is obvious: how do you check whether your own server is affected?

The good news is that Linux gives you simple tools for this. One of the easiest ways is to inspect the live TLS chain with OpenSSL.

Basic OpenSSL check

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

This shows the certificate chain presented by the remote server.

Save and inspect each certificate

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/{i++} {print > ("cert-" i ".pem")}'

for f in cert-*.pem; do
  echo "==== $f ===="
  openssl x509 -in "$f" -noout -subject -issuer -dates
done

This helps you review each certificate in the chain and see who issued it, who it belongs to, when it starts and ends, and whether the issuer looks like an old or current DigiCert hierarchy.

Also check your web server configuration

For Nginx, the certificate file usually needs to contain the leaf certificate followed by the required intermediate certificates in the correct order.

You should also ask yourself a few questions:

Do we pin roots or intermediates anywhere?
Do we use Java keystores or custom trust stores?
Do we have containers, appliances, or internal services that assume a certain chain?

If you find that your server is still presenting an older path, the usual fix is to reissue or renew the certificate onto a supported hierarchy and then test the new chain before rolling it out.

Closing thoughts

A live certificate check takes only a few minutes, but it can save you from a very confusing browser outage later.

Why Mozilla and Chrome Are Distrusting Some Older DigiCert Certificate Chains

Part 2 of 6

Older DigiCert certificate chains are losing browser trust in 2026. Here is what is changing, who is affected, and why it matters.

Introduction

You may have heard people saying that Mozilla is no longer trusting old DigiCert certificates. That statement is directionally true, but it needs more detail.

The issue is not that DigiCert as a whole is being distrusted. The real issue is that some older DigiCert G1 root hierarchies are reaching the point where browsers will no longer trust affected TLS chains.

What is changing?

According to DigiCert, Chrome and Mozilla Firefox will stop trusting active TLS end-entity certificates chaining to certain older DigiCert G1 roots on April 15, 2026.

The affected older roots include:

DigiCert Assured ID Root CA
DigiCert Global Root CA
DigiCert High Assurance EV Root CA

This matters because a certificate can still look perfectly fine from an expiry-date point of view and still fail in modern browsers if the trust chain behind it is no longer accepted.

Who is most likely to be affected?

DigiCert moved default public TLS issuance to newer hierarchies in March 2023, so many customers may already be fine. The environments most likely to need attention are the ones that still use older issuance paths, pin specific intermediates or roots, maintain private or custom trust stores, or hard-code trust assumptions into software, appliances, or containers.

There is also another important date. DigiCert has published revocation plans for several G2 and G3 intermediates, plus two G5 cross-signed roots, for May 15, 2026. If a system still depends on one of those components, certificate validation can fail even if the leaf certificate itself is still within date.

What this really means

Do not only check whether your certificate is expired. Check whether the full chain behind it is still trusted.

TLS Certificates Explained Simply: A Beginner-Friendly Guide for Linux Users

Part 1 of 6

A simple guide to TLS certificates, certificate chains, root CAs, and intermediates for Linux users, website owners, and beginners.

Introduction

If you run a blog, website, reverse proxy, API, mail server, or admin panel, you are already depending on TLS certificates. Many people use them every day without fully understanding how they work. That is normal. But with browser trust changes and shorter certificate lifetimes becoming more important, this is a good time to learn the basics.

When a visitor opens your site over HTTPS, their browser checks a few things. It checks whether the certificate matches the domain name, whether the certificate is still valid by date, and whether it chains back to a trusted root CA.

What is a certificate chain?

A simple way to think about it is this:

The leaf certificate is the certificate installed on your website or server.
The intermediate certificate is the certificate that issued your server certificate.
The root certificate is the trust anchor already stored in the browser or operating system.

The root certificate is usually not something you install on your web server. The browser or operating system already has it in its trust store. What your server usually needs is the correct server certificate and the correct intermediate certificate.

Why certificate problems happen

Certificate errors are not always caused by expiry. A site can break because the intermediate certificate is missing, the chain is incomplete, the browser no longer trusts the root behind the chain, or the wrong certificate files were installed on the server.

For Linux users, the important lesson is simple: a TLS certificate is not just one file. It is part of a trust chain, and that full chain matters.

Closing thoughts

If you have ever wondered why one browser says a site is secure while another complains, the answer is often somewhere in the certificate chain.

Thursday, September 28, 2023

Depricated SSL/TLS Protocols and Ciphers you should not use

As cybersecurity threats evolve, older SSL/TLS protocols and ciphers that were once considered secure have become deprecated due to vulnerabilities and weaknesses. Here are some of the deprecated SSL/TLS protocols and ciphers:

Deprecated SSL/TLS Protocols:

1. SSLv2: SSL version 2 is highly insecure and has numerous vulnerabilities, including susceptibility to various attacks like the BEAST attack. It's considered completely obsolete and should not be used.

2. SSLv3: SSL version 3 is also deprecated due to vulnerabilities like POODLE (Padding Oracle On Downgraded Legacy Encryption). It's no longer considered secure.

3. TLS 1.0: TLS 1.0 is deprecated because it's vulnerable to attacks like BEAST and POODLE. It lacks some modern security features found in newer TLS versions.

4. TLS 1.1: TLS 1.1 is considered weak and is also deprecated in many security-conscious environments.

Deprecated SSL/TLS Cipher Suites:

1. RC4: The RC4 cipher is deprecated due to multiple vulnerabilities, including biases that allow for practical attacks. It's recommended to avoid using RC4 in favor of stronger ciphers like AES.

2. DES (Data Encryption Standard): DES is considered weak due to its small key size, making it vulnerable to brute-force attacks. It's deprecated in favor of stronger encryption algorithms.

3. 3DES (Triple Data Encryption Standard): While 3DES was once considered secure, its key length and vulnerability to certain attacks make it deprecated in favor of more robust encryption algorithms.

4. EXPORT Cipher Suites: These cipher suites were designed to comply with export restrictions on encryption technology in the 1990s. They have extremely weak key lengths and are deprecated.

5. NULL Cipher Suites: These cipher suites provide no encryption, making data transmission completely insecure. They should never be used.

6. Anon Cipher Suites: Anonymous cipher suites don't require the server to present a digital certificate, making them susceptible to man-in-the-middle attacks. They are deprecated for security reasons.

7. Cipher Suites with Weak Key Lengths: Cipher suites with key lengths less than 128 bits (e.g., 40-bit or 56-bit keys) are deprecated due to their vulnerability to brute-force attacks.

It's crucial to keep your SSL/TLS configurations up to date and avoid using deprecated protocols and ciphers to maintain a high level of security for your web services. Most modern web browsers and servers have deprecated these older protocols and ciphers as well, and it's essential to configure your systems to use only strong, secure options to protect against potential security threats.

TLS/SSL Cipher Suites and TLS handshake process

The foundation of secure communication on the internet relies heavily on TLS/SSL cipher suites. These suites dictate the algorithms used to encrypt and decrypt data, ensuring that sensitive information remains private and protected. In this article, we'll delve into the world of TLS/SSL cipher suites, examining how they work, their components, and their importance in establishing secure connections.

Understanding TLS/SSL Cipher Suites

A cipher suite is a combination of cryptographic algorithms that determine how data is secured during transmission over a network. Each TLS/SSL connection negotiates a cipher suite, allowing both the client and the server to agree on the encryption and authentication methods to be used. A typical cipher suite consists of several components:

1. Key Exchange Algorithm: This component is responsible for securely exchanging encryption keys between the client and server. Common key exchange methods include Diffie-Hellman (DHE), Elliptic Curve Diffie-Hellman (ECDHE), and RSA.

2. Authentication Algorithm: This algorithm verifies the authenticity of the server's digital certificate. The most widely used authentication method is RSA, although ECDSA (Elliptic Curve Digital Signature Algorithm) is gaining popularity.

3. Symmetric Encryption Algorithm: Symmetric encryption relies on a single shared key for both encryption and decryption. Common symmetric encryption algorithms include AES (Advanced Encryption Standard), 3DES (Triple Data Encryption Standard), and RC4 (Rivest Cipher 4).

4. Message Authentication Code (MAC) Algorithm: MAC algorithms ensure message integrity by verifying that data has not been tampered with during transmission. HMAC (Hash-based Message Authentication Code) is a popular choice.

5. Hash Function: Hash functions are used for various purposes, such as generating digital signatures and verifying the integrity of transmitted data. Common hash functions include SHA-256 (Secure Hash Algorithm 256-bit) and SHA-384.

The TLS Handshake Process

To establish a secure connection using a specific cipher suite, the TLS handshake process takes place:

1. ClientHello: The client initiates the connection by sending a "ClientHello" message to the server. This message includes information about the cipher suites it supports.

2. ServerHello: The server responds with a "ServerHello" message, selecting a cipher suite from the list provided by the client.

3. Key Exchange: If necessary (as determined by the chosen cipher suite), the client and server exchange key information securely.

4. Certificate Verification: The server presents its digital certificate to the client for verification. The client checks the certificate's authenticity using its list of trusted Certificate Authorities (CAs).

5. Session Key Generation: Both the client and server use the exchanged key information to derive a session key, which will be used for symmetric encryption.

6. Finished: Finally, both parties exchange "Finished" messages to confirm that the handshake was successful. Subsequent data is encrypted and decrypted using the derived session key.

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy is a property of certain key exchange methods (such as DHE and ECDHE) that ensures that even if an attacker obtains the long-term private key, they cannot decrypt past communications encrypted with session keys. This enhances security and privacy.

Choosing the Right Cipher Suite

The choice of cipher suite is essential for security. It depends on factors like the sensitivity of the data being transmitted, the server's security configuration, and performance considerations. Strong, up-to-date cipher suites are recommended to ensure the highest level of security.

TLS Cipher Suites

Cipher Suite	Key Exchange Algorithm	Authentication Algorithm	Symmetric Encryption Algorithm	MAC Algorithm	Hash Function
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	ECDHE	RSA	AES-256-GCM	HMAC-SHA384	SHA-384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	ECDHE	RSA	AES-128-GCM	HMAC-SHA256	SHA-256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384	DHE	RSA	AES-256-GCM	HMAC-SHA384	SHA-384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256	DHE	RSA	AES-128-GCM	HMAC-SHA256	SHA-256
TLS_RSA_WITH_AES_256_GCM_SHA384	RSA	RSA	AES-256-GCM	HMAC-SHA384	SHA-384
TLS_RSA_WITH_AES_128_GCM_SHA256	RSA	RSA	AES-128-GCM	HMAC-SHA256	SHA-256
TLS_RSA_WITH_AES_256_CBC_SHA256	RSA	RSA	AES-256-CBC	HMAC-SHA256	SHA-256
TLS_RSA_WITH_AES_128_CBC_SHA256	RSA	RSA	AES-128-CBC	HMAC-SHA256	SHA-256
TLS_RSA_WITH_AES_256_CBC_SHA	RSA	RSA	AES-256-CBC	HMAC-SHA1	SHA-1
TLS_RSA_WITH_AES_128_CBC_SHA	RSA	RSA	AES-128-CBC	HMAC-SHA1	SHA-1
TLS_RSA_WITH_3DES_EDE_CBC_SHA	RSA	RSA	3DES-EDE-CBC	HMAC-SHA1	SHA-1
TLS_RSA_WITH_RC4_128_SHA	RSA	RSA	RC4 (128-bit)	HMAC-SHA1	SHA-1

Please note that this table includes various combinations of key exchange, authentication, and encryption algorithms. The choice of cipher suite depends on factors like security requirements, server and client compatibility, and performance considerations. Additionally, it's crucial to stay updated with the latest security standards and recommendations when configuring TLS cipher suites for your web services.

TLS/SSL cipher suites are the building blocks of secure communication on the internet. By defining the encryption, authentication, and key exchange methods used during the TLS handshake, cipher suites enable secure data transmission and protect users from eavesdropping and data tampering.

SSL/TLS Certificate Chain Validation in HTTPS

The use of SSL/TLS (Secure Sockets Layer/Transport Layer Security) encryption is fundamental to the security of internet communication. When you connect to an HTTPS website, your browser engages in a complex process of validating SSL/TLS certificates to ensure secure and trustworthy data transfer. In this article, we'll unravel the mystery behind SSL/TLS certificate chain validation and how it works to secure your online interactions.

The Importance of SSL/TLS Certificates

SSL/TLS certificates play a pivotal role in the encryption and authentication of data transmitted over the web. They provide three essential functions:

Encryption: Certificates facilitate the encryption of data between your browser and the web server, ensuring that any intercepted data remains unreadable.
Authentication: Certificates verify the identity of the website you're connecting to. This prevents attackers from impersonating legitimate websites.
Integrity: Certificates ensure that data exchanged between your browser and the web server hasn't been tampered with during transit.

The SSL/TLS Certificate Chain

The SSL/TLS certificate chain is a hierarchical structure comprising multiple certificates that establish trust between your browser and the website's server. Here's how it typically works:

Root Certificate Authority (CA):

At the top of the chain is the Root CA certificate. These are well-known and trusted entities, like VeriSign or Let's Encrypt, that issue certificates.
Your operating system or browser comes pre-installed with a list of trusted root CAs.

Intermediate Certificate Authorities:

Below the root CA are intermediate CAs. These CAs are also trusted but are used by the root CAs to issue certificates.
The website owner obtains a certificate from one of these intermediates, not directly from the root CA.

Server Certificate:

The website's server certificate, also known as the end-entity certificate, is signed by one of the intermediate CAs.
This certificate contains the server's public key and its hostname.

Certificate Chain Validation Process

When you connect to an HTTPS website, your browser performs the following steps to validate the certificate chain:

Receipt of Server Certificate:

The server sends its certificate to your browser when you initiate an HTTPS connection.

Validation of Signature:

Your browser checks the signature on the server's certificate. It uses the public key of the issuer (an intermediate CA) to verify the signature.
If the signature is valid, the server's certificate is considered trustworthy so far.

Issuer Verification:

Your browser checks if the issuer of the server certificate (the intermediate CA) is in its list of trusted CAs. This is where the chain begins.

Validation of Intermediate Certificate:

Your browser proceeds to validate the intermediate certificate using the same process as the server certificate.
It checks the signature and verifies that the intermediate CA is trusted.

Repeat Process for Root CA:

The process continues until your browser reaches a root CA certificate. This final certificate must be in your browser's trusted list.
If the root CA certificate is trusted, the entire certificate chain is validated.

Hostname Verification:

Your browser also checks if the hostname in the server certificate matches the hostname you're trying to access. This prevents man-in-the-middle attacks.

Encryption Key Exchange:

If all steps pass, your browser and the server exchange encryption keys, and secure communication begins.

SSL/TLS certificate chain validation is a complex but essential process that ensures the authenticity and security of HTTPS websites. By verifying each certificate in the chain, starting from the server certificate and ending with a trusted root CA, your browser establishes trust and encrypts data for secure communication.