HashiCorp Vault 0.4

HashiCorp Vault 0.4

Dec 10 2015 Jeff Mitchell

We are proud to announce the release of Vault 0.4. Vault is a tool for managing secrets. From storing credentials and API keys to encrypting sensitive data to managing access to external systems, Vault is meant to be a solution for all secret management needs.

Vault 0.4 brings significant enhancements to the pki backend, CRL checking for certificate authentication, a default policy, and a long list of improvements and bug fixes. Please see the full Vault 0.4 CHANGELOG for more details.

As always, a big thanks to our community for their ideas, bug reports, and pull requests.

You can download Vault 0.4 from the project website. Upgrade information is available at the end of this post.

Read on to learn more about the major new features in Vault 0.4.

CRL Revocation Checking for Certificate Authentication

The cert authentication backend now allows uploading CRLs. Each CRL is identified by a name and can be updated or removed individually. The way that CRLs are handled is similar to Chrome's CRLSets: Vault strives to behave deterministically, and as a result it does not perform CRL fetching itself, avoiding guesswork and edge cases around soft-fail conditions.

When a user attempts to authenticate to Vault with a TLS certificate, the serial number on the certificate is checked against the serial numbers contained in the existing CRLs. If the serial number is contained in any provided CRL, authentication is denied.

See the backend documentation

path "auth/token/renew-self" { policy = "write" }

path "auth/token/revoke-self" { policy = "write" }

The policy simply gives access to the renew, revoke, and lookup functions for the token itself. In general, there is no reason for tokens to not have access to these endpoints; however, while the policy cannot be deleted, you are free to modify the policy however you wish (including removing its contents) after it is created.

If you already have a policy named default, Vault will not overwrite it.

PKI Backend Enhancements

Vault's pki secret backend has received significant enhancements in 0.4. Prior to now, the backend allowed an uploaded CA certificate to be used to issue certificates and associated private keys to callers. The new features added in 0.4 include:

  • Generating self-signed roots

  • Signing intermediate CA CSRs

  • Flexible handling of URLs encoded in certificates

  • Signing of client CSRs

  • Handling of multiple domains within a single role

  • More supported certificate options/features

Some of these will be detailed below, showing examples of the commands and output. For ease of showing the examples the Vault CLI will be used, but since the CLI is simply a wrapper around Vault's JSON API, all functionality is available via the API.

Note that not all options are shown here (or elsewhere in this post); for instance, when generating CAs, there are options to control the key type and length, output format, maximum path length, and more. The documentation shows the full API with all available options.

First Steps

Authority Information Access: 
  CA Issuers - URI:http://vault.example.com:8200/v1/rootpki/ca

X509v3 Subject Alternative Name: 
  DNS:example.com
X509v3 CRL Distribution Points: 

  Full Name:
    URI:http://vault.example.com:8200/v1/rootpki/crl

Signature Algorithm: sha256WithRSAEncryption be:9b:43:db:04:4c:44:f3:b7:49:4b:2a:81:57:8a:09:80:9f: a2:9e:ec:76:10:e9:88:76:45:6c:06:c9:3b:0a:ec:d1:c9:15: 7f:b2:f4:22:02:bc:1f:d4:4c:20:a5:e4:a0:cf:b3:a3:cb:c6: 6c:e2:6f:0b:28:74:82:18:0a:09:f4:e4:13:20:a6:b6:cc:3d: 91:47:82:c1:3d:4d:2f:fa:5e:54:a9:0b:59:89:96:b1:c4:0d: e0:39:37:3a:3d:6d:63:ab:2d:e2:10:70:93:4c:ae:fc:59:59: 7e:ae:f5:a6:3f:a1:1c:9f:a8:3b:70:dd:bf:55:f0:d0:5c:38: d6:86:ef:25:65:bf:21:a8:d6:3c:73:b7:d2:22:c9:ff:a8:41: 72:d4:85:b7:ea:ab:44:41:f9:49:c1:6e:54:a9:68:c4:4d:77: 9b:aa:0d:e9:18:47:95:8c:5e:97:cf:ac:e8:19:8a:c2:76:b7: e4:db:8d:49:13:44:88:b6:90:7d:8d:bd:d3:a0:39:e8:bd:c3: 6d:0b:31:d1:4d:32:04:3a:e8:7f:40:96:65:12:54:a1:fa:a8: 95:ef:90:70:d6:f6:61:79:85:58:56:b5:92:e3:a6:94:50:8c: 48:1a:21:c6:7b:f4:e5:70:99:a0:f6:8b:5e:57:6e:f7:fb:d8: 03:66:05:21

Generating An Intermediate CA CSR

We can generate an intermediate CA CSR. The only required value is common_name, which may or may not be honored at signing time. If signing by Vault, we can choose whether to respect the values on the CSR, or overwrite them (essentially, only carrying over the key information from the CSR).

$ vault write intermediatepki/intermediate/generate/exported common_name=vault.example.com alt_names="security@example.com,intca.example.com" ip_sans="127.0.0.1" Key Value csr -----BEGIN CERTIFICATE REQUEST----- MIICvDCCAaQCAQAwHDEaMBgGA1UEAxMRdmF1bHQuZXhhbXBsZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChHsfGUDAmDiGFtU+JaHyepIdHs8wj VlR+TSZfrctTLcjnzp+MSlyESjQ9BVjf4TSXiy4oqDQEJVKWAA6nIEJadfXX/ou6 jsp+ZHZV5DW7LN8i66/uD/FRuBf8s5bIM8Pxb5jGb3j7kRY8cWCyrB3gClwYe/eP Ex7u2Qa4b3b3Z7v2Cv1K5zImq/lJXW9lPX6c+j21ZcWXFs78bCu86L+eEuPLP6f3 Y9q+2ZNykCOY0S6x35r1KBTa+y+S7tg1dJt+MkPKtIoqhGHcXaXyuF0uIhgi05Oi 76IyM3lGTkE2oUygiTiJwLivL3UlZZYrTnEn20bw5WNkLqy5zrjsQILNAgMBAAGg WzBZBgkqhkiG9w0BCQ4xTDBKMEgGA1UdEQRBMD+CEXZhdWx0LmV4YW1wbGUuY29t ghFpbnRjYS5leGFtcGxlLmNvbYERdmF1bHQuZXhhbXBsZS5jb22HBH8AAAEwDQYJ KoZIhvcNAQELBQADggEBABUix0X4EVVn3FAhq9FUwswCM+PpTR8Slf8YrE3HNkkN Op/6jNewX0WRb8RXNG8JvT4ud6lhxcO3UwGqXvgD4Lx8OqkhKxG6e1kxkONkyfxn MKss84XUBDY5hsCjG2x5bduqdye9QZcjtdM6GrEs+qd41po1N2umWOm6rTwaT2kc Vu3k4Zr0+PTbMgZZOyjArh8C5HrS5bvT/1DvqrLRFuv5MiaefpbwZ80/MDoWYyEk 0us6+Ly3FF9Jf7/0kpgtdUsBfDZAbWYq4EgbGgJJlL3Ujfcb2tWhaDnlXimw+DNJ xGgQ+w7N3N+kxdtkQOC87WvZPuMHpEiX1jusG3lVv38= -----END CERTIFICATE REQUEST----- private_key -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAoR7HxlAwJg4hhbVPiWh8nqSHR7PMI1ZUfk0mX63LUy3I586f ... 9sZjU3lwqwcvCDId+dNytkAZxWP0zP6pu3ADJnMlCi6D/atnFt8i -----END RSA PRIVATE KEY----- private_key_type rsa

Signing an Intermediate CA CSR

In this example, we will use the root to sign the intermediate CA CSR that was generated in the step above, after saving the CSR to a file. Although we could override the CSR values, here we will sign them verbatim.

Authority Information Access: 
  CA Issuers - URI:http://vault.example.com:8200/v1/rootpki/ca

X509v3 CRL Distribution Points: 

  Full Name:
    URI:http://vault.example.com:8200/v1/rootpki/crl

X509v3 Subject Alternative Name: 
  DNS:vault.example.com, DNS:intca.example.com, email:vault.example.com, IP Address:127.0.0.1

Signature Algorithm: sha256WithRSAEncryption 26:ca:21:a5:8e:22:0c:62:35:38:9c:6d:29:74:d7:d9:7b:2e: 22:24:df:e3:67:af:08:d4:9c:e5:21:70:af:24:be:73:bf:32: ae:e1:d9:19:be:9a:09:c6:e0:e7:0e:af:ea:58:11:81:2a:cb: 8b:22:d8:7c:53:25:b7:df:27:d3:c3:a8:ae:40:78:e5:ec:66: 82:c2:4d:ae:a6:40:df:3a:18:d7:cb:a7:67:7c:2b:71:ec:44: c7:7d:88:fc:9b:69:da:84:1e:3f:47:52:57:1b:c3:65:50:68: 52:04:c5:20:bb:a6:8a:21:37:07:2a:0b:e6:f2:f4:13:40:a1: 90:4a:ce:b2:71:b0:db:ab:d4:2e:d9:58:b8:1f:23:3c:44:35: 94:43:7d:21:76:0c:d4:ba:f1:26:17:2b:36:23:36:fe:47:4b: ac:1c:ae:27:60:28:26:56:b6:8a:7e:65:07:fc:61:fe:07:a5: 61:86:a8:94:f2:51:9a:55:7f:e2:2d:81:ae:94:5b:60:59:45: 7f:79:ed:1c:15:8e:de:44:ab:19:46:99:bb:b4:b5:1f:63:79: 86:48:0b:ba:27:e1:e6:b6:21:17:5d:b0:ad:bb:30:78:f8:f2: 1a:d9:bf:a6:63:09:6c:c4:29:02:25:e9:00:c7:b2:79:c1:56: 0f:d7:49:a1

And more!

With this release Vault can serve as a full-fledged CA while maintaining the same authn/authz, zero-trust, short-credential, and easy JSON API paradigms that we strive for throughout Vault. There are many more enhancements to the PKI backend than will fit in a release blog post. We encourage you to look at the API in the backend's documentation and see all of the things it can do.

Upgrade Details

There are a few minor breaking API changes in the PKI backend, and the default port number for etcd physical storage has changed to the official port number for 2.x installations. See the CHANGELOG and (PKI backend documentation](https://www.vaultproject.io/docs/secrets/pki/index.html) for more details.

In addition, if you already have a policy named default, you will want to consider whether its contents are suitable for adding to all tokens before upgrading, and migrate those rules to a different policy if not.

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×