Signing Certificate Requests
Signing Certificates
Introduction
The premise is that all keys / certificates need to have a very short lifespan. As an example, rsyslog uses signed certificates so that each log client has a certificate that can be verified by the log server. The log server also has a signed certificate. So a long at the Root CA is secured, then the certificates can be used to validate (and encrypt) client and server traffic. However if an individual client is comprimised, it’s certificate becomes suspect - the attack can get the private key. The attacker could also, depending on setup, get the comprimised key signed by the Root CA. So making the keys short lived means the attacker would have to continuously be able to intercept keys. This is slightly more secure.
The configuration is that the vault agent runs as a separate account / process and is creating new private keys and getting those signed on a short ttl. The vault agent uses the appRole engine which has a pre-shared SecretId and RoleId. The RoleId is essentially public, while the SecretId is short lived. The SecretId is updated with each request.
All of the secrets are wrapped responses, so the separate account / process creates the private keys, gets them signed, and then the client will pull the wrapped secretId from the vault when it needs it.
Retrieve Token User Story
As a system, I want to get a token from the vault so I can request a certificate
Acceptance Criteria
- The system generating the CSR has the assigned appRoleId “minibus/csr”
- The system generating the CSR has a pre-assigned MINIBUS_CSR_SECRET_ID as an environment variable
- The Vault server returns a valid Token
Example
ROLE_ID=vault read -format=json auth/approle/role/minibus-generate-sign-server-keys/role-id | jq ‘.data.role_id’ SECRET_ID=vault write -format=json -force auth/approle/role/minibus-generate-sign-server-keys/secret-id | jq ‘.data.secret_id’ VAULT_TOKEN=vault write -format=json auth/approle/login role_id=”abb7d74f-9c1c-a99c-a712-7fdd4febe144” secret_id=”7f5a4538-a763-c09d-1e06-e6e710855fb2” | jq ‘.auth.client_token’
Generate Certificate User Story
As a system, I want to generate a certificate so that I can request a signature
Acceptance Criteria
- The Root CA is trusted by the server
- POST /pki/issue/:name
- :name is “minibus-server”
- max_ttl is 25 hours which requires once a day renewal with a little clock skew
Example
vault write -format=json pki_int/minibus-server common_name=”test.minib.us”
Submit CSR User Story
As a system, I want to submit the CSR via an HTTPS call so that I can receive the signature easily
Acceptance Criteria
- Header X-Vault-Token include the token retrieved from the appRole authentication engine
- The CSR returned will include “/ST=rengthining/L=iberty/O=minib.us”
-
The common name is the host name or glob: “CN=host3.minib.us”
curl –header “X-Vault-Token: $VAULT_TOKEN”
–request POST
–data ‘{“common_name”: “test.minib.us”, “ttl”: “24h”}’
$VAULT_ADDR/v1/pki_int/issue/minibus