Certificates¶
cert-manager issues one certificate for every public hostname from the
letsencrypt-prod ClusterIssuer into the traefik namespace
(flux/30_config/cert-manager/wildcard-cbc-certificate.yaml):
| Name | Covers |
|---|---|
gewis.nl, *.gewis.nl |
this cluster's services, the apex and every service the old cluster publishes |
*.test.gewis.nl, *.personal.gewis.nl |
test and personal sites |
*.docker-registry.gewis.nl |
the per-committee registries on gewiscontainer, see External proxy |
gew.is, *.gew.is |
the short domain |
It is one certificate: if any name fails to validate, none of them renew, and the
config layer stays un-Ready until it does. Traefik's default
TLSStore names the secret, wildcard-cbc-gewis-nl-tls, as its default
certificate, so every route with tls: {} serves it and no app namespace holds a
copy — see Ingress.
The databases get certificates of their own from the same issuer, for exactly one
name each, so the wildcard key never leaves traefik:
| Certificate | Namespace | Name | Used by |
|---|---|---|---|
postgres-tls |
postgres |
postgres.net.gewis.nl |
Postgres |
mariadb-tls |
mariadb |
mariadb.net.gewis.nl |
MariaDB |
cert-manager checks that a challenge record is visible before asking Let's
Encrypt to validate it. --dns01-recursive-nameservers-only is required on
campus, which blocks direct queries to authoritative nameservers.
--dns01-recursive-nameservers sends that check over DoH to Cloudflare's
resolvers, 1.1.1.1 and 1.0.0.1, which serve the Cloudflare-hosted zones
fresh. The check does not go through kube-dns or the
cluster resolver, whose caches keep the NODATA answer from the
first check, before the record exists, for the zone's SOA minimum (1800 s).
The old cluster issues the same gewis.nl and gew.is names from the same
Cloudflare zones, so both cert-managers write _acme-challenge.gewis.nl and
_acme-challenge.gew.is. That is safe: Cloudflare keeps several TXT records under
one name, Let's Encrypt accepts any of them, and cert-manager's cleanup deletes a
record only when its content matches its own token. The Cloudflare API token
needs DNS edit rights on both the gewis.nl and gew.is zones.
The two names that share a TXT name with their wildcard, gewis.nl and
gew.is, are presented only after the wildcard's challenge is done, and
1.1.1.1 may still hold the TXT answer that carried only the wildcard's token
until its TTL runs out, so those two take longer than the rest. A challenge
stuck in pending with "not yet propagated" while presented=true and no
Cloudflare API errors means the record is written but 1.1.1.1 does not see it
yet:
Let's Encrypt caps duplicate certificates at 5/week for an identical name set.