smallstep/certificates

🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.

step-ca

step-ca is an online certificate authority for secure, automated certificate management for DevOps. It's the server counterpart to the step CLI tool for working with certificates and keys. Both projects are maintained by Smallstep Labs.

You can use step-ca to:

• Issue HTTPS server and client certificates that work in browsers (RFC5280 and CA/Browser Forum compliance)
• Issue TLS certificates for DevOps: VMs, containers, APIs, database connections, Kubernetes pods...
• Issue SSH certificates:
  • For people, in exchange for single sign-on identity tokens
  • For hosts, in exchange for cloud instance identity documents
• Easily automate certificate management:
  • It's an ACME server that supports all popular ACME challenge types
  • It comes with a Go wrapper
  • ... and there's a command-line client you can use in scripts!

---

Comparison with Smallstep's commercial product

step-ca is optimized for a two-tier PKI serving common DevOps use cases.

As you design your PKI, if you need any of the following, consider our commerical CA:

• Multiple certificate authorities
• Active revocation (CRL, OSCP)
• Turnkey high-volume, high availability CA
• An API for seamless IaC management of your PKI
• Integrated support for SCEP & NDES, for migrating from legacy Active Directory Certificate Services deployments
• Device identity — cross-platform device inventory and attestation using Secure Enclave & TPM 2.0
• Highly automated PKI — managed certificate renewal, monitoring, TPM-based attested enrollment
• Seamless client deployments of EAP-TLS Wi-Fi, VPN, SSH, and browser certificates
• Jamf, Intune, or other MDM for root distribution and client enrollment
• Web Admin UI — history, issuance, and metrics
• ACME External Account Binding (EAB)
• Deep integration with an identity provider
• Fine-grained, role-based access control
• FIPS-compliant software
• HSM-bound private keys

See our full feature comparison for more.

You can start a free trial or set up a call with us to learn more.

---

Questions? Find us in Discussions or Join our Discord.

Website | Documentation | Installation | Contributor's Guide

Features

🦾 A fast, stable, flexible private CA

Setting up a public key infrastructure (PKI) is out of reach for many small teams. step-ca makes it easier.

• Choose key types (RSA, ECDSA, EdDSA) and lifetimes to suit your needs
• Short-lived certificates with automated enrollment, renewal, and passive revocation
• Can operate as an online intermediate CA for an existing root CA
• Badger, BoltDB, Postgres, and MySQL database backends

⚙️ Many ways to automate

There are several ways to authorize a request with the CA and establish a chain of trust that suits your flow.

You can issue certificates in exchange for:

• ACME challenge responses from any ACMEv2 client
• OAuth OIDC single sign-on tokens, eg:
  • ID tokens from Okta, GSuite, Azure AD, Auth0.
  • ID tokens from an OAuth OIDC service that you host, like Keycloak or Dex
• Cloud instance identity documents, for VMs on AWS, GCP, and Azure
• Single-use, short-lived JWK tokens issued by your CD tool — Puppet, Chef, Ansible, Terraform, etc.
• A trusted X.509 certificate (X5C provisioner)
• A host certificate from your Nebula network
• A SCEP challenge (SCEP provisioner)
• An SSH host certificates needing renewal (the SSHPOP provisioner)
• Learn more in our provisioner documentation

🏔 Your own private ACME server

ACME is the protocol used by Let's Encrypt to automate the issuance of HTTPS certificates. It's super easy to issue certificates to any ACMEv2 (RFC8555) client.

• Use ACME in development & pre-production

• Supports the most popular ACME challenge types:

  • For http-01, place a token at a well-known URL to prove that you control the web server
  • For dns-01, add a TXT record to prove that you control the DNS record set
  • For tls-alpn-01, respond to the challenge at the TLS layer (as Caddy does) to prove that you control the web server

• Works with any ACME client. We've written examples for:

  • certbot
  • acme.sh
  • win-acme
  • Caddy
  • Traefik
  • Apache
  • nginx

• Get certificates programmatically using ACME, using these libraries:

  • lego for Golang (example usage)
  • certbot's acme module for Python (example usage)
  • acme-client for Node.js (example usage)

• Our own step CLI tool is also an ACME client!

• See our ACME tutorial for more

👩🏽‍💻 An online SSH Certificate Authority

• Delegate SSH authentication to step-ca by using SSH certificates instead of public keys and authorized_keys files
• For user certificates, connect SSH to your single sign-on provider, to improve security with short-lived certificates and MFA (or other security policies) via any OAuth OIDC provider.
• For host certificates, improve security, eliminate TOFU warnings, and set up automated host certificate renewal.

🤓 A general purpose PKI tool, via step CLI integration

• Generate key pairs where they're needed so private keys are never transmitted across the network
• Authenticate and obtain a certificate using any provisioner supported by step-ca
• Securely distribute root certificates and bootstrap PKI relying parties
• Renew and revoke certificates issued by step-ca
• Install root certificates on your machine and browsers, so your CA is trusted
• Inspect and lint certificates

Installation

See our installation docs here.

Documentation

• Official documentation is on smallstep.com
• The step command reference is available via step help, on smallstep.com, or by running step help --http=:8080 from the command line and visiting http://localhost:8080.

Feedback?

• Tell us what you like and don't like about managing your PKI - we're eager to help solve problems in this space. Join our Discord or GitHub Discussions
• Tell us about a feature you'd like to see! Request a Feature

