ACME-CLIENT.CONF(5)

🎀 acme-client.conf(5) — the file formats manual, bestie edition 💅

okay so you're here because you've got an acme-client.conf file and you want to know what goes in it. say less — this is the <italic>file formats manual</italic> for acme-client.conf, and we're gonna go through it together, section by section, no cap. 🦋

---

✨ NAME ✨

acme-client.conf — the acme-client configuration file. that's it, that's the name, she's iconic 👑

---

🌸 DESCRIPTION 🌸

the acme-client.conf file is split into these main sections, and yes you need to know all of them:

• “Macros” — definitions of variables that you can use later, which keeps the config file from being a whole mess. lowkey a lifesaver 🫶
• “Authorities” — certificate authorities (CAs) that can be contacted via ACME.
• “Domains” — certificate specifications. the actual good stuff.

you can pull in extra config files with the include keyword, like literally:

include "/etc/acme-client.sub.conf"

the current line can be stretched over multiple lines using a backslash (\). comments can go anywhere in the file with a hash mark (#), and they run to the end of the current line. ⚠️ but be careful when you're commenting out multi-line text: the comment is effective until the end of the entire block — so yeah, it eats the whole thing, not just one line. 💀

also: arguments that don't begin with a letter, a digit, an underscore, or / must be quoted. no exceptions, bestie, the parser is not playing around.

---

🧚 Macros

a macro gets defined with a command like name=value. the macro name can contain letters, digits, and underscores — but it cannot be a reserved word, so don't try it. 🙈 inside unquoted arguments, the string $name gets expanded to value later on.

for example, look how clean this is:

api_url="https://acme-v02.api.letsencrypt.org/directory"
authority letsencrypt {
        api url $api_url
        account key "/etc/acme/letsencrypt-privkey.pem"
}

see how $api_url just slots in? obsessed. ✨

---

👑 Authorities

these are the configured certificate authorities.

each authority section starts with a declaration of the name that identifies a certificate authority.

authority name {...} the name is a string used to reference this certificate authority.

then it's followed by a block of options wrapped in curly brackets:

• account key file [keytype] — specifies a file used to identify the user of this certificate authority. keytype can be rsa or ecdsa, and it defaults to rsa.
• api url url — specifies the url under which the ACME API is reachable.
• contact contact — optional contact URLs that the authority can use to contact the client about issues related to this account. 🫶

---

🦋 Domains

these are the certificates to be obtained through ACME.

domain handle {...} each domain section begins with the domain keyword followed by an identifier for this domain block. usually that identifier is the domain name — but if you're requesting certificates of different types (EC and RSA) for the same name, the handle identifiers should be unique and you should use the domain name directive instead. iykyk 💅

then comes a block of options in curly brackets:

• domain name name — the name to be used as the primary Subject Alternative Name (SAN) in the X.509 certificate. this is optional; if you don't specify it, the handle of the domain block gets used instead.
• alternative names {...} — a list of additional names, comma or space separated, for which the certificate will be valid. if the CA and the selected profile support it, you can use fully qualified domain names, IPv4, or IPv6 addresses. 🎀 there is no automatic conversion/inclusion between the "www." form and the plain domain name form — so don't assume, write it out.
• domain key file [keytype] — the private key file for which the certificate will be obtained. keytype can be rsa or ecdsa, and it defaults to rsa. if the key file doesn't exist, acme-client(1) will generate a key itself (4096-bit for rsa or secp384r1 for ecdsa). she's self-sufficient 💅
• domain certificate file — the filename of the certificate that will be issued. this is optional if domain full chain certificate is specified. a backup with name file.1 is created if file exists.
• domain chain certificate file — the filename in which to store the certificate chain that will be returned by the certificate authority. it needs to be in the same directory as the domain certificate (or in a subdirectory) and can be specified as a relative or absolute path. this setting is optional. a backup with name file.1 is created if file exists.
• domain full chain certificate file — the filename in which to store the full certificate chain that will be returned by the certificate authority. it needs to be in the same directory as the domain certificate (or in a subdirectory) and can be specified as a relative or absolute path. this is a combination of the domain certificate and the domain chain certificate in one file, and most browsers straight up require it. this is optional if domain certificate is specified. a backup with name file.1 is created if file exists. 🔥
• profile profile — the certificate profile to be requested. if this setting is absent, no profile request is made.
• sign with authority — the certificate authority (as declared above in the “Authorities” section) to use. if this setting is absent, the first authority specified is used.
• challengedir path — the directory in which the challenge file will be stored. if it's not specified, a default of /var/www/acme is used.

---

🎀 FILES 🎀

• /etc/acme-client.conf — acme-client(1) configuration file.
• /etc/examples/acme-client.conf — example configuration file. (go look at it, fr fr 👀)

---

💖 SEE ALSO 💖

acme-client(1)

---

⭐ HISTORY ⭐

the acme-client.conf file format first appeared in OpenBSD 6.1. she's been serving since day one, periodt. 🌈

---

🌸 and that's the whole page, bestie — go write a config that slays. 💅

this was the Debian build of acme-client.conf(5), dated February 23, 2026 — mwah, bye! 💜🎀