certstrap is a simple certificate manager written in Go that bootstraps a private certificate authority and public key infrastructure, aimed at operators and developers who need to issue TLS certificates without wrestling with openssl.

What it is

certstrap is a command-line certificate manager, adapted from etcd-ca, that lets a team build its own certificate system from scratch: initialize certificate authorities, create identities and certificate signing requests for hosts, and sign and generate certificates. It lives in the Go ecosystem and ships as a single compiled binary named certstrap. Output is written to a depot directory, out/ by default, and consists of .key, .crt, .csr, and .crl files.

The concrete problem it solves is the operational pain of openssl. certstrap is explicitly pitched as convenient for people who do not want to deal with openssl, its myriad of options, or its config files. Instead of assembling long openssl invocations by hand, a user runs three short commands to produce a working CA and a signed leaf certificate. certstrap replaces ad-hoc openssl scripting for the common case of standing up an internal CA and issuing host certificates.

Key capabilities

• init creates a certificate authority and writes CertAuth.key, CertAuth.crt, and CertAuth.crl, using the required --common-name flag to name the output files.
• request-cert generates an identity and keypair, producing a .key and a .csr, and requires either -common-name or -domain.
• sign takes a CSR and a named CA and produces a signed certificate, for example ./certstrap sign Alice --CA CertAuth.
• Multiple CAs can be initialized, and users can build arbitrarily long certificate chains by signing later requests with already-signed hosts.
• Key algorithms include curves P-224, P-256, P-384, P-521, and Ed25519, selectable by name on init and request_cert.
• Hosts with multiple addresses accept comma-separated lists, for example -ip $ip1,$ip2 -domain $domain1,$domain2 -uri $uri1,$uri2.
• Pre-existing private PEM keys can be supplied with the -key flag instead of generating a new keypair.

Who uses it and how

• Small teams standing up internal TLS for services, where a single init and a handful of sign calls replace hand-written openssl commands.
• Operators issuing certificates for hosts with several IP addresses, domains, or URIs, using the comma-separated flag lists.
• Environments that need certstrap inside a build pipeline, since it compiles to one binary and requires no runtime service.
• Deployments with a layered trust model, using multiple CAs and arbitrarily long chains where signed hosts sign later requests.
• Anyone needing a PKCS12 bundle, who runs the generated key and certificate through openssl pkcs12 -export.

Getting started

Build from source with Go 1.18 or higher by cloning https://github.com/square/certstrap, changing into the directory, and running go build, which produces a certstrap binary in the project root. Then run ./certstrap init --common-name "CertAuth" to create the first certificate authority.

How it compares

Among the tools named in the facts, certstrap sits alongside etcd-ca, the project it was adapted from, and takes the place of openssl for routine CA bootstrapping and certificate issuance. openssl remains necessary for adjacent tasks such as converting output to PKCS12 with openssl pkcs12 -export. It is the purpose-built wrapper; openssl is the general-purpose toolkit underneath.

When to use it — and when not to

certstrap is a good fit when the goal is a self-contained, scriptable CA workflow with no service to run and no external dependencies beyond Go at build time. A self-hoster still manages the generated key material, the out/ depot directory, and any distribution of the CA certificate and CRL to relying parties. It is not the right choice for anyone wanting a hosted certificate service, an ACME client for public certificates, or a GUI; the README documents command-line usage only, and prospective users should confirm maintenance cadence and the Apache-2.0 terms against their own requirements before adopting it.

$ git clone https://github.com/square/certstrap
$ cd certstrap
$ go build

$ ./certstrap init --common-name "CertAuth"
Created out/CertAuth.key
Created out/CertAuth.crt
Created out/CertAuth.crl

$ ./certstrap init --common-name "Cert Auth"
Created out/Cert_Auth.key
Created out/Cert_Auth.crt
Created out/Cert_Auth.crl

$ ./certstrap request-cert --common-name Alice
Created out/Alice.key
Created out/Alice.csr

$ ./certstrap sign Alice --CA CertAuth
Created out/Alice.crt from out/Alice.csr signed by out/CertAuth.key

$ openssl pkcs12 -export -out outputCert.p12 -inkey inputKey.key -in inputCert.crt -certfile CA.crt

$ ./certstrap init --common-name CertAuth --curve P-256
Created out/CertAuth.key
Created out/CertAuth.crt
Created out/CertAuth.crl

$ ./certstrap request-cert --common-name Alice --curve P-256
Created out/Alice.key
Created out/Alice.csr