Forem: Alex Fler

Stop Context-Switching to Check SSL Certs — Do It From Emacs

Alex Fler — Thu, 26 Feb 2026 00:00:00 +0000

If you spend most of your day in Emacs and manage any amount of infrastructure, you’ve felt this friction: you need to check a cert, so you alt-tab to a terminal, type out an openssl s_client incantation you can never quite remember, parse the wall of output, and then switch back to whatever you were doing. The context switch is small but constant, and it adds up.

I built certradar-cli — a Rust-based SSL/TLS analysis tool — partly to solve this. But it got way more useful once I wired it into Emacs with a few lines of elisp. Now cert checks are one keystroke away, inline with my workflow, and I actually do them proactively instead of reactively.

Prerequisites

You’ll need certradar-cli installed. It’s a single Rust binary:

cargo install certradar-cli

Verify it’s working:

certradar-cli ssl example.com

If you’re on a system where ~/.cargo/bin isn’t on your PATH, you’ll also want to tell Emacs where to find it:

(add-to-list 'exec-path "~/.cargo/bin")

The `M-x` Command

This gives you a check-ssl command that prompts for a domain and opens the results in a dedicated read-only buffer:

(defun check-ssl--clean-domain (domain)
  "Strip protocol prefix and port suffix from DOMAIN."
  (let ((cleaned (replace-regexp-in-string "https?://" "" domain)))
    (replace-regexp-in-string ":[0-9]+$" "" cleaned)))

(defun check-ssl (domain)
  "Check SSL/TLS certificate for DOMAIN using certradar-cli."
  (interactive "sDomain: ")
  (let* ((clean-domain (check-ssl--clean-domain domain))
         (buf-name (format "*SSL: %s*" clean-domain))
         (buf (get-buffer-create buf-name)))
    (with-current-buffer buf
      (read-only-mode -1)
      (erase-buffer)
      (insert (format "SSL Certificate Report: %s\n" clean-domain))
      (insert (make-string 50 ?─))
      (insert "\n\n")
      (let ((result (shell-command-to-string
                     (format "certradar-cli ssl --no-color %s 2>&1"
                             (shell-quote-argument clean-domain)))))
        (insert result))
      (goto-char (point-min))
      (special-mode))
    (switch-to-buffer-other-window buf)))

Usage: M-x check-ssl RET example.com RET. You get a buffer you can scroll, search with C-s, or yank text from. The buffer is in special-mode so you won’t accidentally edit the output.

The domain cleanup helper strips both https:// prefixes and :443 port suffixes, so you can paste https://example.com:8443/path and it just works. --no-color keeps ANSI escape codes out of the buffer — without it, Rust CLI tools tend to dump ^[[32m garbage into your output. shell-quote-argument prevents injection if you’re ever passing untrusted input. switch-to-buffer-other-window keeps your current buffer visible — useful when you’re checking a cert referenced in the code you’re reading.

Check the Domain Under Your Cursor

If you keep domain lists in org files, Ansible inventories, Nginx configs, or anywhere else, this function grabs whatever’s under point and checks it:

(defun check-ssl-at-point ()
  "Check SSL cert for the domain under point."
  (interactive)
  (let ((domain (thing-at-point 'url t)))
    (if domain
        (check-ssl domain)
      (let ((word (thing-at-point 'symbol t)))
        (if (and word (string-match-p "\\." word))
            (check-ssl word)
          (call-interactively #'check-ssl))))))

It tries to grab a full URL at point first, then falls back to the symbol at point if it contains a dot (probably a domain), and prompts you if neither works. No need to strip the protocol here — check-ssl--clean-domain handles all of that.

Bind it somewhere fast:

(global-set-key (kbd "C-c s") #'check-ssl-at-point)

Cursor on domain → C-c s → cert report. No context switch, no copy-paste, no remembering flags.

Async Variant (Don’t Freeze Emacs)

One problem with the version above: shell-command-to-string is blocking. If a domain is hanging or DNS is slow, Emacs locks up until it times out. That’s fine for fast lookups, but if you’re checking anything over a flaky connection, it’s painful.

Here’s the same thing using make-process so Emacs stays responsive while the cert is fetched:

(defun check-ssl-async (domain)
  "Check SSL/TLS certificate for DOMAIN asynchronously."
  (interactive "sDomain: ")
  (let* ((clean-domain (check-ssl--clean-domain domain))
         (buf-name (format "*SSL: %s*" clean-domain))
         (buf (get-buffer-create buf-name)))
    (with-current-buffer buf
      (read-only-mode -1)
      (erase-buffer)
      (insert (format "SSL Certificate Report: %s\n" clean-domain))
      (insert (make-string 50 ?─))
      (insert "\n\nFetching...\n"))
    (switch-to-buffer-other-window buf)
    (make-process
     :name (format "certradar-%s" clean-domain)
     :buffer buf
     :command (list "certradar-cli" "ssl" "--no-color" clean-domain)
     :sentinel (lambda (proc _event)
                 (when (eq (process-status proc) 'exit)
                   (with-current-buffer (process-buffer proc)
                     (goto-char (point-min))
                     (when (search-forward "Fetching..." nil t)
                       (replace-match ""))
                     (special-mode)))))))

The buffer pops open immediately with “Fetching…”, and the output streams in as it arrives. You can keep typing in other buffers while it runs. If you want this as your default, just rebind C-c s to call check-ssl-async instead.

Org-Babel for Runbooks

If you use org-mode for operational documentation — and if you’re running infrastructure, you really should — this embeds cert checks directly into your notes.

Single Domain Check

#+NAME: ssl-check
#+BEGIN_SRC shell :var domain="example.com" :results output
certradar-cli ssl "$domain"
#+END_SRC

Place your cursor inside the block and hit C-c C-c. The output appears inline, right below the block. Change the :var domain= value and run it again. The results become part of your document — perfect for incident write-ups, audit trails, or change management records.

Batch Checking Multiple Domains

#+NAME: ssl-batch
#+BEGIN_SRC shell :results output
for domain in example.com github.com expired.badssl.com; do
    echo "=== $domain ==="
    certradar-cli ssl "$domain"
    echo ""
done
#+END_SRC

I keep a domains.org file with all the certs I’m responsible for. During maintenance windows, I run through the batch blocks and the results stay versioned in the file. It’s not a replacement for proper monitoring, but it’s a great complement — especially when you need evidence that you actually checked things.

Why This Works So Well

The real value isn’t the execution itself — it’s that your checks live next to your context. You’re writing up an incident and need to verify the cert state? You don’t leave the document. Onboarding someone and want to show them how to verify certs? The runbook runs. Everything stays in one place, reproducible and version-controlled.

Background Expiry Monitoring

This one is for anyone who’s been woken up at 3am because a cert expired silently. It runs a background timer that checks your critical domains and warns you inside Emacs when certs are getting close:

(defvar ssl-watch-domains '("yourdomain.com" "api.yourdomain.com")
  "Domains to monitor for certificate expiry.")

(defvar ssl-expiry-warning-days 14
  "Warn when cert expires within this many days.")

(defun ssl-check-expiry-warnings ()
  "Check watched domains and message any upcoming expirations."
  (dolist (domain ssl-watch-domains)
    (let ((output (shell-command-to-string
                   (format "certradar-cli ssl --no-color %s --json 2>/dev/null"
                           (shell-quote-argument domain)))))
      (when (string-match "\"days_until_expiry\":\\s*\\([0-9]+\\)" output)
        (let ((days (string-to-number (match-string 1 output))))
          (when (<= days ssl-expiry-warning-days)
            (message "SSL WARNING: %s expires in %d days!" domain days)
            (run-with-timer 0.5 nil
              (lambda (d n)
                (display-warning 'ssl
                  (format "%s certificate expires in %d days" d n)
                  :warning))
              domain days)))))))

;; Check once on startup, then every 6 hours
(ssl-check-expiry-warnings)
(run-with-timer 21600 21600 #'ssl-check-expiry-warnings)

Now, this Emacs timer is fine for a handful of domains you want to keep an eye on locally. But if you’re managing infrastructure at any real scale, you probably want something that doesn’t depend on your editor being open. That’s why I also built CertRadar.net — it gives you a centralized dashboard with certificate transparency log monitoring, chain validation, and configuration analysis across your entire infrastructure. The stuff that falls through the cracks — the staging environment cert nobody’s watching, the internal tool with a self-signed cert someone issued a year ago, the domain your team inherited last quarter — CertRadar catches that.

I use both. The CLI for “let me check this right now” and CertRadar for “make sure nothing expires or misconfigures while I’m not looking.”

The timer checks every 6 hours (21600 seconds) and uses display-warning to surface alerts in the *Warnings* buffer, which is hard to miss. Adjust ssl-expiry-warning-days based on your renewal workflow — 14 days works for automated Let’s Encrypt setups, but you might want 30 or 60 if your certs require manual renewal.

Installation: The Full Package

I’ve packaged all of the above into a single certradar.el file you can drop into your config. It also includes a check-ssl-batch interactive command and ssl-watch-start / ssl-watch-stop functions for managing the expiry timer.

Grab it from the certradar-cli repository.

Setup

Download certradar.el into ~/.emacs.d/lisp/ (create the directory if it doesn’t exist)
Add this to your init.el:

(add-to-list 'load-path (expand-file-name "lisp" user-emacs-directory))
(require 'certradar)

;; Keybindings
(global-set-key (kbd "C-c s") #'check-ssl-at-point)
(global-set-key (kbd "C-c S") #'check-ssl-batch)

;; Optional: enable the expiry watcher
;; (setq ssl-watch-domains '("yourdomain.com" "api.yourdomain.com"))
;; (ssl-watch-start)

Restart Emacs or evaluate your init.el with M-x eval-buffer.

Why Bother

The actual time saved per cert check is maybe 10 seconds. That’s not the point. Removing the friction changes your behavior. When checking a cert is one keystroke away, you check certs. When it requires switching contexts, opening a terminal, and remembering syntax, you don’t — or at least not as often as you should.

28 years into this career, the tools I actually use are the ones embedded in my workflow, not the ones bookmarked in my browser. If Emacs is where you live, your cert checks should live there too.

certradar-cli is free and open source. If you want a full web-based dashboard for monitoring certs across all your domains, check out CertRadar.net. For ongoing SSL monitoring with alerts, there’s SSLGuard.net.

Where Did That Environment Variable Come From?

Alex Fler — Fri, 13 Feb 2026 00:00:00 +0000

“It works in my terminal but not in cron.”

If you’ve been doing this long enough, that sentence alone is enough to make your eye twitch. You know exactly what’s coming: an hour of grepping through dotfiles, manually reading shell startup chains in your head, and eventually finding that some vendor install script shoved a PATH override into /etc/profile.d/java-vendor-garbage.sh three years ago and nobody noticed because interactive shells got the right value from ~/.zshrc anyway.

I’ve done this dance hundreds of times. Literally hundreds. And every single time it’s the same tedious archaeology: which files does this shell context actually read, in what order, and which one of them is clobbering my variable?

So I finally wrote a tool to do it for me.

The Shell Startup Problem

If you already know how shell startup files work, skip ahead. If you don’t, buckle up, because this is where most env var bugs come from and nobody teaches it properly.

When you open a terminal on macOS, zsh reads seven files in a specific order:

/etc/zshenv → /etc/zprofile → ~/.zshenv → ~/.zprofile → /etc/zshrc → ~/.zshrc → ~/.zlogin

Bash on Linux does its own thing:

/etc/profile → /etc/profile.d/*.sh → ~/.bash_profile → ~/.bashrc

That’s just for login shells. An interactive non-login shell? Different chain. A cron job? Skips almost everything—you might only get /etc/environment and whatever the crontab itself sets. systemd services? They have environment.d drop-in directories. And macOS launchd agents live in their own plist-based dimension that has nothing to do with your shell at all.

Every one of these contexts can set, override, append to, or unset the same variable. A variable can enter ~/.zshenv as /usr/bin, get /usr/local/bin prepended in /etc/zprofile, pick up /opt/homebrew/bin in ~/.zshrc, and then get completely overwritten by some ancient ~/.zlogin that hardcodes a value from 2021.

The “it works on my machine” of environment variables is really “it works in my specific shell context.”

envtrace

envtrace walks the actual startup file chain for your platform and context, and shows you every file that touches a given variable. That’s it. No magic.

cargo install envtrace


$ envtrace PATH

You get a chronological trace: file, line number, operation (set, export, append, prepend, unset, conditional), and the resulting value after each step. Every file in the chain that doesn’t touch your variable gets skipped, unless you pass --verbose and want to see the full list of files it checked.

The “Works in Terminal, Breaks in Cron” Fix

Here’s the scenario that made me actually write this thing.

A Java developer files a ticket: “JAVA_HOME is wrong in the CI runner.” I SSH into the box. echo $JAVA_HOME gives me /usr/lib/jvm/java-17. Correct. I trigger the CI job manually. It picks up Java 11. What?

The answer, as always, is context. My interactive login shell reads ~/.zshrc, which sources an internal java-env.sh that exports the Java 17 path. The CI runner spawns a non-interactive non-login shell. It never touches ~/.zshrc. It gets its JAVA_HOME from /etc/profile, which still points to Java 11 because nobody updated it after the migration six months ago.

This is not a bug. This is how Unix shells have always worked. But figuring this out by hand means you have to know which files each context reads, then manually read each one, then mentally track the value as it mutates through the chain. Every time.

Or:

$ envtrace -C login,cron JAVA_HOME

The -C flag compares a variable across multiple contexts side by side. You see the full trace for each context and exactly where the values diverge. This one flag alone would have saved me more hours than I’m comfortable admitting.

Tracing Functions

Variables aren’t the only casualties. Shell functions get sourced, overridden, and unset -f’d through the same chain. If you’ve ever wondered why nvm is suddenly not a function after some dotfile change, this is for you:

$ envtrace -F nvm

Picks up POSIX function syntax, bash function keyword syntax, zsh autoload declarations, and unset -f removals. Same chronological trace, same file chain awareness.

Finding Things When You Have No Idea

Sometimes you don’t even know which context is relevant. You just know something somewhere is setting LD_LIBRARY_PATH to a directory that was decommissioned in the Obama administration and you need to find it.

$ envtrace --find LD_LIBRARY_PATH

Ignores context entirely, searches every config file it knows about, and shows you every mention. Broad net.

PATH Health Checks

While I was in there, I added a sanity checker:

$ envtrace --check

Scans your PATH for the usual sins: directories that don’t exist, duplicates, empty entries from stray :: separators. On macOS, it also compares what your shell sees against what launchd provides to GUI apps—which is the root cause of every “it works in Terminal but not in VS Code” bug report you’ve ever gotten.

Under the Hood

I want to be upfront about what this is and isn’t. envtrace is not a shell parser. Fully parsing bash is a Lovecraftian horror that I am not interested in. What it does is pattern-match against the forms people actually use in dotfiles:

export VAR=value and VAR=value
VAR="$VAR:/new/path" (append) and VAR="/new/path:$VAR" (prepend)
unset VAR
[-f /something] && export VAR=value (conditional)
source and . directives (followed recursively, with circular-include detection so your weird dotfile setup doesn’t send it into an infinite loop)

This covers the vast majority of what you’ll find in real startup files. If you have some baroque eval $(generate_env_dynamically.py) situation, envtrace won’t help you and frankly nothing will.

It spits out JSON too (--format json) if you want to pipe it into jq or build something on top of it.

Getting It

cargo install envtrace

Or grab a binary from the releases page. Needs Rust 1.85+ if you’re building from source.

It runs on macOS (zsh) and Linux (bash). Those are the two platforms I care about and the two platforms where this problem actually exists.

The next time you’re staring at a broken PATH at 2 AM, trying to remember whether /etc/profile runs before or after ~/.bash_profile (it does), and whether cron even reads either of them (it doesn’t)—just trace it.

GPG Isn’t Broken, You’re Just Using It Wrong

Alex Fler — Sun, 25 Jan 2026 16:19:17 +0000

I’ve been managing keys since 1997—started on heavy iron back when "remote troubleshooting" meant driving to the data center at 2am. In that time, I’ve seen GnuPG called everything from "obsolete" to "impossible." The truth is, most of the headaches come from treating 2026 infrastructure like it's still 1999.

People solve the same thorny problems over and over, usually by making things more complicated than they need to be. If you are still manually syncing private keys across five different laptops via USB drive, you are doing it wrong.

Here is the pragmatic, "physics wins" approach to OpenPGP that I actually use.

The Philosophy: Cattle, Not Pets

We learned long ago in Ops to treat servers like cattle, not pets. Yet, we still treat GPG subkeys like precious heirlooms.

PGP keys have four functions. Two of them—Signing and Authenticating—are fungible. It does not matter which subkey signs your commit, as long as it ties back to your primary identity.

The Rule: Generate a new signing/auth subkey for every single device you own.

Laptop died? Revoke that specific subkey.
New workstation? Generate a new subkey.
Lost access? Who cares? They are trivially replaceable.

The Identity Crisis (UIDs)

A common mistake I see in r/devops is the "Omnibus Key"—one key with fifteen different email addresses attached.

Your primary key is your root identity. If you are signing Git commits for your employer, do not use your personal identity key.

Create a specific Primary Key for work. Use your work email as the UID.
Create subkeys off that primary.

Result: Your work signatures are tied only to your work identity.

If you leave that job, you revoke the whole key. Clean break.

The Configuration You Actually Need

Default GnuPG settings are suboptimal. We want a clean Ed25519 setup.

1. Create a Cert-Only Primary Key

We want a key that can only certify (manage) other keys.

gpg --quick-generate-key "Your Name <you@work.com>" ed25519 cert

2. Create Your Subkeys

Add the "cattle" keys. We add a signing key for Git, and an encryption key so colleagues can send you secrets (like initial passwords) securely.

gpg --edit-key "you@work.com"
gpg> addkey
# Select (10) ECC (sign only) -> Ed25519
# Valid for? Enter "2y"
gpg> addkey
# Select (12) ECC (encrypt only) -> Cv25519
# Valid for? Enter "2y"
gpg> save

Operational Hygiene: The "Kill Switch"

Before you go any further, generate a revocation certificate.

I once spent a holiday weekend trying to recover a key I'd "safely" stored on a USB drive... which turned out to be an encrypted volume where the password was stored inside that same volume. I had to burn the identity and start over.

Don't be me. Generate the revocation cert now and print it out on actual paper.

gpg --output revoke.asc --gen-revoke "you@work.com"

Expiration Strategy

I set my subkeys to expire in 2 years. I have a calendar reminder to rotate them annually. To extend a key (when your annual reminder pops up), you must select the specific subkey first.

gpg --edit-key "you@work.com"
gpg> key 1        # Select signing subkey
gpg> expire       # Enter "2y"
gpg> key 1        # Deselect
gpg> key 2        # Select encryption subkey
gpg> expire       # Enter "2y"
gpg> save

The "One True Source"

This is the part that fixes 90% of the "I can't verify this signature" errors.

Forget public keyservers. They are a mess of spam. The OpenPGP spec allows you to define a preferred-keyserver. It lets you say: "If you want my key, look HERE."

1. Set the Preference

Tell the key where it lives using the keyserver subcommand.

gpg --edit-key "you@work.com"
gpg> keyserver https://keys.theopsmechanic.com/0xYOURFINGERPRINT.asc
gpg> save

2. Host It

Export the key and push it to your static site (Nginx, Cloudflare Pages, S3, etc).

gpg --armor --export "you@work.com" > static/mykey.asc

Offline the Master Key

People say "keep your master key offline" but rarely explain the mechanics.

Step 0: BACK UP EVERYTHING. Copy your entire ~/.gnupg directory to an encrypted USB drive.

Step 1: Remove the Secret Key
We need to remove the master secret key from your laptop while keeping the subkeys active.

# 1. Export your secret SUBKEYS (this strips the master secret key)
gpg --export-secret-subkeys "you@work.com" > subkeys.gpg

# 2. Delete the secret key entirely from your keyring
gpg --delete-secret-key "you@work.com"

# 3. Import the subkeys back in
gpg --import subkeys.gpg

# 4. Clean up the temp file
shred -u subkeys.gpg

Step 2: Verify
Run gpg -K (list secret keys). Look for the # symbol next to sec.

sec#  ed25519 2026-01-11 [C]  <-- The '#' means the secret key is NOT here. Good.
ssb   ed25519 2026-01-11 [S]  <-- Signing subkey present.

If you see sec#, you succeeded. Your laptop can sign commits, but it cannot create new subkeys or revoke your identity.

Making `git log` Actually Useful

We can fix "No Public Key" errors by embedding the URL to your key inside every signature you make.

Add this to your local GPG config:

# ~/.gnupg/gpg.conf
sig-keyserver-url https://keys.theopsmechanic.com/0xYOURFINGERPRINT.asc

The Catch: For this to work automatically, the verifier needs keyserver-options auto-key-retrieve enabled. Even without it, the URL provides a clear breadcrumb to solve the problem manually.

The Cheat Sheet

If you skipped the prose, here is the lifecycle.

1. Generate & Configure

# Create Cert-Only Master
gpg --quick-generate-key "User <email>" ed25519 cert

# Add Subkeys & URL
gpg --edit-key <FINGERPRINT>
gpg> addkey # Select Sign-Only -> "2y" expiry
gpg> addkey # Select Encrypt-Only -> "2y" expiry
gpg> keyserver https://your-domain.com/key.asc
gpg> save

# EMERGENCY BRAKE (Do not skip)
gpg --output revoke.asc --gen-revoke <FINGERPRINT>

2. Offline Master

This is the dangerous part. Focus.

gpg --export-secret-subkeys <FINGERPRINT> > subkeys.gpg
gpg --delete-secret-key <FINGERPRINT>
gpg --import subkeys.gpg
shred -u subkeys.gpg
# Verify: gpg -K must show 'sec#'

3. Distribute & Use

# Upload
gpg --armor --export <FINGERPRINT> > key.asc
# (Upload to https://your-domain.com/key.asc)

# Config
echo "sig-keyserver-url https://your-domain.com/key.asc" >> ~/.gnupg/gpg.conf
git config --global user.signingkey <SUBKEY_FINGERPRINT>
git config --global commit.gpgsign true

Prior Art & Further Reading

I am standing on the shoulders of giants (and paranoid sysadmins) here. If you want to go deeper:

Debian Wiki: Offline Master Key — The original bible on splitting master and subkeys.
DrDuh's YubiKey Guide — If you want to take this logic and apply it to hardware tokens (highly recommended for high-security contexts).

Set it up once, correctly. Physics wins.

Your SSH Keys Are Naked and It's Your Fault

Alex Fler — Sun, 25 Jan 2026 16:16:40 +0000

I've been SSHing into production boxes since before most junior devs were born. In that time, I've seen the same sins repeated across every generation of sysadmins: naked private keys sitting in ~/.ssh with no passphrase, copy-pasted across laptops, synced to Dropbox (yes, really), and generally treated with the same care as a grocery list.

If your SSH private key doesn't have a passphrase on it right now, you're one stolen laptop away from a very bad day.

Here's the setup I actually use—one that treats SSH authentication like the serious business it is, without making you type passwords fifty times a day.

The Problem: Naked Keys Everywhere

Let me paint you a picture I've seen a dozen times.

Developer gets new laptop. Developer runs ssh-keygen, hammers Enter through the passphrase prompts because "it's annoying," and copies id_rsa.pub to fifteen different servers. Developer feels productive.

Six months later, laptop gets stolen from a coffee shop. Thief now has root access to production. Developer updates LinkedIn to "exploring new opportunities."

The math is simple: An unencrypted private key is a plaintext password sitting on your disk. Would you store root:hunter2 in a file called passwords.txt? Then why is your SSH key any different?

"But Passphrases Are Annoying"

I hear this constantly. And you know what? You're right. Typing a 20-character passphrase every time you SSH somewhere is annoying. That's why we have ssh-agent.

The agent holds your decrypted key in memory. You type your passphrase once when you start your session, and the agent handles every subsequent connection. This is not new technology—it has existed since the 90s.

Setting Up ssh-agent (The Basics)

Most modern systems start an agent automatically. Check if you have one running:

echo $SSH_AUTH_SOCK

If you get a path back, you're set. If not, start one:

eval $(ssh-agent -s)

Add your key to the agent:

ssh-add ~/.ssh/id_ed25519

You'll be prompted for your passphrase once. After that, every SSH connection uses the cached key.

Making It Persistent

On Linux with systemd, enable the user agent service:

systemctl --user enable ssh-agent
systemctl --user start ssh-agent

Add to your shell profile:

# ~/.bashrc or ~/.zshrc
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"

Watch out: Some distros (looking at you, Ubuntu) start their own agent via X11 session scripts. You can end up with two agents fighting over SSH_AUTH_SOCK. If keys aren't loading as expected, check pgrep -a ssh-agent and kill any stragglers.

On macOS, add keys to the Keychain:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

And configure SSH to use it by adding to ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes

Now your passphrase survives reboots without you thinking about it.

Going Further: GPG Keys for SSH (The Right Way)

Here's where I lose half the audience. Stay with me.

Why Bother?

If ssh-agent with a passphrase is "good enough," why complicate things with GPG?

Because you're already maintaining GPG keys for Git signing (you ARE signing your commits, right?). Adding SSH to that same identity means one backup, one rotation schedule, one mental model. And if you ever move to hardware tokens like YubiKeys, the GPG path gets you there with zero additional work—the YubiKey becomes your SSH key automatically.

You already have a GPG key if you followed my previous article. That key can have an Authentication subkey. Here's what you get:

One identity to rule them all. Your GPG key signs commits, encrypts email, AND authenticates SSH. One key to back up, one key to rotate, one key to revoke.
Hardware token support. If you're using a YubiKey for GPG (and you should be), you get SSH authentication on hardware for free. The private key never touches your disk.
The "cattle not pets" model carries over. Device-specific auth subkeys mean a compromised laptop doesn't compromise your entire SSH infrastructure.
Expiration is built in. GPG subkeys have native expiry. Set your auth key to expire in 6 months—if it's compromised, the damage is time-boxed. Standard SSH keys never expire by default. You still need to update authorized_keys files, but at least you have a forcing function.

Step 1: Enable SSH Support in GPG Agent

The GPG agent can emulate ssh-agent. We just need to tell it to.

Add to ~/.gnupg/gpg-agent.conf:

enable-ssh-support

Restart the agent:

gpgconf --kill gpg-agent
gpg-agent --daemon

Step 2: Point SSH at GPG Agent

Add to your shell profile:

# ~/.bashrc or ~/.zshrc
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
gpgconf --launch gpg-agent

Reload your shell. Verify it's working:

ssh-add -L

You should see your GPG authentication subkey in SSH format.

Step 3: Add an Authentication Subkey (If You Don't Have One)

If you followed my GPG article, you have Signing and Encryption subkeys. Let's add Authentication.

gpg --edit-key "you@work.com"
gpg> addkey
# Select (10) ECC (sign only)... wait, that's wrong.
# We need to enable expert mode for auth keys.
gpg> quit

Let me try that again:

gpg --expert --edit-key "you@work.com"
gpg> addkey
# Select (11) ECC (set your own capabilities)
# Toggle off Sign, toggle on Authenticate
# Select Curve 25519
# Valid for? "2y"
gpg> save

Step 4: Export the Public Key for SSH

Get your authentication subkey's keygrip (not the fingerprint—this trips people up):

gpg -K --with-keygrip

Find the [A] subkey (Authentication) and note its keygrip. It's the 40-character hex string on the line after the subkey.

Export it in SSH format:

gpg --export-ssh-key you@work.com

This outputs a standard ssh-ed25519 AAAA... line. Add it to ~/.ssh/authorized_keys on your servers, or to GitHub/GitLab.

Step 5: Tell GPG Agent Which Key to Use

Add the keygrip to ~/.gnupg/sshcontrol:

echo "YOURKEYGRIP 0" >> ~/.gnupg/sshcontrol

The 0 means "don't require confirmation for each use." Change it to 1 if you're paranoid.

The Full Picture

Here's what your setup looks like now:

One identity. Backed up once. Revocable from one place.

Operational Reality

A few things I've learned running this setup for years:

Revocation doesn't work like you think. When you export a GPG key to SSH format, it's just a static public key string. The SSH daemon on your servers doesn't check GPG keyservers—it has no idea if you revoked the key. You still need to remove lines from authorized_keys manually (or use something like LDAP/CA-based SSH). The win here is that GPG gives you a single source of truth for what should be valid. When you revoke a subkey, you know what to clean up.

The agent timeout matters. By default, gpg-agent caches your passphrase for 600 seconds. Tune this in gpg-agent.conf:

default-cache-ttl 3600
max-cache-ttl 7200

I use an hour for normal caching, two hours max. Adjust based on your paranoia level.

Forwarding works differently. If you're used to ssh -A for agent forwarding, it still works—but you're forwarding the GPG agent socket. This is actually more secure because you can configure which keys are allowed to be used remotely.

YubiKey users get the best deal. If your GPG key lives on a hardware token, your SSH authentication requires physical presence. No malware can exfiltrate what isn't on the disk.

The Cheat Sheet

Encrypt Your Existing SSH Key (If You're Not Ready to Switch)

# Add passphrase to existing key
ssh-keygen -p -f ~/.ssh/id_ed25519

# Verify agent is running
echo $SSH_AUTH_SOCK

# Add key to agent
ssh-add ~/.ssh/id_ed25519

Switch to GPG-Based SSH

# Enable SSH support
echo "enable-ssh-support" >> ~/.gnupg/gpg-agent.conf

# Update shell
echo 'export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)' >> ~/.bashrc
echo 'gpgconf --launch gpg-agent' >> ~/.bashrc
source ~/.bashrc

# Add auth subkey
gpg --expert --edit-key you@work.com
# addkey -> ECC (set your own capabilities) -> Auth only -> Curve 25519 -> 2y

# Get SSH public key
gpg --export-ssh-key you@work.com >> ~/.ssh/authorized_keys_gpg

# Find KEYGRIP (not fingerprint!) and add to sshcontrol
gpg -K --with-keygrip | grep -A1 "\[A\]"
echo "KEYGRIP 0" >> ~/.gnupg/sshcontrol

Verify Everything Works

# List keys the agent knows about
ssh-add -L

# Test connection
ssh -v user@server 2>&1 | grep "Offering public key"

Prior Art & Further Reading

GnuPG Wiki: SSH Support — The official documentation on gpg-agent SSH emulation.
DrDuh's YubiKey Guide — Again. If you're serious about this, put your keys on hardware.
Arch Wiki: GnuPG/SSH agent — Exhaustive documentation on every edge case.

Stop treating SSH keys like disposable toys. Encrypt them, manage them properly, and ideally consolidate them under your GPG identity.

Physics wins. Naked keys lose.

I Audited 50 SaaS Vendors' TLS Configurations — Here's What I Found

Alex Fler — Sun, 25 Jan 2026 00:00:00 +0000

I spent the weekend scanning the TLS configurations of 50 popular B2B SaaS tools using CertRadar.net. My goal was simple: find out whether the vendors we trust with our data are actually practicing good TLS hygiene.

The short answer? No disasters. The longer answer reveals some interesting gaps — particularly from vendors who should know better.

Methodology

I scanned the primary marketing domain for each vendor (e.g., okta.com, slack.com) using CertRadar’s SSL analyzer. I collected data on:

How to Automate Let's Encrypt Renewal Monitoring on Nginx (The Robust Way)

Alex Fler — Wed, 14 Jan 2026 00:24:06 +0000

We've all been there. It's Monday morning, you haven't had your coffee yet, and Slack is blowing up.

Users are seeing "Your connection is not private." The CTO is asking why the site is "hacked." Your boss's boss is cc'd on something. You check the box. Nginx is running. The app is fine. Load averages are low.

Then it hits you: The Certbot cron job failed silently.

Maybe the ACME challenge timed out. Maybe Nginx didn't reload to pick up the new cert. Maybe DNS propagation was slow. Maybe Mercury was in retrograde. Doesn't matter—production is down because of a 90-day text file, and you look incompetent.

In the old days, we bought Verisign certs that lasted 3 years and cost as much as a used car. Now we've traded dollars for DevOps anxiety—we have to be right every 90 days, forever. Thanks, Let's Encrypt. (I kid. Mostly.)

Here's how to script your way out of that.

The "Hard Way": Bash, OpenSSL, and Grit

I write a fair amount of Python and Rust these days, but when you need something to run on any box, anywhere, with zero dependencies? You go back to Bash. It's the vi of scripting—ugly, ornery, and always there when you need it.

To monitor this properly, we can't trust Certbot's output. Certbot lies. Not maliciously—it's just optimistic in a way that will ruin your weekend. We need to do what a user does: ask the web server to show us its papers.

1. The Core Command

We're going to use openssl s_client. If you've ever debugged a TLS handshake manually, you know this tool is powerful and incredibly annoying—like a Swiss Army knife where half the blades are unlabeled. We pipe the handshake into x509 to extract the expiration date:

echo | timeout 10 openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
    | openssl x509 -noout -enddate

Three things to note:

The echo | pipe: Without input, s_client waits for stdin (interactive mode). The echo closes the connection cleanly. Yes, you're literally telling openssl to shut up and get on with it.
The -servername flag: Crucial. Without SNI, Nginx serves the default cert—probably the snake-oil one or whatever config it loaded first alphabetically. You'll get a heart attack for no reason.
The timeout: Without it, a hung remote host blocks your script indefinitely. The loop stops, the rest of your domains don't get checked. How do I know this? Pain.

2. The Monitoring Script (`ssl_check.sh`)

I'm an Emacs guy (Evil mode, because hjkl is muscle memory I refuse to unlearn), but paste this into whatever editor brings you joy. Even nano. I won't judge. (I will judge a little.)

This script iterates through your domains, checks expiration against the live server, and screams at you if you have less than a week left.

#!/bin/bash

# Fail on undefined variables and pipe failures.
# If you aren't using this in bash scripts, start now. Future you will thank present you.
set -uo pipefail

# Configuration
DOMAINS=("example.com" "app.example.com" "api.example.com")
SLACK_WEBHOOK_URL="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
DAYS_THRESHOLD=7
TIMEOUT_SECONDS=10

send_alert() {
    local message="$1"
    # Silence curl output so cron doesn't spam you with "100% downloaded" messages
    curl -sf -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"$message\"}" \
        "$SLACK_WEBHOOK_URL" > /dev/null
}

for DOMAIN in "${DOMAINS[@]}"; do
    # Grab the expiration date from the live cert
    EXP_DATE=$(echo | timeout "$TIMEOUT_SECONDS" openssl s_client \
        -servername "$DOMAIN" \
        -connect "$DOMAIN":443 2>/dev/null \
        | openssl x509 -noout -enddate 2>/dev/null \
        | cut -d= -f2)

    # Validate we got something that looks like a date.
    # Note: 'date -d' is GNU specific. If you are on BSD/macOS, use 'date -j -f'.
    if [[ -z "$EXP_DATE" ]] || ! date -d "$EXP_DATE" &>/dev/null; then
        echo "PANIC: Could not retrieve valid certificate for $DOMAIN"
        send_alert "SSL PANIC: Cannot retrieve certificate for $DOMAIN. Check immediately."
        continue
    fi

    # Convert to epoch for math
    EXP_EPOCH=$(date -d "$EXP_DATE" +%s)
    NOW_EPOCH=$(date +%s)
    DAYS_REMAINING=$(( (EXP_EPOCH - NOW_EPOCH) / 86400 ))

    echo "$(date '+%Y-%m-%d %H:%M:%S') - $DOMAIN: $DAYS_REMAINING days remaining"

    if [[ "$DAYS_REMAINING" -le "$DAYS_THRESHOLD" ]]; then
        send_alert "SSL ALERT: $DOMAIN expires in $DAYS_REMAINING days. Fix it now."
    fi
done

3. The Cron Job

chmod +x that bad boy and throw it in cron:

0 6 * * * /usr/local/bin/ssl_check.sh >> /var/log/ssl_check.log 2>&1

Runs at 6 AM daily. Early enough to fix things before the US wakes up, late enough that you're not debugging at 3 AM. Adjust to taste and timezone guilt.

Why This Script Is Going to Burn You (The "Turn")

I've written variations of that script for 25 years. It's better than nothing, and it proves you respect the fundamentals. But honestly? It's got holes you could drive a mass production Kubernetes deployment through.

Here's why relying solely on this gives you a false sense of security:

1. The "Localhost" Lie

The script runs on your server. If you have split-horizon DNS, internal routing, or a load balancer in front, the script might see a valid internal cert while the outside world sees a firewall block or a timeout. Your monitoring says green. Your customers see red. Your phone rings.

2. The Silent Cron Failure

Who monitors the monitor?

I once had a cron daemon die after a botched OS upgrade. Didn't notice for three weeks—until four certs expired on the same day. The script was perfect. It just wasn't running.

And unless you configure Postfix (and who actually does that anymore?), cron errors go to /var/mail/root. Nobody reads /var/mail/root. That file is where error messages go to die.

3. The Intermediate Chain Problem

The script as written only checks the leaf certificate. openssl s_client receives the full chain, but openssl x509 typically only parses the first PEM block it sees.

If your intermediate cert expires—or Nginx isn't sending the chain at all—older clients (especially Android, bless its fragmented heart) will reject the connection. Your script says "30 days remaining." Half your mobile users see a warning page. Support tickets pile up. "Works on my machine" becomes your epitaph.

4. The Wrong Cert Problem

Here's a fun one: the cert is valid. Expiration looks great. It's just not your cert.

Maybe someone renewed with a different CA. Maybe the wildcard got swapped for a single-domain cert during a late-night deploy. Maybe a junior admin grabbed the staging cert by mistake. (No shade—we've all been that junior admin.)

The expiration date looks fine. The site is broken anyway. Your script sees nothing wrong because technically nothing is wrong—except everything.

5. Maintenance Debt

Every time you spin up a new container, subdomain, or microservice, you have to SSH in and update the DOMAINS array. Forget once, and you're not monitoring it.

"I'll add it to the script later," you say, mass producing a future 2 AM incident.

The Solution: External Monitoring

I got tired of maintaining bespoke Bash scripts across different environments. I wanted something that checked my sites from the outside—like a real user—and handled the edge cases automatically.

That's why I built SSLGuard.

It's the tool I wish I had back when I was manually verifying cert chains on Sun boxes and writing Perl scripts I'm not proud of.

Checks from the outside: No more "works on my machine" false positives.
Validates the full chain: If the intermediate is busted, you'll know before your users do.
Alerts to Slack, Teams, email: You get notified before the cert expires, not after.
Zero maintenance: No scripts to update, no cron to babysit, no /var/mail/root to ignore.

If you have zero budget, steal the Bash script above. It's free, and it's better than nothing.

But if you value your time—and your sleep—give SSLGuard a try. Takes 30 seconds to set up. You'll never have that Monday morning panic again.

Your future self will thank you. Possibly with coffee.

Forem: Alex Fler

Stop Context-Switching to Check SSL Certs — Do It From Emacs

Prerequisites

The M-x Command

Check the Domain Under Your Cursor

Async Variant (Don’t Freeze Emacs)

Org-Babel for Runbooks

Single Domain Check

Batch Checking Multiple Domains

Why This Works So Well

Background Expiry Monitoring

Installation: The Full Package

Setup

Why Bother

Where Did That Environment Variable Come From?

The Shell Startup Problem

envtrace

The “Works in Terminal, Breaks in Cron” Fix

Tracing Functions

Finding Things When You Have No Idea

PATH Health Checks

Under the Hood

Getting It

GPG Isn’t Broken, You’re Just Using It Wrong

The Philosophy: Cattle, Not Pets

The Identity Crisis (UIDs)

The Configuration You Actually Need

1. Create a Cert-Only Primary Key

2. Create Your Subkeys

Operational Hygiene: The "Kill Switch"

Expiration Strategy

The "One True Source"

1. Set the Preference

2. Host It

Offline the Master Key

Making git log Actually Useful

The Cheat Sheet

1. Generate & Configure

2. Offline Master

3. Distribute & Use

Prior Art & Further Reading

Your SSH Keys Are Naked and It's Your Fault

The Problem: Naked Keys Everywhere

"But Passphrases Are Annoying"

Setting Up ssh-agent (The Basics)

Making It Persistent

Going Further: GPG Keys for SSH (The Right Way)

Why Bother?

Step 1: Enable SSH Support in GPG Agent

Step 2: Point SSH at GPG Agent

Step 3: Add an Authentication Subkey (If You Don't Have One)

Step 4: Export the Public Key for SSH

Step 5: Tell GPG Agent Which Key to Use

The Full Picture

Operational Reality

The Cheat Sheet

Encrypt Your Existing SSH Key (If You're Not Ready to Switch)

Switch to GPG-Based SSH

Verify Everything Works

Prior Art & Further Reading

I Audited 50 SaaS Vendors' TLS Configurations — Here's What I Found

Methodology

How to Automate Let's Encrypt Renewal Monitoring on Nginx (The Robust Way)

The "Hard Way": Bash, OpenSSL, and Grit

1. The Core Command

2. The Monitoring Script (ssl_check.sh)

3. The Cron Job

Why This Script Is Going to Burn You (The "Turn")

1. The "Localhost" Lie

2. The Silent Cron Failure

3. The Intermediate Chain Problem

4. The Wrong Cert Problem

5. Maintenance Debt

The Solution: External Monitoring

The `M-x` Command

Making `git log` Actually Useful

2. The Monitoring Script (`ssl_check.sh`)