Renew KMIP Certificates

Avatar
Gerard Mansvelder
  • Updated

Introduction

Problem

This article explains how to renew KMIP Certificates, used by the Vault KMIP secrets engine.

Prerequisites (if applicable)

  • Vault Enterprise 
  • Vault KMIP Secrets Engine

Explanation:

There are three (3) different certificate types used by the Vault KMIP secrets engine and these secrets engine use their own TCP/IP listener on a seperate port and not those used the Vault API. 
The default port used by the Vault KMIP secrets engine is 5696 which may be configured to any port.

The following certificates are of relevance:

  • The certificate authority and intermediate certificate authority used by the Vault KMIP secrets engine
  • The listener certificate used by the Vault KMIP secrets engine
  • The certificate used by KMIP clients for client authentication

Detailed Explanation

The certificate authority and intermediate certificate authority used by the Vault KMIP secrets engine

The certificate authority and intermediate certificate authority used by the Vault KMIP secrets engine, are generated while enabling the Vault KMIP secrets engine, and have a validity of 10 years. The validity is hard-coded. Currently the only way to renew the certificate authority and intermediate certificate authority is changing the tls_ca_key_type type and changing it back, for example:

Listing existing KMIP keys:

vault list sys/raw/logical/50eb4a82-c265-7db3-6696-41c7993c08c6/managed-objects/QHzzc
Keys
----
T7INpegu8GKLEWvWPR6YCMOBnRdSMy0Y

Reading the current configuration of the Vault KMIP secrets engine:

vault read kmip/config

Key                            Value
---                            -----
default_tls_client_key_bits    256
default_tls_client_key_type    ec
default_tls_client_ttl         336h
listen_addrs                   [0.0.0.0:5696]
server_hostnames               [18.119.235.23]
server_ips                     [127.0.0.1 ::1]
tls_ca_key_bits                2048
tls_ca_key_type                rsa
tls_min_version                tls12

Confirming the validity of the current certificates

echo | openssl s_client -showcerts -connect 127.0.0.1:5696 2>/dev/null | \
awk '/BEGIN CERTIFICATE/{i++} /BEGIN CERTIFICATE/,/END CERTIFICATE/{print >("cert"i)}'

# Now iterate over the separate files created by awk
for file in cert*; do
    echo "--- Certificate from File: $file ---"
    openssl x509 -in "$file" -noout -serial -subject -dates
    rm "$file"  # Clean up the temporary file
done
--- Certificate from File: cert1 ---
serial=6946FCE92A4AF8C08AB1337B8220BCDDB3A1D6CA
subject=CN = 18.119.235.23
notBefore=Nov 12 10:33:39 2025 GMT
notAfter=Nov 12 10:34:09 2026 GMT
--- Certificate from File: cert2 ---
serial=12B746C3BAA36BB9386E8302B6B4D710D2DE2489
subject=CN = vault-kmip-default-intermediate
notBefore=Nov 12 10:04:03 2025 GMT
notAfter=Nov 10 10:04:33 2035 GMT
--- Certificate from File: cert3 ---
serial=41E6975C0546E19C446903C16D66BB53DD9D822D
subject=CN = vault-kmip-default
notBefore=Nov 12 10:04:03 2025 GMT
notAfter=Nov 10 10:04:33 2035 GMT

Changing the tls_ca_key_type for the currently enabled Vault KMIP secrets engine:

vault write  kmip/config tls_ca_key_type=ec
vault write  kmip/config tls_ca_key_type=rsa

Confirming the validity of the current certificates

echo | openssl s_client -showcerts -connect 127.0.0.1:5696 2>/dev/null | \
awk '/BEGIN CERTIFICATE/{i++} /BEGIN CERTIFICATE/,/END CERTIFICATE/{print >("cert"i)}'

# Now iterate over the separate files created by awk
for file in cert*; do
    echo "--- Certificate from File: $file ---"
    openssl x509 -in "$file" -noout -serial -subject -dates
    rm "$file"  # Clean up the temporary file
done
--- Certificate from File: cert1 ---
serial=43DEE3D46810AF9FA4B5ECFD062BD9DD22C4597D
subject=CN = 18.119.235.23
notBefore=Nov 12 11:06:19 2025 GMT
notAfter=Nov 12 11:06:49 2026 GMT
--- Certificate from File: cert2 ---
serial=777617C0515D50D664D867DEB04FB995ECE3BA3E
subject=CN = vault-kmip-default-intermediate
notBefore=Nov 12 11:06:19 2025 GMT
notAfter=Nov 10 11:06:49 2035 GMT
--- Certificate from File: cert3 ---
serial=2D13BB08B590484C2FA29C3BB7D5001A7F55418B
subject=CN = vault-kmip-default
notBefore=Nov 12 11:06:19 2025 GMT
notAfter=Nov 10 11:06:49 2035 GMT

Listing existing KMIP keys:

vault list sys/raw/logical/50eb4a82-c265-7db3-6696-41c7993c08c6/managed-objects/QHzzc

Keys
----
T7INpegu8GKLEWvWPR6YCMOBnRdSMy0Y

Please note that the entire certificate chain, the certificate authority and the intermediate certificate authority, the listener certificate have been recreated with an updated validity. Simply disabling and re-enabling the KMIP secrets engine would result in the loss of any existing KMIP key,
which is why the approach to change the tls_ca_key_type was used instead. Once the certificate authority and intermediate certificate authority have been recreated, new client certificates have to be re-issued using the same scope as used previously. The trusted root certificates used by KMIP clients also have to be replaced.

The listener certificate used by the Vault KMIP secrets engine

When the Vault Service is restarted or a Leadership election occurs, the listener certificate used by Vault KMIP Secrets Engine is automatically regenerated by the Vault KMIP Secrets Engine with a validity of 365 days. Therefore it is not recommend for KMIP clients to trust the listener certificate but the issuing Certificate Authority instead.

The certificate used for client authentication.

Within a scope, roles can be created which dictate the set of allowed operations that the particular role can perform. TLS client certificates can be generated for a role, which services and applications can then use when sending KMIP requests against Vault's KMIP secret engine. In order to generate client certificates for KMIP clients to interact with Vault's KMIP server, we must first create a scope and role and specify the desired set of allowed operations for it.

The Vault web (UI) can be used to generate KMIP client certificates (credentials), or by invoking the KMIP API:

Outcome

Simply disabling and re-enabling the KMIP secrets engine would result in the loss of any existing KMIP key,
which is why the approach to extend the validity for the certificate authority and the intermediate certificate authority to change the tls_ca_key_type was used instead.

Additional Information

Articles in this section

See more