Vault 0.4

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 for more information.

The default Policy

Vault now automatically adds a policy named default to each token created. (There is an opt-out available for direct token-create commands and the associated API call.) The purpose of this is to ensure that tokens, by default, have access to API functions that are almost universally useful and can cause confusing errors if access is denied.

The default policy as created by Vault contains the following:

path "auth/token/lookup-self" { policy = "read" }

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

First we'll add two PKI mounts: one to serve as a root and the second to serve as an intermediate. Then we'll tune both to have long lifetimes (the lifetime of the root certificate cannot be greater than the maximum TTL set on the mount). It is best practice to restrict access to the root CA (ideally, at all times when not actively in use), so using separate mounts is recommended.

$ vault mount -path=rootpki pki $ vault mount-tune -max-lease-ttl="175200h" rootpki $ vault mount -path=intermediatepki pki

Endpoint URLs

Before generating the root, we'll also configure the issuing certificate and CRL distribution point URLs. This will allow them to be encoded in issued certificates.

$ vault write rootpki/config/urls issuing_certificates="http://vault.example.com:8200/v1/rootpki/ca" crl_distribution_points="http://vault.example.com:8200/v1/rootpki/crl"

Generating Self-Signed Roots

Both the root and intermediate generation endpoints allow specifying exported or internal handling of the private keys, controlling whether or not they are returned to the caller. Since this is a part of the path, ACLs can control whether callers are allowed to ever see the private key (for instance, for backup purposes). The key cannot be retrieved at any future time.

$ vault write rootpki/root/generate/exported common_name=example.com ttl="175200h" Key Value lease_id rootpki/root/generate/exported/0e3a656e-bfa5-230a-0586-b418e88ed1b2 lease_duration 630719999 lease_renewable false certificate -----BEGIN CERTIFICATE----- MIID1jCCAr6gAwIBAgIUOE9NYmt2uIJ1QVMyspWSOd/NGq4wDQYJKoZIhvcNAQEL BQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMTUxMjA2MDEyMjI4WhcNMzUx MjAxMDEyMjI4WjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMX+1i22OYMj9hmRPVKHxaDrcmZJ92+9lqdyHmFv 6JXt8V/N4TnFzFD9Cz5BsfJ/NZUxOxhZNEOTsqjwZnEM/kGxnnYmgfZSdfxDEBrr fQyOZdwMzJGMDKvhGrJT52JTcQSeSzTJeVXt5CvDmZi27F/z2kkQhNUYFowyrESL Qnw6M3TvxeS7VQB3cLZN1qDdLBLOUwIrbbnyBCxqkTFIuaDzask9N14S6k7X7XtN WzVo8iHyxZojicN/NWff+bR22pnNzPELgUf/3qEiSfEfpNVoO3WFPSf9XW5TCezb hL/3JkrCJ2Jk5ne1Io52qzTAbkh3y7HpAzEqofc3nXwawXECAwEAAaOCARowggEW MA4GA1UdDwEB/wQEAwIBrjATBgNVHSUEDDAKBggrBgEFBQcDCTAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBTPZ2caizJe/ip8NOzjcSBv8mm7PDAfBgNVHSMEGDAW gBTPZ2caizJe/ip8NOzjcSBv8mm7PDBHBggrBgEFBQcBAQQ7MDkwNwYIKwYBBQUH MAKGK2h0dHA6Ly92YXVsdC5leGFtcGxlLmNvbTo4MjAwL3YxL3Jvb3Rwa2kvY2Ew FgYDVR0RBA8wDYILZXhhbXBsZS5jb20wPQYDVR0fBDYwNDAyoDCgLoYsaHR0cDov L3ZhdWx0LmV4YW1wbGUuY29tOjgyMDAvdjEvcm9vdHBraS9jcmwwDQYJKoZIhvcN AQELBQADggEBAL6bQ9sETETzt0lLKoFXigmAn6Ke7HYQ6Yh2RWwGyTsK7NHJFX+y 9CICvB/UTCCl5KDPs6PLxmzibwsodIIYCgn05BMgprbMPZFHgsE9TS/6XlSpC1mJ lrHEDeA5Nzo9bWOrLeIQcJNMrvxZWX6u9aY/oRyfqDtw3b9V8NBcONaG7yVlvyGo 1jxzt9Iiyf+oQXLUhbfqq0RB+UnBblSpaMRNd5uqDekYR5WMXpfPrOgZisJ2t+Tb jUkTRIi2kH2NvdOgOei9w20LMdFNMgQ66H9AlmUSVKH6qJXvkHDW9mF5hVhWtZLj ppRQjEgaIcZ79OVwmaD2i15Xbvf72ANmBSE= -----END CERTIFICATE----- expiration 2.080084948e+09 issuing_ca -----BEGIN CERTIFICATE----- MIID1jCCAr6gAwIBAgIUOE9NYmt2uIJ1QVMyspWSOd/NGq4wDQYJKoZIhvcNAQEL ... ppRQjEgaIcZ79OVwmaD2i15Xbvf72ANmBSE= -----END CERTIFICATE----- private_key -----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAxf7WLbY5gyP2GZE9UofFoOtyZkn3b72Wp3IeYW/ole3xX83h ... Fg/sOe3Cx1vCc+M/hjaRTq3CnQJGOUCSnMF/XkhjtVQLk6awNDuF7g== -----END RSA PRIVATE KEY----- private_key_type rsa serial_number 38:4f:4d:62:6b:76:b8:82:75:41:53:32:b2:95:92:39:df:cd:1a:ae

