https://github.com/adrianosela/certcache
Useful wrappers around the acme/autocert Cache interface
https://github.com/adrianosela/certcache
autocert cache certbot go golang https server ssl ssl-certificates tls
Last synced: 9 months ago
JSON representation
Useful wrappers around the acme/autocert Cache interface
- Host: GitHub
- URL: https://github.com/adrianosela/certcache
- Owner: adrianosela
- License: mit
- Created: 2019-04-01T04:07:30.000Z (almost 7 years ago)
- Default Branch: master
- Last Pushed: 2024-08-05T15:09:59.000Z (over 1 year ago)
- Last Synced: 2025-03-29T06:01:48.375Z (9 months ago)
- Topics: autocert, cache, certbot, go, golang, https, server, ssl, ssl-certificates, tls
- Language: Go
- Homepage:
- Size: 67.4 KB
- Stars: 7
- Watchers: 2
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# SSL Certificates Storage
[](https://goreportcard.com/report/github.com/adrianosela/certcache)
[](https://godoc.org/github.com/adrianosela/certcache)
[](https://github.com/adrianosela/certcache/issues)
[](https://github.com/adrianosela/certcache/blob/master/LICENSE)
### Go tools for managing SSL certificates from acme/autocert
The [autocert](https://godoc.org/golang.org/x/crypto/acme/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](https://godoc.org/github.com/adrianosela/sslmgr) package
## Tools:
* [LayeredCache](https://godoc.org/github.com/adrianosela/certcache#LayeredCache) - chain autocert.Cache implementations
* [Functional](https://godoc.org/github.com/adrianosela/certcache#Functional) - define an autocert.Cache by using anonymous functions
## Cache Implementations:
* [Firestore](https://godoc.org/github.com/adrianosela/certcache#Firestore) - if you are looking for quick and easy
* [MongoDB](https://godoc.org/github.com/adrianosela/certcache#MongoDB) - when flexibility and robustness are important
* [DynamoDB](https://godoc.org/github.com/adrianosela/certcache#DynamoDB) - if your infra lives in AWS
* [S3](https://godoc.org/github.com/adrianosela/certcache#S3) - throw those certs in a bucket
---
#### Why should I use this? Is this for me?
The [default storage](https://godoc.org/golang.org/x/crypto/acme/autocert#DirCache) 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](https://godoc.org/golang.org/x/crypto/acme/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](https://godoc.org/golang.org/x/crypto/acme/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](https://letsencrypt.org/docs/rate-limits/) 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!