aboutsummaryrefslogtreecommitdiff
path: root/readme.md
diff options
context:
space:
mode:
Diffstat (limited to 'readme.md')
-rw-r--r--readme.md100
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
+```
+