Learn DragonFlyBSD - TLS, OpenSSL & Certificates

#Introduction

In episode 13 you secured SSH — the encrypted channel for administration. But public services like web servers need a different kind of encryption: TLS, which ensures that data crossing the internet can't be read or altered by someone in the middle. This episode covers its foundations: OpenSSL, certificates, and PKI.

Imagine TLS as a sealed envelope with an official stamp. The envelope (encryption) ensures no one else can read the contents; the official stamp (a certificate from a CA) ensures the sender really is who they claim to be. This episode teaches you how to make your own seal, how to get an official stamp from Let's Encrypt, and how to verify a stamp's authenticity.

#OpenSSL

#Installation and Verification

OpenSSL is usually already included in the crypto set during installation. Verify its presence:

openssl version
pkg install ca-certificates

The ca-certificates package provides the trusted set of public CAs — important so your system can verify other servers' certificates.

#Generating Keys, CSRs, and Certificates

The standard certificate flow: create a key (private key), create a CSR (Certificate Signing Request), then have it signed into a cert. For an internal CA or self-signed:

openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -days 365 -nodes

-x509 directly produces a self-signed certificate; -newkey rsa:2048 creates a 2048-bit RSA key; -nodes leaves the key unencrypted (common for services). To request a certificate from an external CA:

openssl req -newkey rsa:2048 -keyout server.key -out server.csr -nodes

This CSR is what you send to the CA (for example Let's Encrypt), and the CA returns the certificate.

#Verifying Certificates

Inspect a certificate's contents and validity:

openssl x509 -in server.crt -text -noout
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt server.crt

openssl x509 -text shows certificate details — including validity period and subject. openssl verify checks the trust chain against known CAs.

#Certificate Management

#Let's Encrypt with acme-client

For publicly trusted certificates that browsers accept, Let's Encrypt is the free, automatic choice. DragonFlyBSD provides acme-client — OpenBSD's minimal ACME client:

pkg install acme-client

Configuration in /etc/acme-client.conf defines the domains and validation method:

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

Then run it to get the certificate:

acme-client example.com

#acme.sh: A Popular Alternative

acme.sh is a shell-based ACME client that supports many DNS providers:

pkg install acme.sh
acme.sh --issue -d example.com --standalone

Both produce equally valid certificates; choose whichever fits your workflow. The important thing: automate renewal (cron + service reload) so your certificates never expire.

#PKI Basics

A few concepts worth understanding:

Understanding this hierarchy helps you read TLS errors: when a browser complains "untrusted", it's usually because the chain is incomplete or the CA is unknown.

#Connecting It to a Service

Certificates are used by web servers and other services. For httpd/nginx, point the SSL certificate to the generated files:

ssl_certificate /etc/ssl/example.com.fullchain.pem
ssl_certificate_key /etc/ssl/private/example.com.key

After a certificate renewal, reload the service so the latest version is applied.

#Closing

In this episode 14 you mastered TLS and certificates on DragonFlyBSD: generating keys, CSRs, and certs with openssl req, verifying with openssl x509 and openssl verify, managing ca-certificates, getting Let's Encrypt certificates with acme-client or acme.sh, and understanding the basic concepts of PKI.

Key takeaways:

• openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -days 365 -nodes creates a self-signed certificate.
• openssl verify -CAfile ... checks the chain of trust against a CA.
• The ca-certificates package is required for your system to verify other servers.
• Let's Encrypt via acme-client or acme.sh gives free certificates; automate renewal.
• Understand the PKI hierarchy — root CA, intermediate, fullchain — to read TLS errors.

In the next episode, episode 15, we strengthen the entire system: security features & hardening. You'll set sysctl security settings, make use of PaX-like mitigations and ASLR, apply best practices, and monitor with tcpdump, netstat, and systat.