HashiCorp Vault 0.4

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!