adam/jarl
1
0 Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases 34 Wiki Activity

TLS certificates: Jarl obtains and renews them over ACME

Browse Source 
Jarl is now an ACME client (lego's core, no DNS providers). It answers
DNS-01 challenges in a zone it serves, or through Porkbun's DNS API while
Porkbun serves the domain; "auto" decides from the domain's public name
servers at every renewal, and a CNAME on _acme-challenge is followed.
Certificates are used for jarld's HTTPS (served without a restart; each
port speaks HTTPS and plain HTTP, plain HTTP from loopback and trusted
proxies still served) and/or written for named's DNS over TLS/HTTPS, with
rndc reconfig on renewal. Renewal follows the CA's ARI window or two
thirds of the lifetime, with back-off. Certificates you renew yourself
can be used too. Certificates page and dashboard card, jarl cert,
/api/v1/certificates, Prometheus gauges, docs/certificates.md, and an
e2e section against Pebble.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
adamandClaude Opus 5.5 committed 2026-10-12 14:35:53 +01:00
1 parent 88965096bb
commit 88f63ffb0a
43 files changed
+4584 -45
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/acme.md
+6
View File
@@ -1,5 +1,11 @@
# Let's Encrypt (ACME DNS-01) with Jarl
This page is about **other** ACME clients (certbot, acme.sh, lego,
Traefik) publishing their DNS-01 challenges through Jarl. For
certificates for the DNS server itself (Jarl's web UI, named's DNS over
TLS and HTTPS), Jarl can be the ACME client: see
[certificates.md](certificates.md).
The DNS-01 challenge proves that you control a domain by publishing a TXT
record at `_acme-challenge.<domain>`. Jarl does this through its API, so no
dynamic updates (`allow-update`, nsupdate) are needed. That matters because
docs/api.md
+17
View File
@@ -541,6 +541,23 @@ Needs `stats:read`. When statistics are disabled, every endpoint but
curl -sf -H "$AUTH" "$API/stats/top?kind=nxdomain&since=7d&limit=10" | jq -r '.[] | "\(.count)\t\(.key)"'
```
### Certificates
Administrators only. See [certificates.md](certificates.md#api).
| Method | Path | Body |
|--------|------|------|
| GET | `/certificates` | `certificates` (with `status`, `next_attempt`, `issuing_since`, `serving`, `files`) and `account` |
| POST | `/certificates` | `{"name", "domains", "uses", "challenge", "key_type", "comment"}`, or `{"name", "source": "file", "cert_file", "key_file", "uses"}`; `"issue": false` doesn't start obtaining it |
| POST | `/certificates/check` | `{"domains", "challenge"}`: the route of each challenge |
| GET, PATCH, DELETE | `/certificates/{name}` | |
| POST | `/certificates/{name}/issue` | 202: being obtained (poll until `issuing_since` is gone); a file certificate is reread (200) |
| POST | `/certificates/{name}/check` | the routes of a certificate's names |
`GET /status` includes `certificates` for administrators: `total`,
`problems` (failing, expiring, expired), `next` and `next_after`,
`serving`.
### ACME: lego's httpreq provider
Off unless `acme.httpreq.enabled` is set, and by default HTTPS only. The
docs/certificates.md
+252
View File
@@ -0,0 +1,252 @@
# TLS certificates
Jarl can obtain TLS certificates from an ACME CA (Let's Encrypt by
default) and renew them itself, and put them where they are used:
- **web**: jarld's own HTTPS (the web UI, the API and the CLI's server).
- **dns**: files named can read, for DNS over TLS (DoT) and DNS over HTTPS
(DoH) in named's `tls` blocks.
One certificate can have both uses. Jarl answers the ACME DNS-01
challenge itself: in a zone it serves, or through Porkbun's API while
Porkbun still serves the domain. So no other ACME client, hook script or
DNS provider plugin is needed, and the server doesn't have to be
reachable on port 80 or 443 from the internet.
A certificate you renew some other way (certbot, acme.sh, your own CA)
can be used too: Jarl reads it from its files and rereads it when they
change.
In the web UI: **Certificates** (administrators). In the CLI: `jarl cert`.
In the API: `/api/v1/certificates`. All of it is for administrators only:
a certificate's key can impersonate your server.
## Quick start
1. Set up the ACME account in `/etc/jarl/jarl.yaml` and restart jarld
(`systemctl restart jarl`). Try Let's Encrypt's staging CA first: its
certificates aren't trusted by browsers, but its rate limits are
generous, so mistakes cost nothing.
```yaml
acme:
account:
directory: letsencrypt-staging # then: letsencrypt
email: you@adbraun.lol # optional
agree_tos: true # after reading https://letsencrypt.org/repository/
```
2. See where the challenges would go, without asking the CA for anything:
```sh
jarl cert check --domain ns1.adbraun.lol
```
```
NAME ROUTE RECORD WHY
ns1.adbraun.lol porkbun _acme-challenge.ns1.adbraun.lol adbraun.lol is served by Porkbun (curitiba.ns.porkbun.com, ...), so the record goes in through Porkbun's API
```
3. Create the certificate. Jarl obtains it at once; the command waits for
the outcome (usually under a minute, a few minutes through Porkbun):
```sh
jarl cert create ns1 --domain ns1.adbraun.lol --use web --use dns
```
4. When it works, switch `directory` to `letsencrypt`, restart jarld and
renew: `jarl cert issue ns1`.
From then on jarld renews it by itself.
## The ACME account
| Setting | Default | |
|--|--|--|
| `acme.account.directory` | `letsencrypt` | `letsencrypt`, `letsencrypt-staging`, or the directory URL of another ACME CA (ZeroSSL, Google, step-ca, ...). |
| `acme.account.email` | `""` | Contact address for the CA (optional; Let's Encrypt no longer sends expiry mails). |
| `acme.account.agree_tos` | `false` | You accept the CA's terms of service. Jarl registers no account without it, and says so. |
| `acme.account.eab_kid`, `eab_hmac` | `""` | External Account Binding, for CAs that need it (ZeroSSL, Google): from the CA's dashboard. |
| `acme.resolvers` | `1.1.1.1:53`, `9.9.9.9:53`, `8.8.8.8:53` | Recursive resolvers Jarl uses to see a domain as the CA does (below). |
| `acme.ca_bundle` | `""` | A PEM file of extra CA certificates to trust when talking to the ACME server (a private CA). |
| `acme.check_propagation` | `true` | Before telling the CA to look, wait until every name server of the zone serves the challenge (asked directly on port 53). |
| `certificates.dir` | `<bind.config_dir>/tls` | Where certificates with the dns use are written for named. |
The account is registered with the first certificate, and its key is
kept in Jarl's database. Changing `directory` registers a new account with
that CA; changing `email` updates the account.
## Where the challenge goes
For each name on a certificate, the CA looks up a TXT record at
`_acme-challenge.<name>` (a wildcard `*.example.com` uses
`_acme-challenge.example.com`). Jarl first looks the name up the way the
CA will, through `acme.resolvers` (public resolvers, not this server,
which may answer from an internal view), following a CNAME on
`_acme-challenge` if there is one. Then it finds the zone that holds the
record on the internet and that zone's public name servers:
| The zone's public name servers | Route | Jarl writes the record |
|--|--|--|
| Porkbun's (`*.ns.porkbun.com`), with `porkbun.api_key` set | `porkbun` | through Porkbun's DNS API (TTL 600, Porkbun's minimum), and deletes it afterwards. The key is the one the registrar features use ([configuration.md](configuration.md#porkbun-registrar-and-dns-host)); it needs DNS record write access, "API Access" switched on for the domain, and the domain in `porkbun.domains` if you set that |
| the name servers in Jarl's own zone of that name | `jarl` | in that zone, in every view that has it, as a change by `system` (in the history) |
| anything else | none | nowhere: the certificate fails with what to do |
The certificate's `challenge` setting chooses:
- **`auto`** (the default) decides again at **every** issue and renewal.
While Porkbun serves `adbraun.lol`, the challenge goes to Porkbun. Once
you point the domain's name servers at your own servers, the next
renewal writes into Jarl's zone instead. Nothing needs changing.
- **`jarl`** or **`porkbun`** pins the route. Jarl still checks that the
CA will see the record there and refuses to try otherwise (no wasted
attempt against the CA's rate limits).
```sh
jarl cert update ns1 --challenge porkbun # or jarl, or auto
```
`jarl cert check NAME` (or **Check the names** in the web UI) shows the
route for each name, and why, at any time.
### Domains Jarl can't write to: a CNAME
For a domain whose DNS is elsewhere (Cloudflare, say), point the
challenge name at a zone this server serves on the internet, once, by
hand:
```
_acme-challenge.www.example.org. CNAME www-example-org.acme.adbraun.lol.
```
Jarl follows the CNAME and writes the record at its target, in its zone
`acme.adbraun.lol` (which must be delegated to this server). Renewals
never touch the other provider again. That is the same idea as
[acme.md section 7](acme.md#7-a-dedicated-acme-zone-cname-delegation).
## Renewal
jarld looks at every certificate every 10 minutes:
- A certificate Jarl obtains is renewed at the time the CA suggests
(ACME Renewal Information, RFC 9773; asked twice a day, so a CA that
needs to replace certificates early, e.g. after revoking them, gets its
way), or, without one, two thirds into its lifetime: day 60 of a 90-day
certificate. Each renewal makes a new key.
- When obtaining fails, jarld tries again after 1, 2, 4, 8, 16 hours, then
daily. The dashboard and the Certificates page show the error; so do
`jarl cert list` and Prometheus (`jarl_certificate_failing`).
- New names or a new key type on a certificate make it due at once.
- `jarl cert issue NAME` (**Renew** in the web UI) obtains it now. It runs
in the background: the command waits and reports, the web page updates
itself.
A certificate counts as **expiring** (a warning) when less than a sixth of
its lifetime is left, which for a renewing certificate means renewal has
been failing for a while; and **expired** after its end.
## Use: web (jarld's HTTPS)
Only one certificate can have the web use. As soon as it has been
obtained, jarld serves it on all its `listen` addresses, **without a
restart**: each port speaks HTTPS and plain HTTP side by side.
- HTTPS connections get the certificate (HTTP/2 included).
- Plain HTTP from this server itself (`127.0.0.1`, `::1`) is served as
before, so local scripts and `--server http://127.0.0.1:8053` keep
working. So is plain HTTP from `trusted_proxies`.
- Plain HTTP from anywhere else: browsers are redirected to
`https://<the same host and port>`; API requests get `400
https_required` (and, if they carried a token, a note that it crossed
the network unencrypted).
Point browsers and CLIs at the certificate's name:
`jarl config set server https://ns1.adbraun.lol:8053`. A CLI that uses the
server's IP address fails the name check.
A managed certificate takes over from `tls.cert_file`. Taking the web use
off (or deleting the certificate) goes back to `tls.cert_file`, or to
plain HTTP.
## Use: dns (for named)
Jarl writes the certificate to `<certificates.dir>/<name>/`:
```
/etc/bind/jarl/tls/ns1/fullchain.pem (0644)
/etc/bind/jarl/tls/ns1/privkey.pem (0640, group bind)
```
Debian's AppArmor profile lets named read `/etc/bind`, and group `bind`
lets it read the key. When a renewal changes the files and named's
configuration names them, Jarl runs `rndc reconfig`, and named serves the
new certificate at once (checked with BIND 9.20: DoT keeps working, with
the new certificate).
Until Jarl sets up DNS over TLS and HTTPS for you, add it by hand:
```sh
jarl option set tls 'dot { cert-file "/etc/bind/jarl/tls/ns1/fullchain.pem"; key-file "/etc/bind/jarl/tls/ns1/privkey.pem"; }' --toplevel
jarl option set listen-on 'port 853 tls dot { 10.0.10.5; }' --add # DoT
jarl option set listen-on 'port 443 tls dot http default { 10.0.10.5; }' --add # DoH at /dns-query
```
Listen on internal addresses only, unless you mean to run a public
resolver ([exposure.md](exposure.md)).
## A certificate you renew yourself
```sh
jarl cert create own --cert-file /etc/ssl/ns1/fullchain.pem --key-file /etc/ssl/ns1/privkey.pem --use web
```
Jarl checks that the key belongs to the certificate, warns when the file
holds only the certificate without its intermediates (use the full
chain), and rereads both files when they change (within 10 minutes, or at
once with `jarl cert issue own`). A pair that doesn't match is reported
and the last good one stays in use. jarld runs as user `jarl`, which must
be able to read both files (e.g. `chgrp jarl` and `chmod 640`, or have
your renewal hook copy them somewhere it can read).
## Security notes
- Certificates Jarl obtains, their keys and the ACME account key are kept
in Jarl's database, so they are in its backups (like TSIG secrets). The
API never returns a key.
- Every publicly trusted certificate is published in Certificate
Transparency logs, with all its names. A name like `ns1.adbraun.lol`
used for both the web UI and DNS reveals less than separate names. Avoid
wildcards where one name will do: a wildcard's key is good for every
name in the domain.
- Using one certificate for jarld and named puts its key in two places.
On one server, where jarld already writes named's configuration, that
changes little.
## API
| Method | Path | |
|--|--|--|
| GET | `/certificates` | `certificates` (each with `status` {`state`: ok, pending, failing, expiring, expired; `message`}, `next_attempt`, `issuing_since` while being obtained, `serving`, `files`) and `account` |
| POST | `/certificates` | `{"name": "ns1", "domains": [...], "uses": ["web", "dns"], "challenge": "auto", "key_type": "ec256"}`, or `{"name", "source": "file", "cert_file", "key_file", "uses"}`. One Jarl obtains starts being obtained at once (`"issue": false` leaves it to the loop) |
| POST | `/certificates/check` | `{"domains": [...], "challenge": "auto"}`: where each challenge would go (`routes`: `route`, `target`, `zone`, `public_ns`, `why` or `error`) |
| GET, PATCH, DELETE | `/certificates/{name}` | `domains` and `uses` replace the whole list |
| POST | `/certificates/{name}/issue` | obtain now: 202, then poll `GET /certificates/{name}` until `issuing_since` is gone; a file certificate is reread (200) |
| POST | `/certificates/{name}/check` | the routes for an existing certificate |
## Testing with Pebble
[Pebble](https://github.com/letsencrypt/pebble) is Let's Encrypt's test
CA. Point it at a test named, and Jarl at it:
```sh
docker run -d --name pebble --network host -e PEBBLE_VA_NOSLEEP=1 \
ghcr.io/letsencrypt/pebble -config test/config/pebble-config.json -dnsserver 127.0.0.1:53
docker cp pebble:/test/certs/pebble.minica.pem /etc/jarl/pebble.pem
```
```yaml
acme:
account: {directory: "https://localhost:14000/dir", agree_tos: true}
resolvers: ["127.0.0.1:53"]
ca_bundle: /etc/jarl/pebble.pem
```
docs/cli.md
+18
View File
@@ -397,6 +397,24 @@ jarl view update external --exposure public|private|auto
See [exposure.md](exposure.md).
## Certificates
```sh
jarl cert check --domain ns1.adbraun.lol # where each challenge would go, and why
jarl cert create ns1 --domain ns1.adbraun.lol --use web --use dns # obtained at once; waits
jarl cert create wild -d adbraun.lol -d '*.adbraun.lol' --use dns --key-type ec384
jarl cert create own --cert-file /etc/ssl/ns1/fullchain.pem --key-file /etc/ssl/ns1/privkey.pem --use web
jarl cert list
jarl cert show ns1
jarl cert issue ns1 # renew now (--no-wait to return at once)
jarl cert update ns1 --challenge porkbun # auto, jarl or porkbun
jarl cert update ns1 --use dns # --use and --domain replace the list (--use none)
jarl cert delete ns1
jarl cert account # the ACME account (set in jarl.yaml)
```
Administrators only. See [certificates.md](certificates.md).
## Views, ACLs, TSIG keys, options, settings
```sh
docs/configuration.md
+33 -7
View File
@@ -20,7 +20,7 @@ The CLI has its own small configuration file, described in [cli.md](cli.md).
|-----|---------|---------|
| `listen` | `["127.0.0.1:8053"]` | Addresses to listen on (`host:port`, several allowed). Keep these on localhost and management networks. Ports below 1024 (`"192.168.10.2:443"`) work because `jarl.service` gives jarld the `CAP_NET_BIND_SERVICE` capability, and only that ([HTTPS on port 443](#example-https-on-port-443)). |
| `socket` | `/run/jarl/jarl.sock` | A local unix socket for the API. Requests on it from root or jarld's own user need no token and have administrator rights; anyone else must send a token ([permissions.md](permissions.md#the-local-socket)). The `jarl` CLI uses it when no server is configured. At most 107 bytes long; `""` turns it off. If it can't be created, jarld logs a warning and serves the network addresses only. |
| `tls.cert_file`, `tls.key_file` | (empty: plain HTTP) | PEM certificate chain and key. Both or neither. The files are rechecked every 10 minutes and on SIGHUP (`systemctl reload jarl`), so renewed certificates are used without a restart. |
| `tls.cert_file`, `tls.key_file` | (empty: plain HTTP) | PEM certificate chain and key. Both or neither. The files are rechecked every 10 minutes and on SIGHUP (`systemctl reload jarl`), so renewed certificates are used without a restart. Easier: let Jarl obtain and renew one ([certificates.md](certificates.md), use `web`), which takes over from these. With a certificate, the `listen` ports serve HTTPS and plain HTTP side by side: plain HTTP is still served to this server itself and to `trusted_proxies`; anyone else is sent to HTTPS. |
| `trusted_proxies` | `[]` | Addresses or prefixes of reverse proxies whose `X-Forwarded-For` and `X-Forwarded-Proto` (or `Forwarded: proto=`) headers are believed. Needed for correct client IPs in the audit log and for rate limiting behind a proxy, and for knowing that a proxied request came over HTTPS (the session cookie's Secure flag, `acme.httpreq`). From other addresses these headers are ignored. |
| `session.lifetime` | `12h` | A web session ends this long after login... |
| `session.idle_timeout` | `2h` | ...or after this long without requests. |
@@ -85,6 +85,23 @@ configuration. Changing it takes effect when jarld restarts.
Query counters need `stats.enabled` as well. Changes take effect when jarld
restarts.
### Certificates (ACME account)
The account Jarl obtains certificates with, and where it writes them for
named. See [certificates.md](certificates.md). Changes take effect when
jarld restarts.
| Key | Default | Meaning |
|-----|---------|---------|
| `acme.account.directory` | `letsencrypt` | `letsencrypt`, `letsencrypt-staging` or an ACME directory URL (`https://...`). |
| `acme.account.email` | `""` | Contact address for the CA (optional). |
| `acme.account.agree_tos` | `false` | You accept the CA's terms of service; no account is registered without it. |
| `acme.account.eab_kid`, `acme.account.eab_hmac` | `""` | External Account Binding, for CAs that need it. Both or neither. Keep the file readable only by root and jarld. |
| `acme.resolvers` | `["1.1.1.1:53", "9.9.9.9:53", "8.8.8.8:53"]` | Recursive resolvers (`address:port`) used to see domains as the CA does: their zone, public name servers, and a CNAME on `_acme-challenge`. Not this server: it may answer from an internal view. |
| `acme.ca_bundle` | `""` | PEM file of extra CA certificates to trust for the ACME server (a private CA). |
| `acme.check_propagation` | `true` | Wait until every name server of the zone serves a challenge before the CA is told to look (they are asked directly, on port 53). |
| `certificates.dir` | `<bind.config_dir>/tls` | Where certificates with the `dns` use are written for named: `<dir>/<name>/fullchain.pem` and `privkey.pem`. |
### ACME (lego httpreq endpoint)
An endpoint for lego's `httpreq` DNS provider, so lego and Traefik can
@@ -126,18 +143,27 @@ there (`ReadWritePaths`). If you change them, update both
ReadWritePaths=/srv/bind/jarl /srv/bind/zones
```
### Porkbun (registrar)
### Porkbun (registrar and DNS host)
With an API key, Jarl can show and set a domain's name servers, glue
records and DNSSEC DS records at Porkbun, after checking that the change
won't break the domain ([dnssec.md](dnssec.md#porkbun)). Without a key
(the default) nothing about Porkbun shows up.
With an API key, Jarl can:
- show and set a domain's name servers, glue records and DNSSEC DS records
at Porkbun, after checking that the change won't break the domain
([dnssec.md](dnssec.md#porkbun));
- publish the DNS-01 challenges of certificates it obtains while Porkbun
still serves the domain's DNS ([certificates.md](certificates.md#where-the-challenge-goes)):
it only adds TXT records at `_acme-challenge` names and removes them
again.
Without a key (the default) nothing about Porkbun shows up, and
certificates for domains Porkbun serves can't be obtained (`jarl cert
check` says so).
| Key | Default | Meaning |
|-----|---------|---------|
| `porkbun.api_key` | `""` | The API key (`pk1_...`). Set both or neither. |
| `porkbun.secret_api_key` | `""` | Its secret (`sk1_...`). |
| `porkbun.domains` | `[]` | Only these domains (default: every primary zone the key can reach). |
| `porkbun.domains` | `[]` | Only these domains, for both uses (default: any domain the key can reach). |
The key can move your domain anywhere, so it is only ever read from this
file: it isn't stored in the database or backups, and there is no API to
docs/development.md
+7 -1
View File
@@ -118,7 +118,13 @@ checker tests work with the installed `bind9-utils` too.
ACME hooks, DNSSEC signing, backup and restore with keys, audit) and checks
the answers with `dig`. The Porkbun code is tested against
`porkbun.Fake`, an in-memory stand-in for its API; nothing calls the real
one. `KEEP=1` leaves named
one. With Docker, certificates are tested end to end against
[Pebble](https://github.com/letsencrypt/pebble), Let's Encrypt's test CA
(`ghcr.io/letsencrypt/pebble`, host network, ports 14000 and 15000),
which checks the challenges against the test named: obtaining, HTTPS
from jarld, DNS over TLS from named, renewal. `PEBBLE=0` skips that; the
certs package's own tests use a fake DNS server and `porkbun.Fake`, and
never a real CA. `KEEP=1` leaves named
and jarld running afterwards. The output says where; set `JARL_CLI_CONFIG`
to that directory's `cli.yaml` to keep using the CLI against it.
docs/dnssec.md
+7 -3
View File
@@ -175,13 +175,17 @@ Before you go public:
## Porkbun
With a Porkbun API key, Jarl manages a domain's name servers, glue records
and DS records at Porkbun, and checks each change before making it.
and DS records at Porkbun, and checks each change before making it. The
same key also lets Jarl publish the DNS-01 challenges of its own
certificates while Porkbun serves the domain's DNS
([certificates.md](certificates.md#where-the-challenge-goes)).
**Setting it up**
1. At porkbun.com, *Account → API Access*: create a key. If you can,
limit it to the domain and the permissions it needs (domains, read),
and to your server's address.
limit it to the domain and the permissions it needs, and to your
server's address. The registrar features need the domain permissions;
certificate challenges need DNS record write access too.
2. On the domain's page, switch **API Access** on (Porkbun refuses API
calls for a domain until you do).
3. Put the key in `/etc/jarl/jarl.yaml` and restart jarld:
docs/metrics.md
+12
View File
@@ -129,6 +129,9 @@ same values.
| `jarl_blocklist_last_check_timestamp_seconds{list}`, `jarl_blocklist_last_change_timestamp_seconds{list}` | When the list was last checked, and last changed. |
| `jarl_dnssec_phase{zone,view,phase}` | Always 1, one per signed zone; `phase` is one of the [DNSSEC phases](dnssec.md). `ready` means: add the DS at the parent. `removing_ds`: remove it. |
| `jarl_token_expiry_timestamp_seconds{id,user,token}` | When each API token with an expiry date expires. |
| `jarl_certificate_expiry_timestamp_seconds{certificate,source}` | When each certificate Jarl manages expires ([certificates.md](certificates.md)). |
| `jarl_certificate_failing{certificate,source}` | 1 when obtaining (or reading) the certificate failed the last time, or it has expired. |
| `jarl_certificate_renewal_failures{certificate}` | Failed attempts to obtain a certificate since its last success. |
### Queries (with `stats.enabled`)
@@ -220,6 +223,15 @@ groups:
expr: jarl_token_expiry_timestamp_seconds - time() < 7 * 86400
annotations:
summary: "API token {{ $labels.token }} of {{ $labels.user }} expires within a week"
- alert: CertificateFailing
expr: jarl_certificate_failing == 1
for: 12h
annotations:
summary: "Certificate {{ $labels.certificate }} can't be renewed (see the Certificates page)"
- alert: CertificateExpiresSoon
expr: jarl_certificate_expiry_timestamp_seconds - time() < 10 * 86400
annotations:
summary: "Certificate {{ $labels.certificate }} expires within 10 days"
- alert: BlockingPausedForLong
expr: jarl_blocking_paused == 1
for: 24h
docs/permissions.md
+3 -2
View File
@@ -116,8 +116,9 @@ demote or delete the last enabled administrator.
A user's permissions are a list of grants. Administrators (`admin: true`)
may do everything, and only they can manage users, see everyone's tokens,
run `resync`, wipe a zone's DNSSEC keys, and use the registrar (Porkbun,
whose key can move the domain).
run `resync`, wipe a zone's DNSSEC keys, use the registrar (Porkbun,
whose key can move the domain), and manage TLS certificates (whose keys
can impersonate the server; [certificates.md](certificates.md)).
A grant is written as: