Showing posts with label Linux. Show all posts
Showing posts with label Linux. 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

  1. TLS Certificates Explained Simply: A Beginner-Friendly Guide for Linux Users
  2. Why Mozilla and Chrome Are Distrusting Some Older DigiCert Certificate Chains
  3. How to Check If Your Linux Server Uses an Affected DigiCert Certificate Chain
  4. Are TLS Certificate Lifetimes Really Dropping to One Month? Here Is the Real Timeline
  5. How to Automate TLS Certificate Renewals on Linux Before Short Lifetimes Become a Problem
  6. My 2026 Certificate Checklist for Linux Admins and Website Owners

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.

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.

Read next: My 2026 Certificate Checklist for Linux Admins and Website Owners


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.

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


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.

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


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.

Read next: Why Mozilla and Chrome Are Distrusting Some Older DigiCert Certificate Chains


Monday, October 23, 2023

DHCP deleting custom entries in /etc/resolv.conf file

 

If you are working on cloud environments like AWS, OCI you might have come across a requirement where you need to add custom settings on DNS like name servers, search domains and so on. Any changes to /etc/resolv.conf or the network configuration files will be reverted by the DNS server associated with the cloud virtual network.

 

There are many ways to set custom DNS settings and make sure it’s not overridden by DHCP. Using Dhclient supersede option is one of the best methods.

 

The dhclient.conf file allows you to configure various options for the DHCP client (dhclient) that controls how your system obtains IP addresses and network configuration information from DHCP servers. The supersede directive is used to override and modify DHCP options that are provided by the DHCP server. It allows you to replace or supplement the DHCP options with your own settings.

 

Below, I'll explain how to use the supercede directive in the dhclient.conf file.

 

Config file: /etc/dhcp/dhclient.conf

 

Basic Syntax with usage:

interface "<INTERFACE>" {

supersede domain-search "<OPTION-NAME>", "OPTION-VALUE";

}

 

Example: If you want to set a custom DNS server on Oracle Linux 8.8, you may use dhclient supersede option as follows:

 

interface "ens3" {

supersede domain-name-servers 8.8.8.8;

}

 

You should reboot the server to see this is action or you can manually set the /etc/resolv.conf file with the required DNS but during the next DHCP renewal, dhclient will check the configuration file and update the superseded value for the DNS name server in /etc/resolv.conf.

 

You can supersede a number of DHCP options in the dhclient.conf file. Here's a list of DHCP options that can be superseded, along with their descriptions:

 

1.     subnet-mask: Specifies the subnet mask for the client's IP address.

2.     broadcast-address: Defines the broadcast address for the client's subnet.

3.     routers: Sets the default gateway or router for the client.

4.     domain-name-servers: Specifies the DNS servers used by the client.

5.     domain-name: Specifies the domain name for the client's network.

6.     domain-search: Specifies the domain search list for the client.

7.     host-name: Sets the hostname for the client.

8.     ntp-servers: Specifies the Network Time Protocol (NTP) servers used for time synchronization.

9.     netbios-name-servers: Specifies the NetBIOS name servers for Windows networking.

10.  netbios-scope: Defines the NetBIOS scope for Windows networking.

11.  interface-mtu: Sets the Maximum Transmission Unit (MTU) for the client's network interface.

12.  domain-name-servers-append: Appends DNS servers to the list provided by the DHCP server.

13.  classless-static-routes: Specifies static routes for the client.

14.  nis-domain: Sets the Network Information Service (NIS) domain.

15.  nis-servers: Specifies NIS servers for the client.

16.  nisplus-domain: Sets the NIS+ domain.

17.  nisplus-servers: Specifies NIS+ servers for the client.

18.  nisplus-client: Configures the NIS+ client settings.

19.  slp-directory-agent: Specifies Service Location Protocol (SLP) directory agents.

20.  slp-service-scope: Defines the SLP service scope.

21.  ldap-servers: Specifies LDAP (Lightweight Directory Access Protocol) servers.

22.  ldap-base-dn: Sets the LDAP base domain name.

23.  ldap-raid-info: Configures LDAP RAID (Redundant Array of Independent Disks) information.

24.  vivso: Supports Vendor-Identifying Vendor Specific Options (VIVSO).

These options can be superseded in the dhclient.conf file to customize the client's network configuration. Keep in mind that not all of these options may be present in your DHCP server's response. It's essential to understand which options are provided by your DHCP server and which ones you need to supersede to meet your network's specific requirements.

Wednesday, October 18, 2023