Looking at the certificate, we can see that it is its own issuer and the signing key matches the subject key:

Certificate: Data: Version: 3 (0x2) Serial Number: 38:4f:4d:62:6b:76:b8:82:75:41:53:32:b2:95:92:39:df:cd:1a:ae Signature Algorithm: sha256WithRSAEncryption Issuer: CN=example.com Validity Not Before: Dec 6 01:22:28 2015 GMT Not After : Dec 1 01:22:28 2035 GMT Subject: CN=example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c5:fe:d6:2d:b6:39:83:23:f6:19:91:3d:52:87: c5:a0:eb:72:66:49:f7:6f:bd:96:a7:72:1e:61:6f: e8:95:ed:f1:5f:cd:e1:39:c5:cc:50:fd:0b:3e:41: b1:f2:7f:35:95:31:3b:18:59:34:43:93:b2:a8:f0: 66:71:0c:fe:41:b1:9e:76:26:81:f6:52:75:fc:43: 10:1a:eb:7d:0c:8e:65:dc:0c:cc:91:8c:0c:ab:e1: 1a:b2:53:e7:62:53:71:04:9e:4b:34:c9:79:55:ed: e4:2b:c3:99:98:b6:ec:5f:f3:da:49:10:84:d5:18: 16:8c:32:ac:44:8b:42:7c:3a:33:74:ef:c5:e4:bb: 55:00:77:70:b6:4d:d6:a0:dd:2c:12:ce:53:02:2b: 6d:b9:f2:04:2c:6a:91:31:48:b9:a0:f3:6a:c9:3d: 37:5e:12:ea:4e:d7:ed:7b:4d:5b:35:68:f2:21:f2: c5:9a:23:89:c3:7f:35:67:df:f9:b4:76:da:99:cd: cc:f1:0b:81:47:ff:de:a1:22:49:f1:1f:a4:d5:68: 3b:75:85:3d:27:fd:5d:6e:53:09:ec:db:84:bf:f7: 26:4a:c2:27:62:64:e6:77:b5:22:8e:76:ab:34:c0: 6e:48:77:cb:b1:e9:03:31:2a:a1:f7:37:9d:7c:1a: c1:71 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Key Agreement, Certificate Sign, CRL Sign X509v3 Extended Key Usage: OCSP Signing X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: CF:67:67:1A:8B:32:5E:FE:2A:7C:34:EC:E3:71:20:6F:F2:69:BB:3C X509v3 Authority Key Identifier: keyid:CF:67:67:1A:8B:32:5E:FE:2A:7C:34:EC:E3:71:20:6F:F2:69:BB:3C

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.

$ vault write rootpki/root/sign-intermediate csr=@csr.pem use_csr_values=true ttl=4380h Key Value lease_id rootpki/root/sign-intermediate/00d5010c-7376-aab8-d0b3-b507fc0151bd lease_duration 15767999 lease_renewable false serial_number 79:94:96:cb:13:3a:3b:99:b2:fd:c4:7a:70:ad:ee:b5:b2:c6:64:61 certificate -----BEGIN CERTIFICATE----- MIID6TCCAtGgAwIBAgIUeZSWyxM6O5my/cR6cK3utbLGZGEwDQYJKoZIhvcNAQEL BQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMTUxMjA2MDEzMDEyWhcNMTYw NjA1MTMzMDEyWjAcMRowGAYDVQQDExF2YXVsdC5leGFtcGxlLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKEex8ZQMCYOIYW1T4lofJ6kh0ezzCNW VH5NJl+ty1MtyOfOn4xKXIRKND0FWN/hNJeLLiioNAQlUpYADqcgQlp19df+i7qO yn5kdlXkNbss3yLrr+4P8VG4F/yzlsgzw/FvmMZvePuRFjxxYLKsHeAKXBh7948T Hu7ZBrhvdvdnu/YK/UrnMiar+Uldb2U9fpz6PbVlxZcWzvxsK7zov54S48s/p/dj 2r7Zk3KQI5jRLrHfmvUoFNr7L5Lu2DV0m34yQ8q0iiqEYdxdpfK4XS4iGCLTk6Lv ojIzeUZOQTahTKCJOInAuK8vdSVllitOcSfbRvDlY2QurLnOuOxAgs0CAwEAAaOC AScwggEjMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFFmpZaeBuwhC5VgXVkwZ GD66N0L4MB8GA1UdIwQYMBaAFM9nZxqLMl7+Knw07ONxIG/yabs8MEcGCCsGAQUF BwEBBDswOTA3BggrBgEFBQcwAoYraHR0cDovL3ZhdWx0LmV4YW1wbGUuY29tOjgy MDAvdjEvcm9vdHBraS9jYTA9BgNVHR8ENjA0MDKgMKAuhixodHRwOi8vdmF1bHQu ZXhhbXBsZS5jb206ODIwMC92MS9yb290cGtpL2NybDBIBgNVHREEQTA/ghF2YXVs dC5leGFtcGxlLmNvbYIRaW50Y2EuZXhhbXBsZS5jb22BEXZhdWx0LmV4YW1wbGUu Y29thwR/AAABMA0GCSqGSIb3DQEBCwUAA4IBAQAmyiGljiIMYjU4nG0pdNfZey4i JN/jZ68I1JzlIXCvJL5zvzKu4dkZvpoJxuDnDq/qWBGBKsuLIth8UyW33yfTw6iu QHjl7GaCwk2upkDfOhjXy6dnfCtx7ETHfYj8m2nahB4/R1JXG8NlUGhSBMUgu6aK ITcHKgvm8vQTQKGQSs6ycbDbq9Qu2Vi4HyM8RDWUQ30hdgzUuvEmFys2Izb+R0us HK4nYCgmVraKfmUH/GH+B6VhhqiU8lGaVX/iLYGulFtgWUV/ee0cFY7eRKsZRpm7 tLUfY3mGSAu6J+HmtiEXXbCtuzB4+PIa2b+mYwlsxCkCJekAx7J5wVYP10mh -----END CERTIFICATE----- expiration 1.465133412e+09 issuing_ca -----BEGIN CERTIFICATE----- MIID1jCCAr6gAwIBAgIUOE9NYmt2uIJ1QVMyspWSOd/NGq4wDQYJKoZIhvcNAQEL ... ppRQjEgaIcZ79OVwmaD2i15Xbvf72ANmBSE= -----END CERTIFICATE-----

