1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
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
```
|
