Linux: Tips n Tricks

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.

Friday, November 3, 2023

Migrate Redis to OCI Cache on Redis

You can migrate your Redis DB to OCI Cache on Redis using the following steps.

You need to use a data dump tools such as pyredis-dump for getting serialised dump from your Redis DB.

This tool can be used to take a serialised dump from any Redis node running in any cloud environments like AWS ElastiCache. So far, we are testing only single master Redis cluster.

[root@jay ~]# git clone https://github.com/tkote/pyredis-dump.git

Cloning into 'pyredis-dump'...

remote: Enumerating objects: 51, done.

remote: Counting objects: 100% (40/40), done.

remote: Compressing objects: 100% (23/23), done.

remote: Total 51 (delta 22), reused 28 (delta 17), pack-reused 11

Receiving objects: 100% (51/51), 15.89 KiB | 15.89 MiB/s, done.

Resolving deltas: 100% (22/22), done.

[root@jay ~]#

Using pyredis-dump, you can create a backup of your dataset from OCI Redis as well for safe keeping of your data.

You can use the backup you have taken to move the Redis node to a different Redis node in another region/VCN as per your requirement.

The pyredis-dump has the following options:

[root@jay pyredis-dump]# python3 pyredis-dump.py -h

Usage: pyredis-dump.py [options] dump|restore|dblist

Options:

-h, --help show this help message and exit

-H HOST, --host=HOST connect to HOST (default localhost)

-P PORT, --port=PORT connect to PORT (default 6379)

-s SOCKET, --socket=SOCKET

connect to SOCKET

-d DB, --db=DB database

-w PASSWORD, --password=PASSWORD

connect with PASSWORD

-p PATTERN, --pattern=PATTERN

pattern

-o OUTFILE, --outfile=OUTFILE

write to OUTFILE

-i INFILE, --infile=INFILE

read from INFILE

-t use ttl when in restore mode

-b BULK, --bulk=BULK dump/restore bulk size

-S, --ssl use tls connection

-k, --watch watch key value change while dumping

[root@jay pyredis-dump]#

Take a serialised backup of the Redis.

Syntax:

# python3 pyredis-dump.py <Options> -H <Hostname/IP> dump -o /path/to/backupfile

[root@jay pyredis-dump]# python3 pyredis-dump.py -S -H amaaaaaa2ne4d2aaxhlt47oluwtlrvualroXXocvb3xmg546a-p.redis.eu-frankfurt-1.oci.oraclecloud.com dump -o /opt/redisdump/rdump1

dumping to '/opt/redisdump/rdump1'

