diff options
| author | Mitchell Riedstra <mitch@riedstra.dev> | 2023-01-09 23:01:36 -0500 |
|---|---|---|
| committer | Mitchell Riedstra <mitch@riedstra.dev> | 2023-01-09 23:01:36 -0500 |
| commit | 7e8d29755135a4384d8c2aa8cfd24c5ddfeb7c97 (patch) | |
| tree | 951be2c46639267f229c3fd4496c0049e0ca7127 /readme.md | |
| download | acme-warehouse-7e8d29755135a4384d8c2aa8cfd24c5ddfeb7c97.tar.gz acme-warehouse-7e8d29755135a4384d8c2aa8cfd24c5ddfeb7c97.tar.xz | |
Diffstat (limited to 'readme.md')
| -rw-r--r-- | readme.md | 100 |
1 files changed, 100 insertions, 0 deletions
diff --git a/readme.md b/readme.md new file mode 100644 index 0000000..6d9c8a9 --- /dev/null +++ b/readme.md @@ -0,0 +1,100 @@ +# ACME certificate warehouse + +A pretty bare-bones docker container for storing and distributing ACME +certificates to your infrastructure. + +It will fetch certificates, encrypt the key file, generate checksums +then sign the checksums for each domain provided. + +This allows plain HTTP to serve as the transport for what is otherwise +sensitive information ( the key file, mostly ) + +It will generate both an encryption and signing key upon first start. + +To simplify usage there's an example `fetch.sh` script that can be used +to fetch the certificates from this service taking care of checksum validation, +signature checking and decryption for you if given a URL. + +It's currently setup *only* to use acme.sh and do DNS validation to route53. + +That may or may not suit your needs. This is not meant to be a generalized +solution for everyone's certificate needs, but rather a shell you can copy +and expand upon for your needs. + +It's only a few hundred lines of shell, so it's easily modified and hacked to +suit your needs. + +The general flow here is: + +``` +entrypoint.sh -> + Nginx -> serve up the certificates and keys + renewal.sh -> renew certificates if needed, every 24 hours + setup.sh -> runs `acme.sh`, then encrypts, signs and places them in the webroot +``` + +### Why? + +Ephemeral services across large swaths of disparate infrastructure where +tools like Ansible break down and give way too large of an attack surface if +automated. + +Solutions like S3 require esoteric rune-casting, and probably more code than +what you see here just to handle assuming fetching temporary credentials from +an assumed IAM role... Then lock you into a specific setup anyway. + +This also splits the access to DNS validation and certificate access even +further, if a server does managed to get compromised, you don't + +## Building + +``` +$ buildah build -t acme-warehouse . +``` + +## Running + +You may wish to bind mount `/var/acme` or create a volume for persistence. + +``` +$ podman run --env-file acme-env-file acme-warehouse +``` + +Where the `acme-env-file` contains the required environment variables. +They are: + +``` +ACME_DELEGATION_DOMAIN +ACME_EMAIL +DOMAINS +``` + +Additionally you may wish to pass in `ACMESH_FLAGS=--staging` until you've +verified that it pulls down and generates certificates as the DNS validation +limits are fairly low. + +`DOMAINS` are space or newline delimited list of domains to fetch certificates +for. That, and the subdomain wildcard will be fetched. + +You may wish to also supply AWS specific environment variables such as: + +``` +AWS_SECRET_ACCESS_KEY +AWS_ACCESS_KEY_ID +AWS_DEFAULT_REGION +``` + +If you want to encrypt with additional keys simply set: + +``` +AGE_RECIPIENTS +``` + +Generating a new key is easy with [`age-keygen`](https://github.com/FiloSottile/age) + +If you want to retrieve the key the container generated run: + +``` +podman exec <running_container_name> cat /var/acme/age.key +``` + |
