Idea #13446
closed
[keepstore] secure keepstore traffic with TLS
Description
Background: Clients (including keepproxy) already have TLS support -- otherwise, they wouldn't be able to connect to keepproxy in a typical setup. However, keepstore itself does not have built-in support for TLS, and setting up Nginx alongside each keepstore is a burden.
Load certificate and key from configured location (e.g., /var/lib/acme/live/...) at startup- If cert+key cannot be loaded, error out
- If cert+key cannot be loaded, log a warning and continue using old cert+key
If cert+key locations are not configured, just serve plain http as before.
https://blog.gopheracademy.com/advent-2016/exposing-go-on-the-internet/
The job of obtaining and renewing certificates and copying them to the appropriate locations is left to the operator. The easiest solution is probably to allow traffic on port 80 to keepstore nodes and use acmetool's "redirector" validation strategy. One could also obtain a certificate on a different node using split-horizon DNS or DNS validation, then copy it to the keepstore node.
Updated by Tom Morris over 6 years ago
- Target version set to 2018-05-23 Sprint
- Story points set to 1.0
Updated by Tom Clegg over 6 years ago
- Description updated (diff)
13446-keepstore-tls @ b4a283a9f142209b22fabda98ea2573cf0dbe281
New config parameters added:
TLSCertificateFile:
Path to server certificate file in X509 format. Enables TLS mode.
Example: /var/lib/acme/live/keep0.example.com/fullchain
TLSKeyFile:
Path to server key file in X509 format. Enables TLS mode.
The key pair is read from disk during startup, and whenever SIGHUP
is received.
Example: /var/lib/acme/live/keep0.example.com/privkey
Updated by Tom Clegg over 6 years ago
Updated by Tom Clegg over 6 years ago
checked with ops about config/docs in note-4 → "sounds reasonable"
Updated by Peter Amstutz over 6 years ago
This business of circulating the current certificate through a buffered channel seems excessively clever compared to a plain old mutex, but it seems to be sound.
LGTM.
Updated by Ward Vandewege over 6 years ago
- Status changed from In Progress to Resolved