Certificates/Become your own CA

From Gentoo Wiki
Jump to:navigation Jump to:search
This article is a stub. Please help out by expanding it - how to get started.
Note
Various other pages refer to local setup with a local CA or self signed certificates. This subpage will illustrate how to setup a root CA with an intermediate CA. At least Centralized authentication using OpenLDAP make most sense for small networks run isolated/ at lowest cost. To not repeat the TLS setup in every article link here instead – when ready.
Warning
If you roll your own chain of trust and expose root and/ or intermediate CA's key material all trust is gone. Only apply changes to an important system if you follow the recommendations. Weaken any of the links in the chain undermines the security of all systems part of the chain. Effort is necessary to keep the key material safe and secret.

Applies to:

  • small local networks running a critical number of TLS-secured services (HTTP server, message broker, LDAP)
  • mutual TLS for authentication in a local network, esp. hosts that don't have any user input options

What has to be done

  1. Init a safe storage for key material
  2. Write a configuration file (for OpenSSL) to limit the interaction for repeated tasks
  3. create key material for a root CA with certificate on the safe storage
  4. create key material and certificate for an intermediate CA on a safe machine and sign it with the root CA's certificate
  5. issue a first CSR for a server certificate to be used with Apache/ Inspircd, OpenLDAP or others
  6. sign the first CSR as intermediate CA
  7. issue a second CSR for a client certificate to be used for example with Apache mutual TLS
  8. sign the second CSR as intermediate CA

See Local certificates for an explanation how to publish the root CA's certificate to various hosts and truststores.

Necessary Material:

  1. A safe storage for root CA key material (2 thumb drives plus either a hard disk or better a tape drive)
  2. A safe host to start the root CA and run the intermediate CA
  3. An offline password manager or strategy to store strong passwords safely and for a long time

Root CA

Warning
A root certificate authority can be used to sign any domain. It is technically absolutely correct that a root CA signs an online banking domain, web shops, mail servers and everything with a domain. If you create a root CA and publish it to other hosts a malicious attack can trick all these systems when he gained access to your key material or controls your signing process. Also validating the chain of trust does not help. The malicious attacker plays man in the middle with a hijacked chain of trust through a compromised root CA certificate or derived server certificates.

Safe storage

A safe storage means – 3-2-1 rule – 3 copies, 2 technologies/ media, 1 off site. The root CA will be valid more than 20 years and with the certificate spreading out onto hosts and services it is not easy to update all. Encrypt all media. Wath their lifetime, wear and health metrics. Even a thumb drive needs to be attached from time to time to a USB port so that the firmware can move blocks around. For example use two thumb drives and a hard disk. Even better would be a tape drive allowing longterm storage.

Prepare a first medium of the safe storage for example a thumb drive on the physical layer by encrypting it entirely or creating partitions or even volume groups. Later mirror that first medium to two other copies with different security properties like passwords. See for example Dm-crypt full disk encryption .

Now that the safe storage is unlocked and mounted to a safe system it is necessary to initiate it once with some directories and flat file databases. Also permissions need to be granted with safety in mind. Change to the root directory of the safe storage. All commands will be run relative to this root directory:

user $mkdir certs crl newcerts private
user $chmod 700 private
user $touch index.txt
user $echo 1000 > serial

OpenSSL configuration file

The following configuration file example is used throughout the process. This limits interaction with commands and lowers the chance of errors when signing CSRs or issuing more certificates. Some sections reference each other. Consult the man page of openssl for details beyond the comments. Treat all properties with caution lookup more recent recommendations because safe algorithms when this was written might be weak when applying these steps.

FILE openssl.cnf
[ca]
default_ca = CA_default

[CA_default]
# Directory and file locations. CRL is certificate revocation list
dir               = .
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The root key and root certificate.
private_key       = $dir/private/root-ca.key.pem
certificate       = $dir/certs/root-ca.cert.pem

# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 375
preserve          = no
policy            = policy_strict

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[v3_ca]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

Key material and certificate

Use a strong password. If you prefer elliptic curve keys see openssl man pages for correct syntax. First a key pair is created:

user $openssl genrsa -aes256 -out private/root-ca.key.pem 4096
enter passphrase: ***
verify passphares: ***

And secured against overwriting:

user $chmod 400 private/root-ca.key.pem

Based on the key material a certificate has to be created. Mind that req either requires -config or falls back to a default configuration in /etc:

user $openssl req -config openssl.cnf \ 
     -key private/root-ca.key.pem \
     -new -x509 -days 7300 -sha256 -extensions v3_ca \
     -out certs/ca.cert.pem

Intermediate CA

CSR for server certificate

CSR for client certificate

See also

Now forward links, later backward/ symmetric

Retrieved from "https://wiki.gentoo.org/index.php?title=Certificates/Become_your_own_CA&oldid=1061843"