Intrusion Detection and Integrity Checks with AIDE in Linux

 Advanced Intrusion Detection Environment (AIDE) is an open-source utility designed to monitor and protect the integrity of files on a Linux system. AIDE creates a database of file attributes and uses it to perform regular checks for changes, additions, or deletions in system files, alerting you to potential security breaches. When properly used AIDE helps to protect the system internally, by providing a layer of protection against viruses, rootkits, malware, and detection of unauthorized activities.

 

Why Use AIDE?

  1. Detect Unauthorized Changes: AIDE can identify unauthorized changes to critical system files, helping you catch intrusion attempts promptly.
  2. File Integrity Monitoring: It offers continuous file integrity monitoring, making it ideal for ensuring the stability and security of your server.
  3. Customizable Rules: AIDE allows you to define specific rules for monitoring, tailoring its functionality to your unique server environment.
  4. Alerts and Reports: It generates detailed reports and alerts when changes are detected, making it easier to respond to security incidents.

 

Install AIDE

AIDE is readily available in all the operating system software repositories.

 

# yum install aide


Initilize AIDE

Check if the AIDE database is created and initialized using:

 

# aide --check

 

You might end up with the below error, its because the AIDE database has not been created and initialized.

 

[root@delme ~]# aide --check

Couldn't open file /var/lib/aide/aide.db.gz for reading

 


Create and Initialize AIDE Database using:

 

# aide --init

 

Initializing the AIDE database will take some time as its building a database with entries of the files in the server for integrity checks.

 


As you can see from the logs, the new AIDE DB has been created at ‘/var/lib/aide/aide.db.new.gz’.

 

            [root@delme ~]# aide --init

Start timestamp: 2023-10-17 17:19:48 +0000 (AIDE 0.16)

AIDE initialized database at /var/lib/aide/aide.db.new.gz

 

 

Running the AIDE check now will again error out because the AIDE is still not in the location AIDE needs it to be.

 

[root@delme ~]# aide --check

Couldn't open file /var/lib/aide/aide.db.gz for reading

 

We need to rename the AIDE created in the initialization step as follows:

 

            # mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

 

Running an AIDE check should complete successfully.

 

[root@delme ~]# aide --check

Start timestamp: 2023-10-18 09:34:17 +0000 (AIDE 0.16)

AIDE found differences between database and filesystem!!

 

Summary:

  Total number of entries:    152841

  Added entries:         0

  Removed entries:       0

  Changed entries:       2

 

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

Changed entries:

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

 

f   ...    .C... : /root/dead.letter

f           C    : /var/spool/anacron/cron.daily

 

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

Detailed information about changes:

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

 

File: /root/dead.letter

  SHA512   : jdMY+0A4RF8MDhMhdE1GvbQbxo695cYf | Q9XC53FBoeyLpzXe7bcUvEex0C/EwNZq

             KoS4la95t3np7LxoeMmH943uDFipAq8d | v1BNdB8ZlDwIgMTemCoUSeOWtz1CowZ3

             Q3VgvcerraMGjo6TVP1FHg==         | G/nTFnnCNr9ihxO/NGeTtg==

 

File: /var/spool/anacron/cron.daily

  SHA512   : MAp+To9ckjKmE7nZl5/J5M9EXxsgks8O | BsPYbhD/SXkrAdJ4Z4V6ng7BhrFJmqeZ

             wv/5ABt5bMMxWkrjOci3mQhRKfOoNV/h | IJ87kg0X3xVlJYrXV9MR7+0BJ90/0wg2

             eQBfHpitQxsAY2867cU2FQ==         | TI+f0QyA7lChmEYPer2QxQ==

 

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

The attributes of the (uncompressed) database(s):

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

/var/lib/aide/aide.db.gz

  MD5      : fkL+BqnpQdU/i6i3Y3kYqg==

  SHA1     : soqet8oNzHlY9RyDvmHxkqqHY50=

  RMD160   : yIFtCdBrYrt8XY0YipYaMMLP6N0=

  TIGER    : Cbz88BLcGNlurtyIUeizs8KOjof0vc97

  SHA256   : mZK5eTK5nHYDxp/Q7bpCjBtZXa8o8jTx

             INo+S3qXTVE=

  SHA512   : ASgbZO1egNtthUi4TkMqDuQFpKwUr7bh

             SHkdcSscF6rN2p0EKqdd27qmjDf3cr7X

             nCuHDXZrTfYwPSy46KGfdQ==

 

