Categorygithub.com/adrianosela/certcache
modulepackage
1.0.1
Repository: https://github.com/adrianosela/certcache.git
Documentation: pkg.go.dev
Overview
Versions
2
Dependencies
25
Dependents
4
Files
466 SLOC

# README

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!

# Packages

No description provided by the author

# Functions

NewDynamoDB returns a DynamoDB certificate cache.
NewFirestore is the default constructor for a Firestore CertCache.
NewFirestoreWithCollection is a constructor for a FirestoreCertCache with a custom Firestore Collection name.
NewFunctional is the constructor for a functional Cert Cache.
NewLayered returns a new layered cache given autocert.Cache implementations.
NewLayeredWithPolicy returns a new layered cache and allows the user to specify the write policy.
NewLogger is the constructor for a Functional cert cache implementation which does nothing other than log events.
NewMongoDB returns a Mongo cache given a mongodb connection string e.g.
NewS3 returns an S3 certificate cache.

# Constants

PolicyWriteDeepFirst will write to caches starting from the last layer provided.
PolicyWriteShallowFirst will write to caches starting from the top, often least persistent, layer e.g.

# Structs

DynamoDB represents a DynamoDB implementation of autocert.Cache.
Firestore is a Google Firestore implementation of autocert.Cache.
Functional allows the user to use functions to define a cert cache.
LayeredCache is an implementation of the autocert.Cache interface.
MongoDB represents a MongoDB implementation of autocert.Cache.
S3 represents an AWS S3 implementation of autocert.Cache.

# Type aliases

WritePolicy determines the order in which the layered cache executes Put.