Skip to content

Useful wrappers around the acme/autocert Cache interface

License

Notifications You must be signed in to change notification settings

adrianosela/certcache

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

46 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

SSL Certificates Storage

Go Report Card Documentation GitHub issues license

Go tools for managing SSL certificates from acme/autocert

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

Tools:

  • LayeredCache - chain autocert.Cache implementations
  • Functional - define an autocert.Cache by using anonymous functions

Cache Implementations:

  • 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

Why should I use this? Is this for me?

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!

But wait, why can't I just get a new certificate every time I deploy?

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!