Offload randomly generated PKCS #12 passphrases to Vault

this section covers two examples that invoke futurex apis to request an x 509 certificate and associated key pair that is issued as a pkcs #12 file then, the kmes series 3 automatically offloads the passphrase generated for decrypting the pkcs #12 file to vault the first example runs the raup excrypt command while connected to the system/host api port on the kmes by using openssl the second example sends a post request to the kmes restful api by using the postman application perform prerequisite setup on the kmes series 3 before attempting either of the examples, you must perform setup steps on the kmes series 3 see the kmes series 3 user guide for additional information about completing the following required setup steps go to identity management > roles and select \[ add ] create a signing approval role, set logins required to 1 , and enable all permissions under certificate authority , keys , and cryptographic operations select \[ ok ] to finish creating the role go to identity management > identities and select \[ add ] under assigned roles , select the signing approval role you just created under authentication , set a password for the identity select \[ ok ] to finish creating the identity go to pki > signing workflow and select \[ add ] set a name for the signing approval group and select \[ ok ] create a ca tree, ensuring that you select the pmk as the major key for all certificates created in this ca tree add an issuance policy to the leaf certificate in the ca tree in the x 509 tab of the issuance policy window, ensure that you select all of the permission checkboxes and that you select the signing approval group you created in step 5 give the created signing approval role the use permissions on all of the following the signing approval group created in step 5 the entire ca tree created in step 6 the cloud credential that is being used in the vault api options menu example raup excrypt command ensure that the raup command is enabled in the host api options menu run the following command to connect to the system/host api port on the kmes by using slope openssl s client connect 10 0 8 28 2001 cert signed client cert pem key private key pem capath cafile chain pem you must configure the system/host api connection pair on the kmes series 3 so that this openssl connection works instructions for setting this up are outside the scope of this guide see the kmes series 3 user guide for more information after you connect successfully, run the rklo excrypt command twice to log in with the default admin users, as shown in the following example \[aorklo;daadmin1;chsafest;] \[aorklo;any;ul1;ut2;rl1;] \[aorklo;daadmin2;chsafest;] \[aorklo;any;ul2;ut2;rl0;] run the raup command to upload a new x 509 pki request, as shown in the following example \[aoraup;cademo ca;rtdemo sub cert;natestupload;hasha256;gndemo approval group;enexample tls certificate;sn{2 5 4 3,12,436f6d6d6f6e4e616d6548657265},{1 3 3 7,19,30313233};ktrsa 2048;mp1;] \[aoraup;any;ap1;id34e2cce30bc2f336;pw567e463b516f3120246c265446366a585d63636a794342215f344b7d43266f765d454c3b5741307068614f657a487a2234692e51754b5c46342477282856253c;] if the command succeeds, as shown in the preceding example, a new x 509 pki, issued as a pkcs #12 file, generates on the kmes series 3, and the passphrase for the pkcs #12 file is stored in vault log in to the vault ui and navigate into the secret/ folder select the created secret you can see the key is passphrase , and the value is the passphrase for the pkcs #12 file you generated on the kmes series 3 example post request to the kmes restful api by using postman before trying this example, you must perform an additional configuration on the kmes series 3 configure a jwt identity provider and authentication mechanism go to identity management > identity providers right click and select add > provider > json web token on the info tab, specify a name for the provider on the jwt options tab, set the issuer as futurex on the jwt key tab, select hmac key and enter safest123 select \[ ok ] when finished right click the identity provider you just created and select add > mechanism > json web token on the info tab, specify a name for the mechanism, then select \[ ok ] to save go to identity management > identities and locate the signing approval identity created for the previous example right click it and select edit navigate to the authentication tab and select \[ add ] in the type drop down menu, select json web token and select \[ ok ] to return to the identity editor then select \[ ok ] to save go to identity management > identity providers right click the identity provider you created and select permission give your signing approval role use permissions and select \[ ok ] send a post request to the kmes restful api by using postman to perform the following steps, you must install the postman application on your local computer the same concepts apply if you use curl rather than postman however, to use curl, you must generate the jwt token elsewhere (for example, a website such as https //jwt io/ ) with postman, you can generate a jwt token on the fly when you send the post request start the postman application, and select \[ new ] on the top left side of the page select collection set any name for the collection, go to the variable tab, and set jwt token in the variable field select \[ create ] you don't need to set anything else in this window right click the three dots in the new collection and select \[ add request ] set any name for the request the most important part is that the request is associated with the newly created collection save the request expand the collection folder and select the request that you just created set the request url to https //10 0 5 125 8081/kmes/v6/certificates/signing requests and change the request type to post in the drop down menu go to the authorization tab, set the type to bearer token , and set the token value to {{jwt token}} go to the body tab, select the raw bullet, and paste the following json code { "pkitree" "demo ca", "signingcert" "demo sub cert", "requestname" "test request", "requesttype" "pki", "hashtype" "sha 256", "approvalgroup" "demo approval group", "pkioptions" { "extensionprofile" "tls certificate", "keytype" "rsa 2048", "randompassphrase" true, "subject" \[ { "id" "2 5 4 3", "asn1type" 12, "data" "436f6d6d6f6e4e616d6548657265" } ], "certexpiration" "2024 11 1 00 00 00" } } in the request body, you specify that you want the kmes series 3 to create a new x 509 pki you define the ca tree that you built on the kmes, along with several other parameters one of the most important parameters to notice is the randompassphrase value set to true the randompassphrase parameter ensures that the pki request is issued as pkcs #12 then, the passphrase for the pkcs #12 file is stored in vault go to the pre request script tab and paste the following javascript let hmac key = "safest123"; let header = { "alg" "hs256", "typ" "jwt" }; let payload = { "iss" pm globals get('jwt issuer'), "sub" pm globals get("jwt user"), "iat" math floor(date now() / 1000) }; function base64url(source) { encodedsource = cryptojs enc base64 stringify(source) replace (/=+$/, '') replace(/\\+/g, ' ') replace(/\\//g, ' '); return encodedsource; } let b64 header = base64url(cryptojs enc utf8 parse(json stringify (header))); let b64 data = base64url(cryptojs enc utf8 parse(json stringify (payload))); let message = b64 header + " " + b64 data; let b64 signature = base64url(cryptojs hmacsha256(message, hmac key)); jwt token = \[b64 header, b64 data, b64 signature] join(' '); pm collectionvariables set("jwt token", jwt token); the preceding code generates the jwt token used for authentication to the kmes, on the fly after pasting in the javascript, select the settings icon in the upper right corner of the page and select globals add a new variable, jwt issuer, and enter futurex for both the initial value and current value add a new variable, jwt user set the current value to the username of the signing approval identity you created select \[ save ] select \[ save ] on your request and select \[ send ] if the request is successful, the response body contains the message successfully created new entry if you log back into the vault ui and go to secret engines > secret , you see a new entry with id values after commonname that matches the requested value in the response body in postman this confirms that the kmes series 3 sent the pkcs #12 passphrase successfully to vault for storage enable the rekey feature you can apply a renewal threshold in registration authority options when you request an existing key name, one of the following events occurs if the key is under the expiration threshold when you request the key, the system returns a new key and certificate if the key is over the expiration threshold when you request the key, the system returns the same key and certificate to apply the renewal threshold, perform the following steps go to administration > configuration > registration authority options in registration authority options , locate renewal threshold for the renewal threshold option, set a number and use the drop down list to select days, weeks, months, or years depending on your needs (for example, 90 days) in this example, a key request with the same name that is over the 90 day threshold returns the same key and certificate a key request with the same name that is under the 90 day threshold returns a new key and certificate select \[ save ] to finish applying your changes to use the rekey feature, add the renewalcheck true line to the json request, as shown in the following example post renewal check https //{{url}}/{{v6}}/certificates/signing requests { "pkitree" "registration authority", "signingcert" "rasigner", "requestname" "renew1", "requesttype" "pki", "hashtype" "sha 256", "approvalgroup" "ra group", "renewalcheck" true, "pkioptions" { "extensionprofile" "example tls client certificate", "keytype" "rsa 2048", "randompassphrase" true, "exportpkcs12" true, "subject" \[ { "id" "2 5 4 3", "asn1type" 12, "data" "72656e657731" } ], "certexpiration" "2030 01 01 00 00 00" } }