connecting to {'db': 0, 'host': amaaaaaa2ne4d2aaxhlt47oluwtlrvualroXXocvb3xmg546a-p.redis.eu-frankfurt-1.oci.oraclecloud.com', 'port': 6379, 'ssl': True}

5 keys, bulk_size: 1000, watch_keys: False

dumped 5 records

elapsed time: 0.029 seconds

[root@jay pyredis-dump]#

Here we have taken a backup of the OCI Redis cluster. However, you may run the same command to take backup of any Redis clusters in any environments.

In the above command, we used the option ‘-S’ as we are connecting to an OCI Redis cluster and it mandates secure TLS connection. For your Redis environment you might not need to use this option.

The pyredis-dump command creates a dump file in the path you specified. The time it takes to create a dump depends on your data size.

Once you get the dump file, you can move it to the location or an OCI instance from which you can access your new OCI Redis cluster.

Restore to OCI Redis Cache

You may use the following command to restore the data to the new cluster.

Syntax:

# python3 pyredis-dump.py <Options> -H <Hostname/IP> restore -i /path/of/backup

[root@jay pyredis-dump]# python3 pyredis-dump.py -S -H amaaaaaa2ne4d2aaxhlt4XXXrvualrociwb3xmg546a-p.redis.eu-frankfurt-1.oci.oraclecloud.com restore -i /opt/redisdump/rdump1

restore from '/opt/redisdump/rdump1'

connecting to {'db': 0, 'host': amaaaaaa2ne4d2aaxhlt4XXXrvualrociwb3xmg546a-p.redis.eu-frankfurt-1.oci.oraclecloud.com', 'port': 6379, 'ssl': True}

restored 5 records

elapsed time: 0.022 seconds

[root@jay pyredis-dump]#

Some catches:

If you get the following error when using pyredis-dump, install redis for python.

[root@jay pyredis-dump]# python3 pyredis-dump.py -h

Traceback (most recent call last):

File "pyredis-dump.py", line 7, in <module>

from redis import StrictRedis as Redis

ModuleNotFoundError: No module named 'redis'

[root@jay pyredis-dump]#

Install redis in python using pip3.

[root@jay pyredis-dump]# pip3 install redis

WARNING: Running pip install with root privileges is generally not a good idea. Try `pip3 install --user` instead.

Collecting redis

Downloading https://files.pythonhosted.org/packages/d6/f6/19237b28c632935c7359bddf703395ba13bbd134fc5e2eb297c4c120398c/redis-4.3.6-py3-none-any.whl (248kB)

100% |████████████████████████████████| 256kB 5.7MB/s

Collecting importlib-metadata>=1.0; python_version < "3.8" (from redis)

Downloading https://files.pythonhosted.org/packages/a0/a1/b153a0a4caf7a7e3f15c2cd56c7702e2cf3d89b1b359d1f1c5e59d68f4ce/importlib_metadata-4.8.3-py3-none-any.whl

Collecting async-timeout>=4.0.2 (from redis)

Downloading https://files.pythonhosted.org/packages/d6/c1/8991e7c5385b897b8c020cdaad718c5b087a6626d1d11a23e1ea87e325a7/async_timeout-4.0.2-py3-none-any.whl

Collecting packaging>=20.4 (from redis)

Downloading https://files.pythonhosted.org/packages/05/8e/8de486cbd03baba4deef4142bd643a3e7bbe954a784dc1bb17142572d127/packaging-21.3-py3-none-any.whl (40kB)

100% |████████████████████████████████| 40kB 11.4MB/s

Collecting typing-extensions; python_version < "3.8" (from redis)

Downloading https://files.pythonhosted.org/packages/45/6b/44f7f8f1e110027cf88956b59f2fad776cca7e1704396d043f89effd3a0e/typing_extensions-4.1.1-py3-none-any.whl

Collecting zipp>=0.5 (from importlib-metadata>=1.0; python_version < "3.8"->redis)

Downloading https://files.pythonhosted.org/packages/bd/df/d4a4974a3e3957fd1c1fa3082366d7fff6e428ddb55f074bf64876f8e8ad/zipp-3.6.0-py3-none-any.whl

Requirement already satisfied: pyparsing!=3.0.5,>=2.0.2 in /usr/lib/python3.6/site-packages (from packaging>=20.4->redis)

Installing collected packages: zipp, typing-extensions, importlib-metadata, async-timeout, packaging, redis

Successfully installed async-timeout-4.0.2 importlib-metadata-4.8.3 packaging-21.3 redis-4.3.6 typing-extensions-4.1.1 zipp-3.6.0

[root@jay pyredis-dump]#

If you get a ConnectionError exception as follows, its mostly due to OCI Redis cache needing a secure TLS connection.

Error: redis.exceptions.ConnectionError: Error while reading from <Hostname>:6379 (104, 'Connection reset by peer')

[root@jay pyredis-dump]# python3 pyredis-dump.py -H amaaaaaa2ne4d2aaxhlt47xxxktdy77fovocvb3xmg546a-p.redis.eu-frankfurt-1.oci.oraclecloud.com dump -o rdump1

dumping to 'rdump1'

connecting to {'db': 0, 'host': amaaaaaa2ne4d2aaxhlt47xxxktdy77fovocvb3xmg546a-p.redis.eu-frankfurt-1.oci.oraclecloud.com', 'port': 6379, 'ssl': None}

[..]

redis.exceptions.ConnectionError: Error while reading from amaaaaaa2ne4d2aaxhlt47xxxktdy77fovocvb3xmg546a-p.redis.eu-frankfurt-1.oci.oraclecloud.com:6379 : (104, 'Connection reset by peer')

[root@jay pyredis-dump]#

OCI Redis cache requires secure TLS connection. The pyredis-dump supports TLS connection using switch ‘-S’. Use this option to the connection string.

Friday, October 27, 2023

How to connect to OCI Redis cluster

Redis is a private service and accessible only within the VCN or appropriately peered VCNs.

You can connect to the OCI Redis Clusters using the cluster endpoints provided.

To write to the redis cluster, connect using the Primary endpoint.

To read from the redis cluster, connect using the Replica endpoint.

You may choose a client library your programming language supports to connect to OCI Cache with Redis.

For example, Lettuce or Jedis for Java, redis-py for Python, node-redis for Node.js, go-redis for Go and so on.

You can use redis-cli to connect to Redis cluster. The redis-cli is a command-line based tool connect to your redis clusters which can also be used to get valuable insights from the redis cluster.

To use redis-cli comes included with the Redis package. You need to establish a secure TLS connection between the client/application and redis server. You should use redis-cli version 6 or above so that it supports the --tls switch to establish as secure TLS connection.

By default, redis version 5 is default in the stream on Oracle Linux 8.

See below for Oracle Linux 7/RedHat Linux 7/CentOs 7.

[root@jay ~]# yum module list redis

Last metadata expiration check: 0:06:43 ago on Fri 27 Oct 2023 14:34:46 GMT.

Oracle Linux 8 Application Stream (x86_64)

Name Stream Profiles Summary

redis 5 [d][e] common [d] Redis persistent key-value database

redis 6 common [d] Redis persistent key-value database

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

[root@jay ~]#

To install Redis Version 6, you need to enable redis 6 module stream.

[root@jay ~]# yum module enable redis:6

Last metadata expiration check: 0:10:29 ago on Fri 27 Oct 2023 14:34:46 GMT.

Dependencies resolved.

======================================================================================================================================================================================================

Package Architecture Version Repository Size

======================================================================================================================================================================================================

Enabling module streams:

redis 6

Transaction Summary

======================================================================================================================================================================================================

Is this ok [y/N]: y

Complete!

[root@jay ~]#

However, if you end up with the following error: “Error: It is not possible to switch enabled streams of a module unless explicitly enabled via configuration option module_stream_switch.”, you need to uninstall previous redis versions and reset the redis module as follows.

[root@jay ~]# yum module enable redis:6

Last metadata expiration check: 0:07:49 ago on Fri 27 Oct 2023 14:34:46 GMT.

Dependencies resolved.

The operation would result in switching of module 'redis' stream '5' to stream '6'

Error: It is not possible to switch enabled streams of a module unless explicitly enabled via configuration option module_stream_switch.

It is recommended to rather remove all installed content from the module, and reset the module using 'yum module reset <module_name>' command. After you reset the module, you can install the other stream.

[root@jay ~]#

[root@jay ~]# yum module reset redis

Last metadata expiration check: 0:10:14 ago on Fri 27 Oct 2023 14:34:46 GMT.

Dependencies resolved.

======================================================================================================================================================================================================

Package Architecture Version Repository Size

======================================================================================================================================================================================================

Resetting modules:

redis

Transaction Summary

======================================================================================================================================================================================================

Is this ok [y/N]: y

Complete!

[root@jay ~]#

Once redis mode is reset and version 6 module is enabled, you may proceed with installing redis version 6 as follows.

[root@jay ~]# yum module install redis

Last metadata expiration check: 0:11:16 ago on Fri 27 Oct 2023 14:34:46 GMT.

Dependencies resolved.

======================================================================================================================================================================================================

Package Architecture Version Repository Size

======================================================================================================================================================================================================

Installing group/module packages:

redis x86_64 6.2.7-1.module+el8.7.0+20764+cc495aeb ol8_appstream 1.2 M

Installing module profiles:

redis/common

Transaction Summary

======================================================================================================================================================================================================

Install 1 Package

Total download size: 1.2 M

Installed size: 4.3 M

Is this ok [y/N]: y

Downloading Packages:

redis-6.2.7-1.module+el8.7.0+20764+cc495aeb.x86_64.rpm 6.9 MB/s | 1.2 MB 00:00

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Total 6.8 MB/s | 1.2 MB 00:00

Running transaction check

Transaction check succeeded.

Running transaction test

Transaction test succeeded.

Running transaction

Preparing : 1/1

Running scriptlet: redis-6.2.7-1.module+el8.7.0+20764+cc495aeb.x86_64 1/1

Installing : redis-6.2.7-1.module+el8.7.0+20764+cc495aeb.x86_64 1/1

Running scriptlet: redis-6.2.7-1.module+el8.7.0+20764+cc495aeb.x86_64 1/1

Verifying : redis-6.2.7-1.module+el8.7.0+20764+cc495aeb.x86_64 1/1

Installed:

redis-6.2.7-1.module+el8.7.0+20764+cc495aeb.x86_64

Complete!

[root@jay ~]#

On Oracle Linux 7/RHEL 7/CentOs7:

On Oracle Linux 7 / RedHat Linux 7, you should install ‘epel-release-7-14’ and ‘remi’ repositories to get the latest version of Redis. The default repo has only 3.X.X which doesn't support 'tls' in-transit encryption.

# yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm # yum -y install http://rpms.remirepo.net/enterprise/remi-release-7.rpm # yum --enablerepo=remi install redis

You should get Redis v7.X.X which has support for 'tls' connections.

You should now be able to connect to Redis cluster using redis-cli:

# redis-cli --tls -h <Redis Endpoint>

[root@jay ~]# redis-cli --tls -h amaaaaaa2ne4d2g6eiu32jva-p.redis.eu-frankfurt-1.oci.oraclecloud.com

amaaaaaa2ne4d2g6eiu32jva-p.redis.eu-frankfurt-1.oci.oraclecloud.com:6379>

amaaaaaa2ne4d2g6eiu32jva-p.redis.eu-frankfurt-1.oci.oraclecloud.com:6379> set key value

amaaaaaa2ne4d2g6eiu32jva-p.redis.eu-frankfurt-1.oci.oraclecloud.com:6379> get key

"value"

amaaaaaa2ne4d2g6eiu32jva-p.redis.eu-frankfurt-1.oci.oraclecloud.com:6379> quit

[root@jay ~]#