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