End timestamp: 2023-10-18 09:34:49 +0000 (run time: 0m 32s)

[root@delme ~]#

 

As you can see AIDE has detected 2 changes in the system since the DB is initialized/updated. Review those changes and make sure everything is fine.

 

Once verified, you should update the AIDE DB to include the known changes using the --update command option.

 

However, if there are changes in the filesystem, which is usually the case when you update the DB, AIDE will create a new DB as follows. You need to back up the old and rename the newly generated one to be the main db.

 

[root@delme ~]# aide --update

Start timestamp: 2023-10-18 09:44:02 +0000 (AIDE 0.16)

AIDE found differences between database and filesystem!!

New AIDE database written to /var/lib/aide/aide.db.new.gz

 

Summary:

  Total number of entries:    152841

  Added entries:         0

  Removed entries:       0

  Changed entries:       2

 

Rename the AIDE Db to include newly modified/added files:

 

# mv /var/lib/aide/aide.db.gz /var/lib/aide/aide.db.$(date +%d%m%y%H%M).gz

 

# mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

 

Running a check again should give you a clean summary provided there are no further changes in the system.

 

AIDE configuration

AIDE’s configuration file is /etc/aide.conf file. You can customize the rules for file monitoring based on your needs. For example, you can add or exclude specific directories or files from monitoring.

The AIDE confirmation file contains the directives that defines the database location, where the new database be created when running an update, default rules, files and directories to be included in the database for monitoring and so on.

 

The following are the default rules, that can be applied to the files and directories to be added to the DB.

#p:      permissions

#i:      inode:

#n:      number of links

#u:      user

#g:      group

#s:      size

#b:      block count

#m:      mtime

#a:      atime

#c:      ctime

#S:      check for growing size

#acl:           Access Control Lists

#selinux        SELinux security context

#xattrs:        Extended file attributes

#md5:    md5 checksum

#sha1:   sha1 checksum

#sha256:        sha256 checksum

#sha512:        sha512 checksum

#rmd160: rmd160 checksum

#tiger:  tiger checksum

 

#haval:  haval checksum (MHASH only)

#gost:   gost checksum (MHASH only)

#crc32:  crc32 checksum (MHASH only)

#whirlpool:     whirlpool checksum (MHASH only)

 

#R:             p+i+n+u+g+s+m+c+acl+selinux+xattrs+md5

#L:             p+i+n+u+g+acl+selinux+xattrs

#E:             Empty group

#>:             Growing logfile p+u+g+i+n+S+acl+selinux+xattrs

 

 

You can create custom rules of your choice using the above default rules.

There are few custom rules already in the configuration file as follows.

 

# NORMAL = R+sha512

NORMAL = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha512

 

# For directories, don't bother doing hashes

DIR = p+i+n+u+g+acl+selinux+xattrs

 

# Access control only

PERMS = p+u+g+acl+selinux+xattrs

 

# Logfile are special, in that they often change

LOG = p+u+g+n+S+acl+selinux+xattrs

 

# Content + file type.

CONTENT = sha512+ftype

 

# Extended content + file type + access.

CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs

 

# Some files get updated automatically, so the inode/ctime/mtime change

# but we want to know when the data inside them changes

DATAONLY =  p+n+u+g+s+acl+selinux+xattrs+sha512

 

You may define rules to watch files and directories. The configuration file contains several default rules that does a job of monitoring files, but you are free to tweak.

 

An example rule set:

Check everything for all files under the /root directory with the exception of checking for permissions only for the hidden files under /root.

 

            /root/\..* PERMS

     /root   CONTENT_EX

 

Use the following to help you detect any changes in data inside all files/directory under /etc/.

 
        /etc/   DATAONLY 

 

You may specify to ignore files and directories using “!” as follows:

            # Files under there directores are too volatile, hence do not include in the AIDE database

!/usr/src

!/usr/tmp

 

Some thoughts on setting up the AIDE rules

There are currently thirteen attributes that AIDE can log including permissions, owner, group, size, all three timestamps (atime, ctime, and mtime), plus lower-level stuff like inode, block count and number of links .

You need to review the rules in the AIDE configuration file and set proper regular expression matching the files you need to monitor is key to effective use of AIDE. If you are monitoring too many file and directories you might end up with extremely long logs to go through. On the other hand a narrow set of rules could risk missing an important change on your system.

 

Run System Integrity Checks Frequently

AT the very minimum AIDE should be configured to run every week or ideally everyday. You could setup a cornjob as follows.

        0 0 * * * /usr/sbin/aide --check