certificates's Issues

How to run step-certificates in docker

Description

Create docs on how to run step-certificates in docker. How to initialize the PKI and run it using the smallstep/step-ca docker image.

Add provisioner support for GCE

Description

Add a new provisioner type to grant certificates using instance identity tokens.
https://cloud.google.com/compute/docs/instances/verifying-instance-identity
https://cloud.google.com/compute/docs/internal-dns#about_internal_dns

Add basic federation where you can add multiple roots to your trust bundle

Also a useful feature for root certs rotation.

ACME Support for CA ready for review

Might be a useful feature for ecosystem/clients that want to natively speak ACME as protocol/interface. This is not be a Web PKI drop-in replacement. This feature would make it possible to leverage ACME for internal PKI.

Step CA not renewing cert after waking from sleep on OSX

Steps to reproduce:

1. Set default cert validity duration to an appropriately small value; e.g. 10 mins

2. Start the CA, put the machine to sleep before the cert has a chance to renew

3. Wake the laptop after the cert had sufficient time to renew.

4. Make a step ca health request and witness failure due to expired cert.

Consolidate certificates docs/ directory

• Link ToC (/docs) in README
• Add complete docs of ca.json
• Make sure custom claims is complete, reference examples (#40)

Add docs for claims

Description

Add docs for TLS and SSH claims, at both authority and provisioner level.

Add support for TLS 1.3 if certificates is compiled with 1.12 or greater

TLS 1.3 is available in Go 1.12 adding the value tls13=1 to the GODEBUG environment variable, and it will be enabled by default on Go 1.13.
https://golang.org/doc/go1.12#tls_1_3

We can add support for TLS 1.3 as MaxVersion using build constraints // +build go1.12

Add support for multiple intermediate CA

Subject of the improvement

Would it be possible to add support in step ca to create structures of multiple intermediate CAs (case when the path length of the certificate >= 2). It is an idea to change the settings of the lifespan of the created certificates on different Intermediate CAs level.

Example use case

Root CA - Intermediate CA 1 - Intermediate CA 2 - leaf certificates
Intermediate CA2 does not have a constant network connection to Intermediate CA1 (bad network connectivity), so the assumption to use very short lifetimes for passive revocation will introduce issues: due to bad network connectivity it is impossible to do renewal of the certificate in time. To solve this, Intermediate CA 1 would need to issue certificates with a longer lifetime (e.g. multiple years) to Intermediate CA2.
End devices have good network connectivity to Intermediate CA 2, so there shorter lifetimes could be used.

Tell CA to allow a VM to re-authenticate using IID

By default, the IID implementation only allows a VM to authenticate to the CA once. This is a security feature. You can disable this feature for a provisioner by setting disableTrustOnFirstUse to true, but that's a global operation for the provisioner and will allow all VMs to get as many certs as they want using IIDs.

It seems like there's a middle ground where someone might want to "reset" a particular instance. This might come up if an instance is being brought back up and has an expired certificate, and must be re-bootstrapped. It's also come up for me repeatedly during testing.

Seems like we could add a step command that pokes at the step-ca database to reset the status for a particular instance so it can authenticate one more time.

In the meantime, is there a way to poke at the step-ca database manually to reset this status?

Add a hello-mTLS example using gRPC

Description

Add a hello-mTLS example using gRPC

Extensions are not properly copied on renew

Description

Step provisioner extension is not copied from the old certificate when a renew occurs.

Incorrect parsing of cache age/jitter in keystore

When initializing a keystore with JWKs, keystore.go tries to fetch age from Cache-Control header.
Unfortunately, when the server responds with something like

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

the value extracted from getCacheAge(cacheControl string) is equals to 0 (zero).
Subsequently, jitter is set to 0.
This causes an error in subsequent functions, which expect a positive integer as value (see https://golang.org/pkg/math/rand/#Rand.Int63n):

n := rand.Int63n(int64(ks.jitter))

A simple fix could be setting a lower bound for jitter in getCacheJitter (for example defaultCacheJitter/12).

Stacktrace

panic: invalid argument to Int63n

goroutine 1 [running]:
math/rand.(*Rand).Int63n(0xc000092150, 0x0, 0xc00019de30)
	/snap/go/3947/src/math/rand/rand.go:111 +0x11e
math/rand.Int63n(...)
	/snap/go/3947/src/math/rand/rand.go:319
github.com/smallstep/certificates/authority/provisioner.(*keyStore).nextReloadDuration(0xc00019de30, 0x0, 0xed4a2c25b)
	/home/mat/go/src/github.com/smallstep/certificates/authority/provisioner/keystore.go:88 +0x3c
github.com/smallstep/certificates/authority/provisioner.newKeyStore(0xc000230100, 0x1d, 0xc000230100, 0x1d, 0x0)
	/home/mat/go/src/github.com/smallstep/certificates/authority/provisioner/keystore.go:46 +0x20f
github.com/smallstep/certificates/authority/provisioner.(*OIDC).Init(0xc0001c8240, 0xc0002222a0, 0xc0002222a8, 0xc0002222b0, 0xc00022229d, 0xc00016da10, 0x3, 0x3, 0xc00016da40, 0x3, ...)
	/home/mat/go/src/github.com/smallstep/certificates/authority/provisioner/oidc.go:146 +0x28e
github.com/smallstep/certificates/authority.(*AuthConfig).Validate(0xc00016d830, 0xc00016da10, 0x3, 0x3, 0xc00016da40, 0x3, 0x3, 0x0, 0xc0001273f8)
	/home/mat/go/src/github.com/smallstep/certificates/authority/config.go:84 +0x275
github.com/smallstep/certificates/authority.(*Config).Validate(0xc000194d00, 0x1b, 0xc00016aa48)
	/home/mat/go/src/github.com/smallstep/certificates/authority/config.go:167 +0x302
github.com/smallstep/certificates/authority.New(0xc000194d00, 0x0, 0x0, 0x0, 0x30, 0x28, 0xad4240)
	/home/mat/go/src/github.com/smallstep/certificates/authority/authority.go:45 +0x40
github.com/smallstep/certificates/ca.(*CA).Init(0xc00016d9e0, 0xc000194d00, 0x2, 0x2, 0x9c6a3d)
	/home/mat/go/src/github.com/smallstep/certificates/ca/ca.go:89 +0x8b
github.com/smallstep/certificates/ca.New(0xc000194d00, 0xc0001276b8, 0x2, 0x2, 0x0, 0xb29eed, 0x4)
	/home/mat/go/src/github.com/smallstep/certificates/ca/ca.go:75 +0xaf
main.startAction(0xc0001d8b00, 0xc000190300, 0xc0001d8b00)
	/home/mat/go/src/github.com/smallstep/certificates/cmd/step-ca/main.go:190 +0x1e4
github.com/smallstep/certificates/vendor/github.com/urfave/cli.HandleAction(0xa43e60, 0xb5e230, 0xc0001d8b00, 0x0, 0xc00016a9c0)
	/home/mat/go/src/github.com/smallstep/certificates/vendor/github.com/urfave/cli/app.go:501 +0xc8
github.com/smallstep/certificates/vendor/github.com/urfave/cli.Command.Run(0xb2acbf, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/home/mat/go/src/github.com/smallstep/certificates/vendor/github.com/urfave/cli/command.go:165 +0x487
main.main.func4(0xc0001d8840, 0x0, 0x0)
	/home/mat/go/src/github.com/smallstep/certificates/cmd/step-ca/main.go:152 +0x1ae
github.com/smallstep/certificates/vendor/github.com/urfave/cli.HandleAction(0xa43e60, 0xc00016efc0, 0xc0001d8840, 0x0, 0x0)
	/home/mat/go/src/github.com/smallstep/certificates/vendor/github.com/urfave/cli/app.go:501 +0xc8
github.com/smallstep/certificates/vendor/github.com/urfave/cli.(*App).Run(0xc000214000, 0xc00000c080, 0x2, 0x2, 0x0, 0x0)
	/home/mat/go/src/github.com/smallstep/certificates/vendor/github.com/urfave/cli/app.go:268 +0x5aa
main.main()
	/home/mat/go/src/github.com/smallstep/certificates/cmd/step-ca/main.go:155 +0x640

Enforce that CSR RSA public keys have >= 2048 bits

Add support for Google KMS-backed private keys

What would you like to be added

Google's Cloud KMS supports digital signatures based on asymmetric keys. A nice feature would be if step ca could utilize a Cloud KMS key for signing X.509 certificates rather than using local private key material.

Why this is needed

Utilizing a Cloud KMS key for signatures could increase security as it would act like an HSM (or, potentially, be an HSM) and decrease the risk of the root (or intermediate) private key material leaking.

Prior Art

I provide no attestation to its security or quality, but it does seem like this at least possible in Go: https://github.com/mattes/google-cloud-kms-csr

Flags not working after configuration file

Description

The following error appears if you run step-ca with the --password-file <file> option after the configuration file:

$ step-ca  ~/.step/config/ca.json --password-file /tmp/password
too many positional arguments were provided in 'step-ca  [command options]

Doing it the other way around, step-ca --password-file /tmp/password ~/.step/config/ca.json is working properly, but both options should work.

Document how to use `step-ca` docker container.

step-ca containers are shipped without pre-configured certificates/keys/configuration files. We should either ship with default materials in the container or have good documentation about how to setup your environment.

The lack of proper documentation / guide was first brought to our attention by this issue on smallstep/cli.

Provisioners logic with multiple intermediate CA

Subject of the improvement

When there are multiple intermediate CAs (see #87) for example
Root CA - Intermediate CA 1 - Intermediate CA 2 - leaf certificates
There are provisioners on multiple layers in the Public Key Infrastructure.
Currently this logic of provisioners is local data which is coupled to an intermediate CA, so this logic is decentralized (Intermediate CA 1 and Intermediate CA 2).

Would it be a good idea to have a possible synchronization between this data to simplify the management of provisioners? Like a central system for the provisioners logic which is available in intermediate CA 1 and intermediate CA 2?

Maybe coupling between the provisioners is needed? For example provisioners of Intermediate CA 2 might need a claim about maxTLSCertDuration which is tight (can not exceed) to the maxTLSCertDuration of provisioners of Intermediate CA 1 (which generated Intermediate CA2)?

Certificate difference

I created this certificate using:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls.key -out /tmp/tls.crt -subj "/CN=booksapp.linkerd.io"

I created similar using step:

step certificate create --profile root-ca "My Root CA" root-ca.crt root-ca.key --no-password --insecure --force --kty=RSA

step certificate create identity.linkerd.cluster.local identity.crt identity.key --profile intermediate-ca --ca ./root-ca.crt --ca-key ./root-ca.key --no-password --insecure --kty=RSA

step certificate create booksapp.linkerd.io booksapp.crt booksapp.key --profile leaf --ca identity.crt --ca-key identity.key --no-password --insecure --force --kty=RSA  --not-after=2160h

When I use step created in Kubernetes, Chrome uses this well but curl does not like it.

When I use openssl way, both chrome and curl are OK.

Here is the inspect on both tls.crt --> Openssl way

$ step certificate inspect /tmp/tls.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 18348404666430232338 (0xfea2a0d481b19712)
    Signature Algorithm: SHA256-RSA
        Issuer: CN=booksapp.linkerd.io
        Validity
            Not Before: Aug 12 05:21:47 2019 UTC
            Not After : Aug 11 05:21:47 2020 UTC
        Subject: CN=booksapp.linkerd.io
        Subject Public Key Info:
            Public Key Algorithm: RSA
                Public-Key: (2048 bit)
                Modulus:
                    d7:24:55:b8:17:f4:24:2d:29:7f:ef:28:dc:e7:8d:
                    14:2a:71:64:da:40:4b:3d:94:12:e5:b7:bf:07:46:
                    5a:d3:a3:0c:64:05:6e:a6:8d:d1:69:81:c0:e3:ab:
                    bc:ad:fb:c1:71:81:4b:67:12:d0:a6:50:0f:5c:fd:
                    d6:93:28:54:a4:32:d3:9a:7a:1e:b3:bc:43:cf:61:
                    a7:15:68:62:dd:05:e1:6f:af:87:0d:fc:06:dc:0b:
                    f9:1f:cf:ab:f5:50:57:51:85:b7:72:65:1a:b3:62:
                    03:db:25:f6:37:a0:cd:36:b5:ba:6d:1d:7f:5d:ce:
                    e9:e4:df:6f:97:43:95:39:af:f1:f7:d7:1d:55:40:
                    2f:8f:55:ac:8f:ab:74:db:08:49:39:5f:15:ac:46:
                    79:27:3b:30:d1:88:84:7a:5e:8b:d2:e6:20:ca:9d:
                    93:92:a5:68:f9:30:96:e9:51:73:f9:12:32:0e:23:
                    b9:1d:c8:77:29:cc:d5:28:80:ad:6d:02:83:e9:22:
                    d8:fc:10:7f:60:36:44:5f:8a:f3:ce:4b:0e:dc:53:
                    e7:66:83:4a:e3:52:ae:45:b0:22:cd:a2:95:14:7c:
                    68:7a:09:44:65:17:b4:05:66:0d:c9:2f:a6:d6:c1:
                    bb:1b:2b:d5:7d:1f:fc:77:31:37:05:c5:2e:16:6e:
                    0b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                43:EA:FD:2D:FD:30:B8:62:D8:75:A1:70:74:6C:16:9D:9D:6C:71:89
            X509v3 Authority Key Identifier:
                keyid:43:EA:FD:2D:FD:30:B8:62:D8:75:A1:70:74:6C:16:9D:9D:6C:71:89
            X509v3 Basic Constraints:
                CA:TRUE

    Signature Algorithm: SHA256-RSA
         94:eb:d8:16:6d:ab:46:fc:a9:d8:ff:ad:a3:41:b9:5d:10:1d:
         a9:81:c6:68:8c:de:b1:60:ab:f6:1a:38:7b:6e:83:45:b2:f5:
         bf:fb:a9:d5:21:bd:1d:ac:84:79:6a:e4:08:91:bf:58:a5:22:
         3c:00:da:b9:b7:be:13:e5:a7:ff:f5:41:ed:2b:bb:c7:70:2c:
         74:b5:47:86:a1:b2:04:70:50:ef:b3:bc:95:d1:bd:56:d6:fd:
         a9:c2:29:71:6b:6d:ac:2b:de:57:9b:57:c2:45:ca:fe:55:2e:
         81:ae:6b:2f:07:61:cf:e8:a4:7d:d3:c8:e0:ea:93:d9:d4:66:
         95:14:2b:fa:9e:f6:d9:fd:ca:19:e2:23:87:a1:2c:dc:66:33:
         8b:bc:35:34:7d:3c:b8:f2:77:d9:a3:7a:18:2e:fc:9d:27:9d:
         cd:de:29:79:5a:cf:b9:2e:67:87:b5:48:48:8c:9f:57:51:f4:
         d5:c6:ba:6b:31:4a:30:24:f4:ec:18:77:c7:10:f6:d1:ca:2b:
         8d:42:64:75:c6:32:7d:29:83:74:8b:77:f6:18:12:74:3f:02:
         ff:9e:0c:ee:fb:66:72:64:2c:f0:1b:48:71:9d:1d:17:f4:3f:
         7e:70:b4:e1:2c:fe:48:71:ec:95:32:cf:8e:de:0c:2e:5b:81:
         9f:24:2d:8f

Here is the one for step created.

$ step certificate inspect booksapp.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 316363851025198308392871671396925855994 (0xee01761e62125440225bf80a7e4258fa)
    Signature Algorithm: SHA256-RSA
        Issuer: CN=identity.linkerd.cluster.local
        Validity
            Not Before: Aug 12 05:58:25 2019 UTC
            Not After : Nov 10 05:58:24 2019 UTC
        Subject: CN=booksapp.linkerd.io
        Subject Public Key Info:
            Public Key Algorithm: RSA
                Public-Key: (2048 bit)
                Modulus:
                    d6:fd:2c:c6:35:95:37:c9:26:b4:c1:d8:5b:20:df:
                    d0:02:5f:fa:f2:40:f4:c0:9d:07:63:3b:0f:e4:22:
                    f1:4c:dc:2a:38:c4:97:89:2d:67:05:83:64:8a:bc:
                    61:95:c8:0a:41:c3:e2:d7:b6:5e:5c:89:ce:77:91:
                    bd:e0:ab:f5:30:10:de:75:e5:bc:19:5d:0e:a6:64:
                    6b:f1:52:d4:a5:9b:2c:e0:78:65:f9:45:cb:d3:e9:
                    ba:37:2c:63:67:9f:d3:07:ff:ee:13:2e:32:62:ab:
                    70:18:e0:5c:bb:cd:e4:8c:a4:47:b7:ce:76:76:08:
                    ff:a9:25:e9:d3:d0:4c:71:13:82:d8:bb:be:9e:e9:
                    5b:fb:e1:de:1e:51:d3:72:fd:95:d7:de:d2:df:45:
                    e2:01:38:1d:5f:8f:26:1e:cb:c9:91:3f:be:30:56:
                    83:89:8e:a2:3b:c4:ac:2f:70:ad:26:ef:6f:b2:4a:
                    f0:65:e2:b2:4c:27:d6:a8:8e:fa:1b:a3:c7:bd:ee:
                    1f:c7:ac:eb:29:89:02:24:9a:bb:d9:1e:c6:81:d6:
                    68:3c:32:7d:7b:ab:5f:83:ca:5a:79:d5:0e:0b:39:
                    6f:36:cd:e7:13:91:f7:bd:74:13:61:b5:41:5d:5f:
                    6c:5e:6d:1c:7a:80:95:50:fc:b7:bd:1d:8d:72:34:
                    05
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                93:7D:D2:5A:28:46:3F:89:C8:25:9B:09:40:7F:A6:1B:AE:56:2C:64
            X509v3 Authority Key Identifier:
                keyid:DD:A1:01:97:F6:C2:5D:64:BE:2E:C3:BC:65:C8:C9:DF:0A:B0:30:F9
            X509v3 Subject Alternative Name:
                DNS:booksapp.linkerd.io

    Signature Algorithm: SHA256-RSA
         8d:e0:fb:c2:17:61:41:54:79:4d:42:d1:9a:f4:cd:b6:6d:a6:
         2d:54:78:17:5c:27:15:5b:71:a6:8c:1c:e8:e2:d0:fd:f9:d8:
         f9:ac:04:a7:ee:26:17:71:af:8e:37:35:a9:1b:4c:e4:9d:78:
         97:c7:2a:fd:68:47:14:13:80:b8:de:71:c5:15:66:b9:a8:88:
         e4:fb:74:67:f9:68:8a:95:58:58:c8:78:4e:4d:7d:a2:90:ac:
         81:c6:e0:e5:10:c0:68:48:23:a2:c8:8d:6b:19:cc:99:7b:b7:
         69:f7:c1:35:25:f7:bf:85:22:53:b5:60:31:cb:bd:1d:f5:ea:
         54:32:0b:1d:61:8c:e6:36:f4:fa:67:45:c1:7d:38:3f:c3:ee:
         80:1e:e7:b4:3a:92:7e:f6:38:6d:b2:4a:fe:99:ce:b7:05:c0:
         cf:1e:65:8e:85:92:53:22:94:31:cc:0d:72:e8:a4:e4:29:00:
         c7:52:13:62:69:77:b2:31:1c:c2:c9:97:46:0b:2b:87:db:25:
         60:a4:35:ba:2f:72:75:94:be:d2:ea:ef:b8:bd:47:f8:08:1c:
         73:ff:af:6a:8d:99:be:5e:3c:5f:37:56:06:d3:00:ad:3e:2b:
         ae:08:a4:5b:8e:63:5e:63:d0:02:16:2e:73:16:c6:ba:b1:47:
         fa:3c:48:3a

The following curl fails for step generated.

$ curl -v -HHost:booksapp.linkerd.io --resolve booksapp.linkerd.io:$INGRESS_HOST:$INGRESS_PORT --cacert booksapp.crt https://booksapp.linkerd.io
* About to connect() to booksapp.linkerd.io port 443 (#0)
*   Trying 192.168.142.249...
* Connected to booksapp.linkerd.io (192.168.142.249) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: booksapp.crt
  CApath: none
* Server certificate:
*       subject: CN=booksapp.linkerd.io
*       start date: Aug 12 05:58:25 2019 GMT
*       expire date: Nov 10 05:58:24 2019 GMT
*       common name: booksapp.linkerd.io
*       issuer: CN=identity.linkerd.cluster.local
* NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER)
* Peer's Certificate issuer is not recognized.
* Closing connection 0
curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html

Of course - I am making some mistake here.

Can you please help as what would be the equivalent of following in step

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls.key -out /tmp/tls.crt -subj "/CN=booksapp.linkerd.io"

so that the curl is happy. The bigger issue is that Linkerd proxy is also failing on same issue.

I appreciate your insight.

The `:latest` tag for the `step-ca` docker registry is not up to date.

Figure out how we want to use this tag. Should it reflect master, any versioned release (including RC candidates), or only stable versions?

First brought to our attention in this issue on smallstep/cli.

Add used OTTs to the persistent storage layer.

Used OTTs are stored in memory in the CA which makes them unreliable for HA use cases.

x5c provisioner

Description

Add support for a new type of provisioners that can authorize certificates using an mTLS connection. This new provisioner will allow a special X.509 certificate to create new certificates for different SANs without requiring a token, just trusting a mutual TLS connection between the client and server.

The provisioner should be able to differentiate a "regular" certificate from a certificate that can be used in the mTLS provisioner flow, and only allow to use the later ones.

We can also add extension saying which SANs are authorized, or some similar restrictions.

Write a `defaults.json` file on `step ca init`.

step-ca docker container has out of date version of cli container (and cli)

There is a cyclical relationship between the build process of the CLI and the build process of the CA making it difficult to pin both to the same version in docker containers.

One solution to this would be to have the CLI build process build the CA docker container.

Add a CRUD API for provisioners

Add a CRUD API for provisioners.

Ability to add/remove/list/update provisioners using the API.

Why

The current flow for managing provisioners is clunky. Provisioners are managed by the ca-configuration file which can only be modified using the step cli. After modifications have been made, the CA must be SIGHUP-ed in order for changes to take effect. An api could streamline this process.

Questions

• Should provisioners be stored in the database?
• How will provisioners function across multiple intermediates? (#88)

Add support for an OIDC provisioner

Add support for an OIDC provisioner:

• Using user identities (OIDC token)
  ** Temporary and audited access

Implement ACME renew route/api

Add custom claims example to `step certificates` repo

Always verify certificates before use

We should consider making commands like step certificate key, step crypto jwe encrypt --key, and step crypto jwt verify --key that take an X.509 certificate also verify that certificate before use. For the latter two commands we may also want to check the key use attribute(s) in the certificate and ensure they're appropriate for the command being run.

This seems like the right default in terms of safety/misuse prevention, although the risk of serious danger seems minimal (particular for the key use bit). The downside is that it will add more complexity: we'll probably need to add --root(s) and --insecure flags to set the CA cert and disable verification, respectively. We'd probably also need --subtle to disable the key use check. And I'm pretty sure our CA doesn't include the necessary key use(s) for these operations in leaf certificates. All of this could confuse users.

I'm not sure what the right answer is, but wanted to capture some thoughts for now.

Update safely a certificate pool with GetConfigForClient

The SDK does not remove the old roots as it's not possible to safely change the RootCAs/ClientCAs directly on the tls.Config. But tls.Config method GetConfigForClient allows to get a custom tls.Config after a ClientHello. More information:
https://tip.golang.org/pkg/crypto/tls/#Config.GetConfigForClient
https://diogomonica.com/2017/01/11/hitless-tls-certificate-rotation-in-go/

Default crv, kty, size (and min size) should be configurable per provisioner

Provisioner configuration for default key types, sizes, crvs, etc.

Why this is needed

Support more specialized use cases.

Short version of certificate inspect: `step certificate inspect --short`

It'd be nice to have a shorter / more friendly version of step certificate inspect. We already have --format json so this doesn't need to be easily parseable. It's for humans, not machines.

So far we've just copied the openssl formatting, but there's a lot of detail there, some of which isn't commonly needed. As a strawman I propose something like the following:

$ step certificate inspect --short site.crt
X.509v3 TLS Certificate (ECDSA P256) [Serial: 3887...5350]
  Subject:     hello-mtls.default.svc.cluster.local
  Issuer:      Autocert Intermediate CA
  Provisioner: autocert [ID: 7oOZgiEg...]
  Valid from:  Jan 19 01:59:06 2019 UTC
          to:  Jan 20 01:59:06 2019 UTC

With the general format:

X.509v3 <Type> Certificate (<Public Key Algorithm> <Curve | Key Length>) [Serial: <Abbreviated Serial>]
  Subject:     <Subject CN>
  Issuer:      <Issuer CN>
  Provisioner: <Provisioner Name> [ID: <Abbreviated Provisioner CredentialID>]
  Valid from:  <Not Before>
          to:  <Not After>

Where <Abbreviated Serial> is the first four characters of the serial number + ... + the last four characters (because serial numbers are often sequential); <Abbreviated Provisioner CredentialID> is the first 8 characters of the CredentialID (if there is one) + ...; and <Type> is:

• TLS if extended key usage is TLS Web Server Authentication and/or TLS Web Client Authentication
• CA if isCA is true
• Not present for any other uses (including when a cert is both TLS and CA), in which case the first line will just be "X.509v3 Certificate ..."

Add provisioner support for AWS

Description

Add a new provisioner type to grant certificates using AWS instance identity documents
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html

Consider adding the OTTMap to the NoopDB and slightly changing the name and function of the NoopDB to capture in mem operations when no database is configured.

Decide on enforcing mTLS on default methods

Description

The default methods (the ones with shorter/nicer names) of the CA SDK only verify the client certificate if it is provided, but there are also methods to enforce the mTLS and require a valid certificate, but they have a more obscure name:

Method	mTLS enforced
client.GetServerTLSConfig	false
client.GetServerMutualTLSConfig	true
BootstrapServer	false
BootstrapServerWithMTLS	true

We should consider if we want to switch the behavior and use mTLS in those 'default' methods

custom reload for certificates (close OSS gap)

https://github.com/smallstep/certificates/blob/master/ca/ca.go#L130-L146
We can do this in two different ways:

1. Create a new type CA in step that inherits certificates’ CA and replace the Reload
2. Change certificates CA to allow to pass a new LoadConfiguration method, that can be passed in New options and will replace the default one.
   I’m more in favor of 2, as we can also use LoadConfiguration from a db, configmap, …

IID provisioners get "0s" instance age by default

When I run step ca provisioner add aws --type AWS --aws-account XXXX I end up with a provisioner configuration that has "instanceAge": "0s". In other words, default instanceAge is “0s”. That ends up meaning “don’t enforce instance age”, which is weird.

I figure that “0s” is the default value for whatever the duration object is in golang… so it’s probably hard to distinguish between “0s” and the value simply not being defined in configuration… but it still feels weird. Is there anything easy we can do to make this more intuitive?

Compatibility with CSRs that have no SANs.

Compatibility with CSRs that have no SANs.

Currently step enforces SAN compatibility in a number of different places in cli and certificates which makes thinking about and changing the codebase difficult.

step cli - All tokens not generated directly from a CSR will have a default SAN (the subject common name) if the SANs have been left empty.
step certificates - If the token has no SANs then the subject of the of the CSR will be added to the token as a SAN. This was originally added for backwards compatibility b/c certs generated by step cli always added the common name as a SAN, while the tokens did not.

This logic is confusing and does not work correctly in the case where a CSR with no SANs is passed to step ca sign. The token will be created by step cli correctly (w/out additional SANs), but step certificates will add a SAN to the token which will break authentication.

step-ca does not listen on address for `step ca init -address`

Subject of the issue

The -address argument passed to step ca init does not change the address step-ca server will listen on. In the reproducer below step-ca will serve on port 8443 regardless of $CA_PORT used with -address option.

Your environment

• OS - ubuntu:bionic (official docker image)
• Version - latest

Steps to reproduce

Repo here

docker-entrypoint.sh

#!/bin/bash

echo CA_PORT=$CA_PORT

step ca init \
  -name="The Step CA Test" \
  -dns=localhost \
  -address=127.0.0.1:$CA_PORT \
  [email protected] \
  -password-file=/files/ca.password && \
step-ca --password-file=/files/ca.password /.step/config/ca.json

docker-compose up output

ca_1  | CA_PORT=10433
ca_1  | 
ca_1  | Generating root certificate... 
ca_1  | all done!
ca_1  | 
ca_1  | Generating intermediate certificate... 
ca_1  | all done!
ca_1  | 
ca_1  | ✔ Root certificate: /root/.step/certs/root_ca.crt
ca_1  | ✔ Root private key: /root/.step/secrets/root_ca_key
ca_1  | ✔ Root fingerprint: 2f70cfc7f3f09e089df345c896f2d0e7825c82fdefa002b733a50582e8140bde
ca_1  | ✔ Intermediate certificate: /root/.step/certs/intermediate_ca.crt
ca_1  | ✔ Intermediate private key: /root/.step/secrets/intermediate_ca_key
ca_1  | ✔ Default configuration: /root/.step/config/defaults.json
ca_1  | ✔ Certificate Authority configuration: /root/.step/config/ca.json
ca_1  | ✔ Database: /root/.step/db
ca_1  | 
ca_1  | ...
ca_1  | 
ca_1  | 2019/09/28 13:56:42 Serving HTTPS on 127.0.0.1:8443 ...

Expected behaviour

step-ca should start a server listening on 127.0.0.1:10443.

Actual behaviour

step-ca will start a server listening on 127.0.0.1:8443.

Additional context

I'm following the Getting Started Guide on a single host.

Not re-setting ca.config, ca.auth, etc.

The reload replaces the server but does not set the internal attributes of ca to the new ones (config, auth, etc.) derived from loading a new configuration.

https://github.com/smallstep/certificates/blob/master/ca/ca.go#L131-L149

Was able to see this by logging the internals of ca.config at the end of the reload execution. The internal attributes are still tied to the old configuration.

Caddy 2 integration

I'm very excited to see Smallstep's announcement today, congrats!

You've kind of beat me to the chase -- part of Caddy 2's original design plans was to include an integrated certificate authority for internal key infrastructure. Basically smallstep, but integrated.

I have yet to test it out myself, but from the docs and demos it seems that you're knocking that out of the park already. So I don't see any need to reinvent the wheel here.

What would you like to be added

I want to see smallstep become a Caddy 2 app.

Caddy 2 can run any kind of Go service:

type App interface {
	Start() error
	Stop() error
}

If you can wrap the Smallstep CA server with these two methods and make it configurable via a JSON Unmarshal, then I think we're golden, at least for getting started.

There is a detailed doc here that explains how to write Caddy modules: https://github.com/caddyserver/caddy/wiki/v2:-Writing-a-Module

Why this is needed

Right now, using Smallstep with any web server requires extra steps (no pun intended). This could be eliminated if it "just worked" in the web server directly.

Caddy 2 already nails automatic HTTPS for public domains and certs. It makes sense that it should "just work" in a cluster for internal PKI as well. I think Smallstep can make this possible.

Basically, I envision a simple Caddy config, something like this:

{
	"apps": {
		"smallstep": {
			// smallstep config goes here
		},
		"http": {
			// reverse proxy config goes here
		}
	}
}

One possible advantage here is that the ACME/CA server could potentially run in a distributed fashion similar to how Caddy does for certificate management: by configuring the fleet to use the same storage, it can automatically coordinate cert management. I see an advantage here for Smallstep doing something similar for its issuance processes.

Now, maybe this exact way of doing the integration isn't optimal. But we should talk about it. I want to open the discussion to see how we can integrate Caddy 2 and Smallstep. I can help with the integration, but I can't do it all myself.

Also, I'd be happy to invite your team to our development Slack. Just let me know which emails to invite.

Provisioner should be authorized to issue certificates for the CN

A useful feature to allow workflows for more complex environments/organizations.

step-ca tries to recreate the mysql tables every time it starts

Subject of the issue

step-ca fails to run after the mysql tables have already been created.

Your environment

• OS - Ubuntu 18.04
• Version - step-ca version 0.13.2-dev

Steps to reproduce

1. Create mysql database
2. Add appropriate mysql config to the db config section:

   "db": {
    "type": "mysql",
    "dataSource": "admin:admin@tcp(mysqlhost:3306)/",
    "database": "stepCA"
  },

3. Run step-ca (step-ca .step/config/ca.json)
4. stop step-ca
5. run step-ca again (step-ca .step/config/ca.json)

Expected behaviour

step-ca should start up and use the existing tables

Actual behaviour

step-ca fails to start with the following error:

error creating table revoked_x509_certs: failed to create table revoked_x509_certs: Error 1050: Table 'revoked_x509_certs' already exists

Additional context

N/A

How to configure as an intermediate CA under an external root CA

Description

Add docs on how to install step-ca only as an intermediate ca under an external root ca.

ACME order object responses from step-ca seem to not be setting the notBefore and notAfter

the order object responses from step-ca seem to not be setting the notBefore and notAfter dates correctly, e.g.:

201 CREATED
{ status: 'pending',
  expires: '2019-08-23T19:05:14Z',
  identifiers:
   [ { type: 'dns', value: 'bar.internal' } ],
  notBefore: '0001-01-01T00:00:00Z',
  notAfter: '0001-01-01T00:00:00Z',
  authorizations:
   [ 'https://acme.internal/acme/acme/authz/N1nCcoVpQWXOF88errGA84eLn2BQNHIm' ],
  finalize: 'https://acme.internal/acme/acme/order/IHcUVXQKElaGFXenvHRphPZ7e0Pk7L4A/finalize' }

Bootstrap token audience incorrect

When the CA is initialized we ask for two separate bits of information:

1. The DNS name that clients will use to connect to the CA
2. The listen address that the CA will use

We ask for these things separately because the DNS name must be bound in the certificate used by the online CA and may not match the listen address (e.g., the DNS name may be ca.smallstep.com while the listen address is :8080).

We never explicitly ask for the audience that the CA should expect in JWT bootstrap tokens. Instead, that value is constructed by combining the DNS name and the port from the listen address specified above. That's weird, and I think we need to reconsider this decision.

This approach breaks the kubernetes use case that originally motivated this design. If you have the CA listen on a non-privileged port (e.g., 4443) and create a service that redirects traffic from port 443 to 4443 the CA clients will be connecting to something like https://ca.smallstep.com:443 but the CA will expect an audience of https://ca.smallstep.com:4443, resulting in a validation error at the CA.

As a strawman, I propose we strip the port from the JWT audience. This would be consistent with HTTPS, which does not consider the port that a web server is listening on during certificate path validation (e.g., a certificate for foo.example.com works for any port).

Version not appearing in homebrew installed `step-ca`

brew installed step-ca does not return correct version.

max @ maxs-mbp ~/src/github.com/smallstep/certificates (master *$%=) $ step-ca version
Smallstep CA/ (darwin/amd64)
Release Date: 2019-02-13 00:05 UTC

Add provisioner support for Azure

Description

Add a new provisioner type to grant certificate using Azure version of identity documents.
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service

Default validation user supplied public keys when creating SSH certificates

Default validation user supplied public keys when creating SSH certificates

Specifically validating that RSA keys have at least 256 bytes.

Why this is needed

Because otherwise we'll sign an RSA key of any length, and keys with <256 bytes are known to be insecure.

Comments

It's complicated to perform this validation as a signOption created by the provisioner because golang SSH uses an interface for public keys which makes it difficult to access any details about the actual key (e.g. the size).
One option would be to add the public key to the context here https://github.com/smallstep/certificates/blob/master/api/ssh.go#L131 and then just validate it immediately in the provisioner.authorizeSignSSH method (instead of adding it to the signOptions for later validation against the cert).

Feature Request: SCEP Support?

Subject of the issue

Hi, do you plan to support SCEP (https://tools.ietf.org/html/draft-nourse-scep-23) in your Client tool and server? I couldn't find it in your repository. It would be tremendously useful. If you support it in your client, it would help adoption and migration rate, i bet :)