corrections, edits, and additions

This commit is contained in:
2026-04-10 03:28:56 +00:00
parent 69eede65d8
commit 8a3e979f94
3 changed files with 96 additions and 34 deletions

View File

@@ -1,8 +1,9 @@
# Signing certificates for users and servers
# Signing certificates for users, services, and hosts
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***.
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
@@ -10,52 +11,102 @@ 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 `server_cert` extension.
### 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 server_cert -days 375 -notext -md sha256 -in csr/server.csr -out certs/server.crt
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
```
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), editing the -subj and [SAN] sections as necessary
### 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.
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 ' '***
**Peers**
Edit the *-subj* and *[SAN]* sections as necessary
```
openssl req -new -sha256 \
-key domain.key \
-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 domain.csr # provide this to the CA for signing
-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
```
openssl ca -config intermediate.cnf -extensions server_cert -days <#-of-days> -notext -md sha256 -in csr/server.csr -out certs/server.crt
### 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
```
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
**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/server-or-user.tar.gz certs/server-or-user certs/ca-bundle.crt (private/server-or-user.key added if key was created by the CA).
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).
```

View File

@@ -90,35 +90,31 @@ authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ usr_cert ]
[ peer_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
[ client_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
[ identity_cert ]
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection
copy_extensions = copy
[ server_cert ]
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
copy_extensions = copy # using this to copy alternative names
[ crl_ext ]
authorityKeyIdentifier=keyid:always
[ ocsp ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer

View File

@@ -7,39 +7,53 @@ Now that there's a Root CA established, one or more Intermediate CA can be creat
Copy the [root.cnf](./root.cnf) to the Intermediate CA and change the name to *intermediate.cnf* (or whatever name desired to distinguish it from the root CA) on the Intermediate CA and change the policy section under the [CA_default] from `policy_strict` to `policy_loose` since the Intermediate CA isn't signing certificates for other CAs, it can have a less strict policy.
### Create the Intermediate CA key (on Root CA)
```
openssl genrsa -aes256 -out private/intermediate-ca.key
chmod 400 private/intermediate-ca.key
```
### Create the certificate signing request (CSR) for the Intermediate CA using the intermediate.cnf configuration (on the Root CA)
```
openssl req -config intermediate.cnf -new -sha256 -key private/intermediate-ca.key -out csr/intermediate-ca.csr
```
### Sign the certificate using the root.cnf using the `v3_intermediate_ca` extension the paths are defined in the root.cnf so do not need to be explicitly defined in the command (on the Root CA)
```
openssl ca -config root.cnf -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in csr/intermediate-ca.csr -out certs/intermidate-ca.crt
chmod 444 certs/intermediate-ca.crt
```
### Verify the certificate information and verify the trust chain (on the Root CA)
```
openssl x509 -noout -text -in certs/intermediate-ca.crt
openssl verify -CAfile certs/root-ca.crt certs/intermediate-ca.crt # should return certs/intermediate-ca.crt: OK
```
### Create the ca-bundle.crt (on the Root CA)
```
cat certs/root-ca.crt certs/intermediate-ca.crt > certs/ca-bundle.crt
cat certs/intermediate-ca.crt certs/root-ca.crt > certs/ca-bundle.crt
```
Verify the chain order (the root CA should be last in the chain)
```
openssl crl2pkcs7 -nocrl -certfile ca-bundle.crt | openssl pkcs7 -print_certs -text -noout
```
### Create an archive of the ca-bundle.crt intermediate-ca.crt, and intermediate-ca.crt transport to the Intermediate CA using your preferred transport method
```
tar cvzf intermediate-ca.tar.gz certs/ca-bundle.crt certs/intermediate-ca.crt private/intermediate-ca.key
```
### Create dirs, serial, and index for Intermediate CA on Intermediate CA (same dirs as the root but with a bundles dir)
```
mkdir -p /path/to/intermediate_ca/{bundles,certs,csr,crl,newcerts,private}
cd /path/to/intermediate_ca
@@ -47,6 +61,7 @@ chmod 700 private
```
### Create a CRL number on Intermediate CA (creating this for later use)
```
echo 1000 > /path/to/intermediate_ca/crlnumber
```