Certificate Signing Requests (CSR) can for servers/user can be provided by the system owners or the users. This retains the privacy of the private key. The steps to create key, CSR, and certificate on the CA will be outlined here. If a CSR is provided, skip to the `Verify the CSR` section. ***IT IS IMPORTANT TO INSPECT CSRs PROVIDED EXTERNALLY BEFORE SIGNING EVEN THOUGH THE CERTIFICATE CAN BE INSPECTED BEFORE SIGNING***.
### Sign the certificate using the proper extension for the CSR to be signed, using the intermediate.cnf configuration. The example below uses the `server_cert` extension.
Alternatively, and recommended, certificate can be created with one or more, usually more, Subject Alternative Names (SAN) as other means of identifying a server. This useful when you want to refer to a server by different names, such as its hostname and FQDN and IP address or the server is part of a load balanced cluster so there is a need to refer to the load balancer IP or FQDN
### Generating the CSR with SAN(s) depending on the where the csr is being created, sudo su -c with the command in ' ' may be required.
Edit the *-subj* and *[SAN]* sections as necessary
The certificate to be signed will be sent to stdout after providing the password, which can be inspected to ensure it is correct. Select y to sign it and y again to add to the index database
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