Profiles are named templates in the policy file that define what kind of certificate is issued, which DNS names are covered, and how ACME challenges are performed. Each profile is referenced by name from host entries, and a host can only request profiles it has been explicitly granted access to. You can define as many profiles as you need to represent different certificate classes across your infrastructure.Documentation Index
Fetch the complete documentation index at: https://certplane.kippel.org/llms.txt
Use this file to discover all available pages before exploring further.
Profile fields
The type of certificate to issue.
wildcard— issues a single-wildcard certificate (e.g.,*.example.com)multi— issues a certificate with multiple explicit Subject Alternative Names as listed indns_names
The DNS names to include on the certificate. Provide at least one entry.For
wildcard profiles this is typically a single wildcard name such as *.example.com. For multi profiles, list every SAN the certificate should cover.The ACME challenge type the broker uses to prove domain control.
dns-01— broker creates a TXT record in your DNS provider. Required for wildcard certificates.http-01— broker serves a token over HTTP on port 80. Only valid for non-wildcard names.
The requested certificate lifetime. Accepts Go duration strings such as
2160h (90 days) or 4320h (180 days).How early the broker renews a cached certificate. The broker checks whether less than this duration remains before the certificate expires, and if so, requests a new one. Accepts Go duration strings such as
720h (30 days).The
ttl field is ignored by Let’s Encrypt. Let’s Encrypt always issues certificates with a 90-day lifetime regardless of what you request. The field is useful if you are using a private ACME CA that honours the requested TTL.