Documentation menu

homepki vs. other tools

How homepki 0.8.0 compares with other command line tools that create local certificates. The comparison is about local development and test use.

Feature matrix

Featurehomepkimkcertstepcfssleasy-rsaminicacertstrap
Intermediate CAsYesNoYesYesseparate PKINoYes
Several intermediates per rootYesNoYesYesmanualNoYes
Client (mTLS) certificatesYesYesYesYesYesNoYes
Name constraintsYesNotemplatespolicy configOpenSSL configNoDNS only
Constraints checked before writingYesNoNoNoNoNoNo
Key typesRSA, ECDSA, Ed25519RSA, ECDSARSA, ECDSA, Ed25519RSA, ECDSARSA, ECDSA, EdDSARSA, ECDSARSA, ECDSA
Custom validityYesNoYesYesYesNoYes
Sign an external CSRYesYesYesYesYesNoYes
PKCS#12 outputYesYesYesNoYesNoNo
Revocation (CRL)YesNowith step-caYesYesNoYes
OCSP, ACME or an online CANoNostep-ca: ACME, no OCSPAPI server, OCSPNoNoNo
Chain check of the whole treeYesNoper fileper fileNoNoNo
Trust install: macOS, LinuxYesYesYesNoNoNoNo
Trust install: WindowsNoYesYesNoNoNoNo
Trust install: Firefox/NSS, JavaYesYesYesNoNoNoNo
Encrypted private keysNoNoYesNoYesNoYes
Needs OpenSSLNoNoNoNoYesNoNo

"step" is the step CLI; online features come from step-ca, its companion server. Entries for the other tools describe their documented behaviour, not a test run.

When to use which

NeedBest fit
Make https://localhost work in a browser, on any OS including Windowsmkcert
mTLS or multi-tenant demos with CA bundles, client certificates and CRLs, on macOS or Linuxhomepki
A CA that constrains which names it can sign, checked before a certificate is writtenhomepki
An online CA with ACME, short-lived certificates on demand, SSH certificatesstep-ca
A CA behind an HTTP API, with OCSPcfssl
A long-lived OpenVPN PKI with encrypted keyseasy-rsa
Certificates issued inside Kubernetescert-manager, with a homepki intermediate as its CA issuer

mkcert

mkcert creates one local root and signs leaves directly with it. Its strength is trust installation: the system store on macOS, Linux and Windows, Firefox/NSS and Java, in one command. It has no intermediates, no name constraints, fixed validity and no revocation. Its root can vouch for any name once trusted. homepki covers the same trust stores except Windows, and adds the hierarchy, client certificates under separate intermediates, name constraints and CRLs.

step and step-ca

step certificate create can build the same three tiers with profiles, and templates allow name constraints. You choose file names and layout yourself. step-ca adds an online CA with ACME, provisioners and SSH certificates. homepki fixes the layout per domain and intermediate, derives the subjects, verifies every chain in list, and needs no server.

cfssl

cfssl is configured with JSON: CSR definitions, signing profiles and policies. It can run as an HTTP API, generate CRLs and serve OCSP. It does not install trust. It fits a CA used by services and CI over an API more than a workstation.

easy-rsa

easy-rsa is a set of shell scripts around OpenSSL, known from OpenVPN. One PKI directory holds one CA; a sub-CA is a second PKI signed by the first. It supports revocation with CRLs, encrypted keys and PKCS#12 export. It needs OpenSSL and does not install trust.

minica

minica creates a root and leaves signed by it, one directory per name. It has no intermediates, no client-certificate mode, no revocation and no trust installation. It is the smallest option when a test only needs a leaf and a CA file.

certstrap

certstrap has an init, request-cert, sign workflow, supports intermediates, CRLs and passphrase-protected keys, and can restrict a CA to DNS names. It does not install trust or produce PKCS#12.

OpenSSL

openssl req, x509 and ca can do everything above and more, with configuration files you write. homepki issued certificates with openssl before 0.7.0; it now uses Go's crypto/x509, and OpenSSL is only useful for inspecting results.

What homepki does not do

  • No Windows binary and no Windows trust store.
  • No online CA: no ACME, no OCSP, no API server.
  • Private keys are never encrypted.
  • Certificates carry no CRL distribution point; CRL files are handed to servers directly.
  • Intermediate CAs cannot be revoked, only replaced with --force.
  • Subject names are derived and cannot be set, except through signed CSRs.