Signing certificates for users, services, and hosts

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.

Generate the key (the -aes256 can be omitted to not require a password)

cd intermediate_ca
openssl genrsa -out private/server.key 2048
chmod 400 private/server.key

Generate the CSR

openssl req -config intermediate.cnf -key private/server.crt -new -sha256 -out csr/server.csr

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.

openssl ca -config intermediate.cnf -extensions service_cert -days 375 -notext -md sha256 -in csr/server.csr -out certs/server.crt
chmod 444 certs/server.crt

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 with ' '

Peers

openssl req -new -sha256 \
    -key peer.key \
    -subj "/C=2LetterCountry/ST=YourStateorProvince/L=YourCityOrLocality/O=YourOrg/OU=YourOU/CN=example.com" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
    <(printf "\n[SAN]\nsubjectAltName=DNS:peer,DNS:peer.example.com,DNS:peer-lb.example.com,IP:192.168.1.1")) \
    -out peer.csr

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)

Services

openssl req -new -sha256 \
    -key client.key \
    -subj "/C=2LetterCountry/ST=YourStateorProvince/L=YourCityOrLocality/O=YourOrg/OU=YourOU/CN=example.com" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
    <(printf "\n[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com,IP:192.168.1.1")) \
    -out client.csr

Identities (humans)

openssl req -new -sha256 \
    -key user.key \
    -subj "/C=2LetterCountry/ST=YourStateorProvince/L=YourCityOrLocality/O=YourOrg/OU=YourOU/CN=username" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
    <(printf "\n[SAN]\nsubjectAltName=email:user@example.com,DNS:endpoint.example.com")) \
    -out user.csr

Verify the CSR

Verify the CSR is valid and contains the necessary data

openssl req -in csr/server.csr -noout -text

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.

Peers

openssl ca -config intermediate.cnf -extensions peer_cert -days 400 -notext -md sha256 -in csr/peer.csr -out certs/peer.crt

Services/clients

openssl ca -config intermediate.cnf -extensions client_cert -days 400 -notext -md sha256 -in csr/client.csr -out certs/client.crt

**Identities (humans)

openssl ca -config intermediate.cnf -extensions identity_cert -days 400 -notext -md sha256 -in csr/identity.csr -out certs/identity.crt

Verify the certificate and trust chain

openssl verify -CAfile certs/ca-bundle.crt certs/server.crt

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).

3.9 KiB Raw Blame History