pub struct TlsConfig {
pub certificate: String,
pub key: String,
pub client_ca: Option<String>,
pub crl: Option<String>,
}Expand description
Where the server’s own certificate, key and client CA live.
Its presence is what turns TLS on; there is no enabled key, because a
block that names a certificate and does nothing is a deployment that
believes it is encrypted and is not.
[server.tls]
certificate = "/etc/dynamic-config/server.pem"
key = "/etc/dynamic-config/server.key"
client_ca = "/etc/dynamic-config/clients-ca.pem" # optional; see belowOnly paths live here. The key’s bytes are read once, at startup, by
Tls::load, and never reach a diagnostic — see
TlsError.
Fields§
§certificate: StringPEM holding the server’s certificate, then any intermediates, leaf first.
key: StringPEM holding that certificate’s private key: PKCS#8, PKCS#1 or SEC1.
On Unix the server refuses to start if this file is readable by anything but its owner, for the same reason it refuses a token under 32 characters.
client_ca: Option<String>PEM holding the certificate authority every client certificate must chain to.
Present means mutual TLS is required: a caller that presents no certificate, or one signed by anything else, does not complete the handshake and never becomes a request. Absent means the server authenticates itself to callers and asks for nothing back.
A certificate is a second gate, never a second identity: it is not an
alternative to the bearer token and it does not name a caller. See
the tls module.
No revocation is checked. A certificate that chains here is good
until it expires; see crl.
crl: Option<String>A certificate revocation list — a startup refusal, never a file this server reads.
The key exists so that an operator who reaches for revocation is told
that this server does not check it, rather than being told unknown field 'crl' and going looking for a different spelling. It is the
same reason tls itself is parsed in a build
without the feature: a security-relevant key that reads as a typo is
worse than one that reads as a decision.
The decision, and it was measured rather than assumed
(RevocationUnsupported’s message is the short form): rustls will
accept a CRL whose nextUpdate passed years ago without a word,
because ExpirationPolicy::Ignore is the default — so the twenty
lines that look like revocation are a check that stops being true the
moment the file stops being refreshed, with nothing anywhere
reporting it. The one switch that refuses a stale list,
enforce_revocation_expiration, refuses every client while it is
stale, which turns a CRL publishing hiccup into a fleet-wide
configuration outage. Neither is a posture this crate will ship, and
a file watcher does not rescue it: the failure to catch is the
absence of a write, and no filesystem event fires for that.
What to do instead is in tls: short-lived client
certificates, and revoke the bearer token — the credential that
actually authorises, and the one this server can withdraw by removing
a line.