Learn OpenBSD - TLS: acme-client, LibreSSL & Certificates

#Introduction

In episode 9 you saw httpd using certificate files for HTTPS — but where do those certificates come from and how do you manage them? This episode answers that: TLS and certificate infrastructure on OpenBSD.

OpenBSD doesn't use OpenSSL. It uses LibreSSL, a fork created by the OpenBSD project out of frustration with OpenSSL's slow response to vulnerabilities (remember Heartbleed in 2014). LibreSSL keeps SSL_* API compatibility but with cleaned-up code and modern security practices. You'll learn to use it through the openssl CLI, then automate certificates with acme-client.

#LibreSSL: Not Just a Rename

LibreSSL is an OpenSSL fork maintained alongside OpenBSD. What sets it apart:

• Cleaned-up code: a lot of old and experimental code was removed.
• Separated crypto library: libcrypto is separated from the frontend.
• Compatible API: programs using SSL_*, EVP_*, and X509_* keep working.
• Security priority: mitigations such as dropping old protocols and modern minimal TLS versions.

When you run openssl on OpenBSD, you're actually using the LibreSSL binary. Verify with:

openssl version

The output will show LibreSSL X.Y.Z, not an OpenSSL version.

#openssl CLI for Everyday Operations

openssl is a versatile tool. The most commonly used operations:

openssl genrsa -out server.key 4096
openssl req -x509 -new -key server.key -days 365 -out selfsigned.crt
openssl x509 -in example.com.crt -text -noout

• genrsa creates an RSA key (for practice; consider ECDSA for production).
• req -x509 creates a self-signed certificate for local testing.
• x509 -text displays certificate details — the way to check validity dates and CN.

Connection inspection also matters:

openssl s_client -connect example.com:443 -servername example.com
openssl s_client -starttls smtp -connect example.com:25

s_client shows the certificate being served and the negotiated cipher. The -starttls smtp option inspects STARTTLS for mail — relevant in episode 17.

#acme-client: Automatic Certificates from Let's Encrypt

#The /etc/acme-client.conf Configuration

acme-client is OpenBSD's built-in ACME client for issuing certificates from Let's Encrypt or another CA. Its configuration is in /etc/acme-client.conf:

authority letsencrypt {
    api url "https://acme-v02.api.letsencrypt.org/directory"
    account key "/etc/acme/letsencrypt-privkey.pem"
}
 
domain example.com {
    domain key "/etc/ssl/private/example.com.key"
    domain full chain certificate "/etc/ssl/example.com.crt"
    sign with letsencrypt
    alternative names { blog.example.com }
}

The authority block defines the CA, and the domain block specifies the domain, key location, and certificate. alternative names adds SANs.

#Issuing and Renewing

To issue a certificate for the first time:

acme-client -v example.com

This command negotiates with Let's Encrypt, verifies domain ownership via an HTTP challenge (answered by httpd in episode 9), then writes the key and certificate.

#Auto-Renew with Cron

Let's Encrypt certificates are valid for 90 days, so renewal must be automatic. OpenBSD provides the /etc/weekly.local script that cron runs periodically:

acme-client example.com
rcctl reload httpd
rcctl reload relayd

With this, every week acme-client checks and renews certificates that are close to expiry, then reloads the services that use them. Automation without third-party tools.

#TLS Termination at httpd and relayd

TLS termination means a daemon handles the encryption at the front door, then forwards plaintext traffic to the backend. httpd does this through its tls block (episode 9). relayd also supports this — and in episode 16 you'll see relayd combine TLS termination with load balancing.

Best practices consistent across both daemons:

• Certificates in /etc/ssl/ (public) and private keys in /etc/ssl/private/ with 600 permissions.
• Reload the daemon after every certificate update.
• Use modern TLS versions; LibreSSL disables old protocols by default.

#Checking TLS Health

Once everything is running, test from the outside:

openssl s_client -connect example.com:443 </dev/null | openssl x509 -noout -dates -subject

This shows the validity dates and subject of the certificate actually served by the server. If the dates don't change after a renew, there's a reload problem.

#Closing

In episode 10 you secured services with TLS: getting to know LibreSSL as a clean OpenSSL fork, using the openssl CLI to create and inspect keys and certificates, automating Let's Encrypt certificates with acme-client, and doing TLS termination at httpd and relayd.

Key takeaways:

• LibreSSL is OpenBSD's built-in OpenSSL fork; openssl version proves it.
• acme-client issues and renews certificates from /etc/acme-client.conf.
• Auto-renew runs via /etc/weekly.local and must be followed by a daemon reload.
• Private keys are stored in /etc/ssl/private/ with strict permissions.

In the next episode, episode 11, we'll manage data and backup — maintaining filesystems with fsck, using dump and restore, leveraging FFS snapshots, and combining tar, cpio, and rsync for a truly restorable base system backup strategy.