This document covers a few options in how to generate and set up TLS certificates suitable for working with pomerium.
This guide uses the following tools and resources:
- LetsEncrypt (opens new window) is a public certificate authority that issues free certificates trusted by the major browsers. Other private (opens new window) or public (opens new window) CAs would also be fine.
- Google Domains (opens new window) registrar will be used to set up our wildcard domain and certificate validation. But any registrar would do and some providers support automatic renewal (opens new window).
- acme.sh (opens new window) will be used to retrieve the wild-card domain certificate. Any LetsEncrypt client (opens new window) that supports wildcard domains would work.
It should be noted that there are countless ways of building and managing public-key infrastructure (opens new window). And although we hope this guide serves as a helpful baseline for generating and securing pomerium with certificates, these instructions should be modified to meet your own organization's tools, needs, and constraints. In a production environment you will likely be using your corporate load balancer, or a key management system to manage your certificate authority infrastructure.
Since one of Pomerium's core principles is to treat internal and external traffic impartially, Pomerium uses mutually authenticated TLS (opens new window) ubiquitously. For example, Pomerium uses mTLS between:
- end-user and Pomerium
- Pomerium's services regardless of if the network is "trusted"
- Pomerium and the destination application
# Setting up DNS
First, you'll want to set a CNAME (opens new window) record for wild-card domain name you will be using with Pomerium.
# Per-route automatic certificates
Pomerium itself can be used to retrieve, manage, and renew certificates certificates for free using Let's Encrypt, the only requirement is that Pomerium is able to receive public traffic on ports
443. This is probably the easiest option.
# Self-signed wildcard certificate
In production, we'd use a public certificate authority such as LetsEncrypt. But for a local proof of concept or for development, we can use mkcert (opens new window) to make locally trusted development certificates with any names you'd like. The easiest, is probably to use
*.localhost.pomerium.io which we've already pre-configured to point back to localhost.
Bootstrap mkcert's root certificate into your operating system's trust store.
Create your wildcard domain.
*.localhost.pomerium.iois helper domain we've hard-coded to route to localhost:
# Manual DNS Let's Encrypt wildcard certificate
Once you've setup your wildcard domain, we can use acme.sh to create a certificate-signing request with LetsEncrypt.
#!/bin/bash # acme.sh : https://github.com/Neilpang/acme.sh # curl https://get.acme.sh | sh # NOTA BENE: # if you use a DNS service that supports API access, you may be able to automate # this process. See https://github.com/Neilpang/acme.sh/wiki/dnsapi echo "=> first generate a certificate signing request!" $HOME/.acme.sh/acme.sh \ --issue \ -k ec-256 \ -d '*.corp.example.com' \ --dns \ --yes-I-know-dns-manual-mode-enough-go-ahead-please read -p "press anykey once you've updated your TXT entries" $HOME/.acme.sh/acme.sh \ --renew \ --ecc \ -k ec-256 \ -d '*.corp.example.com' \ --dns \ --yes-I-know-dns-manual-mode-enough-go-ahead-please
LetsEncrypt will respond with the corresponding
TXT record needed to verify our domain.
It may take a few minutes for the DNS records to propagate. Once it does, you can run the following command to complete the certificate request process.
Here's how the above certificates signed by LetsEncrypt correspond to their respective Pomerium configuration settings:
|Pomerium Config||Certificate file|
Your end users will see a valid certificate for all domains delegated by Pomerium.
LetsEncrypt certificates must be renewed every 90 days (opens new window).
Certificates, TLS, and Public Key Cryptography is a vast subject we cannot adequately cover here so if you are new to or just need a brush up, the following resources may be helpful:
- Why HTTPS for Everything? (opens new window) The US government's CIO office has an excellent guide covering HTTPS and why future government sites will all be HTTPS.
- Is TLS Fast (opens new window) debunks the performance myth associated with HTTPS.
- Use TLS (opens new window) covers why TLS should be used everywhere; not just for securing typical internet traffic but for securing service communication in both "trusted" and adversarial situations.
- Everything you should know about certificates and PKI but are too afraid to ask (opens new window)