The Certificate Is Not the Hard Part

That one line produces a working TLS certificate. It takes about two seconds, needs no account, no validation, no money. And it is trusted by absolutely nobody.

That gap—between "a certificate exists" and "a certificate is trusted"—is where every real decision about TLS lives. The cryptography is the easy part. The trust is the work.

What the certificate actually does

A TLS certificate is a signed statement. It says: this public key belongs to this name, and a party you already trust has verified that claim.

Your server holds the private key. The certificate carries the public key. When a client connects, the server presents the certificate, and the client runs a short checklist: is the signature valid, does the name match, is the issuer in my trust store, has it expired, has it been revoked. Pass all five and you get an encrypted session.

Fail any one and the browser shows a warning that scares users away from your site faster than a 500 error ever will.

Your trust store is the whole game

You do not trust certificates. You trust a small set of root certificates that ship with your operating system or browser, and you trust anything those roots have signed.

That is the entire model. A certificate authority is just an entity whose root certificate ended up in that store. Some got there through decades of audits and process. Some got there because a browser vendor decided so. A few got there and were later removed after they issued a certificate they should not have.

When you buy a certificate from a commercial CA, you are not buying cryptography. OpenSSL gives you that for free. You are buying the fact that their root is already in every trust store on earth, and that they will do the domain validation for you.

Free versus paid, honestly

Let's Encrypt issues domain-validated certificates at no cost, valid for 90 days, renewed automatically with `certbot`. For the overwhelming majority of websites and services, this is the correct answer. There is no security downgrade. The certificate is a standard X.509 certificate signed by a root that is in every trust store.

What you give up: no organization validation, no extended validation, no wildcard on the free tier in the same way, no support contract, and a 90-day lifetime that assumes your renewal automation works.

That last point is not a footnote. If `certbot` stops running, your site goes down in 90 days. You will not get an email from a salesperson. You will get a browser warning.

Commercial CAs still sell certificates. The reasons are real: some compliance regimes require OV or EV certificates, some organizations want a support line they can call, some need wildcard or multi-domain coverage under a single contract, and some simply want a warranty attached to the issuance. A certificate from a commercial CA is not a scam. It is a different product with a different price and a different set of guarantees.

If you need it, you need it. If you do not, you are paying for a phone number.

Self-signed is not a dirty word

A self-signed certificate is exactly what the first command in this article produces. It is signed by its own key, which means no CA vouches for it, which means no client will trust it by default.

For internal services—a database, an admin panel, a service mesh between your own machines—this is often fine. You distribute the certificate to the clients that need it, add it to their trust store, and move on. The encryption is just as strong. The identity guarantee is just narrower: it only means something to machines you configured by hand.

The cost is that every new client needs that certificate installed. At five machines, that is a chore. At five hundred, it is a project. At five thousand, you want an internal CA, and now you are running one.

The pieces you will actually touch

OpenSSL is the toolkit. `openssl req` generates a certificate request. `openssl x509` inspects a certificate. `openssl verify` walks a chain. `openssl ocsp` checks revocation in real time against an OCSP responder, which is faster than waiting for a CRL to be republished.

X.509 version 3 is what you will be dealing with. The extensions matter more than the base fields. `subjectAltName` lists every name the certificate covers—modern clients ignore the old Common Name field entirely for hostname matching. `keyUsage` and `extendedKeyUsage` declare what the key is allowed to do. `basicConstraints` marks whether a certificate can sign other certificates.

You configure these in an OpenSSL config file, sections in square brackets, key-value pairs underneath. The syntax is documented in `config(5)`. It is not friendly, but it is stable and it is everywhere.

Where the private key lives

`/etc/ssl/private/` with mode 600 and root ownership is the conventional answer on Linux. It is a good answer.

The private key is the certificate. Anyone who has it can impersonate your server. Anyone who has it and a copy of the certificate can do so from any machine on the network. File permissions and `sudo` are the mechanisms that keep it where it belongs.

`sudo` is governed by `/etc/sudoers`. You can restrict who may run `openssl`, who may restart `nginx`, who may touch the certificate directory. You can also log all of it, and forward the logs to a central `sudo_logsrvd` with `sudo_sendlog` if you have compliance requirements that say you must.

Most people do not. Most people should at least know the option exists.

DNS is part of the certificate story

Renewal with ACME requires the CA to reach your server or your DNS. If `systemd-resolved` is misconfigured—wrong upstream in `/etc/systemd/resolved.conf`, LLMNR doing something unexpected, DNS-over-TLS pointed at a resolver that cannot see your zone—the renewal fails silently until the certificate expires.

`resolvectl` will show you what your machine is actually resolving and through which server. It is worth running once before you assume your DNS is fine.

The part nobody warns you about

Every certificate has an expiry date, and that date will arrive whether you are ready or not.

The choice is not between "certificates" and "no certificates." The choice is between automatic renewal you have tested and manual renewal you have not. A cron job that has been running for two years without anyone checking whether it still works is not automation. It is a countdown.

The right answer for your setup depends on how many certificates you manage, how much of that management you want to hand to a third party, and how much you want to keep in your own hands. Everything in-house is more control and more responsibility. Everything outsourced is less work and less visibility. There is no configuration that gives you both, and the certificate does not care which one you pick.