Checking the returned certificate, we can see that the signing information matches our root CA, the URLs are set to point to the issuing (root) CA and its CRL, and that the various alternate names are present:

$ openssl x509 -in cert.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 79:94:96:cb:13:3a:3b:99:b2:fd:c4:7a:70:ad:ee:b5:b2:c6:64:61 Signature Algorithm: sha256WithRSAEncryption Issuer: CN=example.com Validity Not Before: Dec 6 01:30:12 2015 GMT Not After : Jun 5 13:30:12 2016 GMT Subject: CN=vault.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:a1:1e:c7:c6:50:30:26:0e:21:85:b5:4f:89:68: 7c:9e:a4:87:47:b3:cc:23:56:54:7e:4d:26:5f:ad: cb:53:2d:c8:e7:ce:9f:8c:4a:5c:84:4a:34:3d:05: 58:df:e1:34:97:8b:2e:28:a8:34:04:25:52:96:00: 0e:a7:20:42:5a:75:f5:d7:fe:8b:ba:8e:ca:7e:64: 76:55:e4:35:bb:2c:df:22:eb:af:ee:0f:f1:51:b8: 17:fc:b3:96:c8:33:c3:f1:6f:98:c6:6f:78:fb:91: 16:3c:71:60:b2:ac:1d:e0:0a:5c:18:7b:f7:8f:13: 1e:ee:d9:06:b8:6f:76:f7:67:bb:f6:0a:fd:4a:e7: 32:26:ab:f9:49:5d:6f:65:3d:7e:9c:fa:3d:b5:65: c5:97:16:ce:fc:6c:2b:bc:e8:bf:9e:12:e3:cb:3f: a7:f7:63:da:be:d9:93:72:90:23:98:d1:2e:b1:df: 9a:f5:28:14:da:fb:2f:92:ee:d8:35:74:9b:7e:32: 43:ca:b4:8a:2a:84:61:dc:5d:a5:f2:b8:5d:2e:22: 18:22:d3:93:a2:ef:a2:32:33:79:46:4e:41:36:a1: 4c:a0:89:38:89:c0:b8:af:2f:75:25:65:96:2b:4e: 71:27:db:46:f0:e5:63:64:2e:ac:b9:ce:b8:ec:40: 82:cd Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 59:A9:65:A7:81:BB:08:42:E5:58:17:56:4C:19:18:3E:BA:37:42:F8 X509v3 Authority Key Identifier: keyid:CF:67:67:1A:8B:32:5E:FE:2A:7C:34:EC:E3:71:20:6F:F2:69:BB:3C

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.

As always, we recommend upgrading and testing this release in an isolated environment. If you experience any issues, please report them on the Vault GitHub issue tracker or post to the Vault mailing list.

We hope you enjoy Vault 0.4!

close modal

Request a Demo

Fill out the form below and we'll reach out to discuss a product demo.

check mark
check mark
check mark
check mark
Select an option
  • Select one
  • Terraform
  • Nomad
  • Vault
  • Consul
Trusted by
  • Adobe Logo
  • Barclays Logo
  • Cisco Logo
  • Citadel Logo
  • DigitalOcean Logo
  • Hewlett Packard Enterprise Logo
  • SAP Arabia Logo
  • New Relic Logo
  • Pinterest Logo
  • Segment Logo
  • Spaceflight Logo
  • Stripe Logo