The autocert package provides automatic access to certificates from Let's Encrypt and any other ACME-based CA. This repository contains a collection of tools to simplify the task of managing certificates acquired through this method.
Want to have SSL and don't know where to start => Check out the sslmgr package
- LayeredCache - chain autocert.Cache implementations
- Functional - define an autocert.Cache by using anonymous functions
- Firestore - if you are looking for quick and easy
- MongoDB - when flexibility and robustness are important
- DynamoDB - if your infra lives in AWS
- S3 - throw those certs in a bucket
The default storage mechanism used by autocert is the file system. Containerized and virtual workloads often don't have a persistent file system. Furthermore, file system storage is not suitable for servers spanning multiple machines or distributed systems.
See that the autocert.Cache interface is what controlls where/how certificates are stored/fetched from:
m := autocert.Manager{
Prompt: autocert.AcceptTOS, // To always accept the terms, the callers can use AcceptTOS
HostPolicy: autocert.HostWhitelist(hostnames...), // Specifies which hostnames the Manager is allowed to respond to
Cache: cache, // Cache is used by Manager to store and retrieve previously obtained certificates and other account data as opaque blobs
}
I have implemented the autocert.Cache interface with popular data stores on major cloud providers; so that you dont have to!
Unless you have a corporate deal with Lets Encrypt, you are limited to 5 duplicate certificates (certificates for the same set of names) per week on a rolling basis. This means that if your deployments don't have persistent storage, you can only deploy 5 different times (or even less if your deployments span multiple machines) within a week!