The steps to create key, certificate signing request (CSR), and certificate outlined here assume they're created on the CA and distributed from the CA. If a CSR is provided, skip to the `Verify the CSR` section.
### Sign the certificate using the proper extension for the CSR to be signed, using the intermediate.cnf configuration. The example below uses the `service_cert` extension.
### Generating the CSR with SAN(s), editing the -subj and [SAN] sections as necessary
Generally, the CSR is provided to the CA for signing, in order for the private key that generates the CSR to remain secure. The following are choices to generate the desired CSR type:
***Note: If using sudo su -c, the subsequent command may need to be wrapped ' '***
***Note: For most peers, it's usually best practice to have the peer system IP AND FQDN along with the loadbalancer IP and FQDN (Kubernetes control plane nodes for example)***
### Sign the certificate based on the certificate type
Sign the certificate using one of the following commands. Once the password has been provided, the certificate will be printed to *stdout* to be verified one more time before signing and subsequently added to the index.
The `verify` command should return OK, verifying the trust chain.
### Create the certificate archive bundle and transfer to the server/user if the CSR is is provided, a key will not be bundled, as it will reside with the server or the user. Use the desired transfer method to move the TLS bundle to the desired location
tar cvzf bundles/<name_of_cert_archive>.tar.gz certs/server-or-user certs/ca_bundle.crt (private/server-or-user.key added if key was created by the CA).