Expand description
Where certificates live, in certon’s own vocabulary.
Storage is a key-value store with filesystem-like paths and
cluster-wide locking. That is a fine description of how certon persists
things, and a poor description of what it persists — so somebody who
wants their certificates in Postgres, or Vault, or a Kubernetes Secret has
to implement a key-value store with distributed locking, and then
reverse-engineer a key layout that is certon’s own convention.
Six methods and a lock protocol, to answer “where do the certificates go”.
CertStore asks the question certon actually has. Four methods, each one
about a certificate, with no path scheme to reproduce and no locking to
implement. KeyValueCertStore satisfies it over any Storage, which
is what happens by default, so nothing changes for anybody who does not
want it to.
It also stops one decision forcing another. Redirecting certificates used to mean redirecting the ACME account key and the lock files with them, because there was one interface for all three. Certificates in a database and an account key on disk is a perfectly ordinary arrangement, and it is now expressible.
§What is not here yet
OCSP staples, ACME account data and challenge state still go through
Storage directly. Certificates came first because they are the thing
people actually want to put somewhere else; the same treatment for the
other three is worth doing and is not done here.
Structs§
- KeyValue
Cert Store - A
CertStoreover anyStorage, using certon’s key layout.
Traits§
- Cert
Store - Somewhere certificates are kept.