From 5c05a8f8e12291824c689d574289a29fdb2456a6 Mon Sep 17 00:00:00 2001 From: "E. Luke Walker" Date: Mon, 30 Oct 2023 12:37:32 -0700 Subject: [PATCH] Delete content/PIV/Guides/Certificate_authority.adoc --- content/PIV/Guides/Certificate_authority.adoc | 194 ------------------ 1 file changed, 194 deletions(-) delete mode 100644 content/PIV/Guides/Certificate_authority.adoc diff --git a/content/PIV/Guides/Certificate_authority.adoc b/content/PIV/Guides/Certificate_authority.adoc deleted file mode 100644 index 39a00b631..000000000 --- a/content/PIV/Guides/Certificate_authority.adoc +++ /dev/null @@ -1,194 +0,0 @@ -== Certificate Authority with a YubiKey -This document explains how to set up a Certificate Authority (CA) with -Sub-CA private keys stored on YubiKeys. Typical use for this is -to generate HTTPS certificates for internal servers. - -=== Considerations -For our example, we have chosen to use one root CA with a private key -stored in an offline machine, that signs sub-CAs with private keys -stored on YubiKeys, which signs end-entity (EE) certs. We'll -generate the Sub-CA private keys on an offline host and save a copy of -those keys. - -We have chosen to use a RSA 3744 bit root CA key, and RSA 2048 bit -keys for the Sub-CAs and EE certificates. The YubiKey is limited to -RSA 1k and 2k keys (it supports ECDSA too but we chose to not use that -here). - -By setting some name constraints, we are trying to limit to powers of -this CA. This is not fully supported by all environments, but it -should do no harm, and may be useful in some environments. - -The root also has a path length constraint of 1 to prevent the Sub-CAs -from issuing further Sub-Sub-CAs. - -We also set a expiry date far away in the future on the root CA -(expiring in 1000000 days) and use datefudge to set an arbitrary start -date for the CA, to avoid leaking the time of CA creation which would -leak some bits of information going into the randomness generation. - -=== Preparations -We use OpenSSL to generate keys and certificates. This is done on an -offline machine, booted from a LiveCD. Some additional packages may -be required (pcscd, etc, see below) and will have to be transferred on -a USB stick. - -You need a YubiKey with the PIV application on, which you can purchase -from Yubico. - -You need to install the PKCS#11 Engine: - - # dpkg -i libengine-pkcs11-openssl* - -or if you are on a connected machine, more simpler: - - # apt-get install libengine-pkcs11-openssl - -=== Creating a Root CA -Generate the private key as follows: - - $ openssl genrsa -out yubico-internal-https-ca-key.pem 3744 - -Generate the Root CA certificate and initialize the CA serial number -counter as follows: - - $ cat>yubico-internal-https-ca.conf< yubico-internal-https-ca-crt.srl - -You may inspect the newly generated root CA with: - - $ openssl x509 -text < yubico-internal-https-ca-crt.pem - -=== Preparing a Sub-CA -We need to change the management key, PIN and PUK code following the -YubiKey-PIV-Introduction.txt document. We also want to save a -copy of these values. Here are the steps that are needed to be done -for each new Sub-CA. - -This step is parametrized with the name of the YubiKey user. -Generate new management code, PIN and PUK as follows: - - $ user=Simon - $ key=$(export LC_CTYPE=C; dd if=/dev/urandom 2>/dev/null | tr -d '[:lower:]' | tr -cd '[:xdigit:]' | fold -w48 | head -1) - $ echo $key > yubico-internal-https-$user-key.txt - $ pin=$(export LC_CTYPE=C; dd if=/dev/urandom 2>/dev/null | tr -cd '[:digit:]' | fold -w6 | head -1) - $ echo $pin > yubico-internal-https-$user-pin.txt - $ puk=$(export LC_CTYPE=C; dd if=/dev/urandom 2>/dev/null | tr -cd '[:digit:]' | fold -w8 | head -1) - $ echo $puk > yubico-internal-https-$user-puk.txt - -Configure a fresh YubiKey with these parameters as follows: - - $ yubico-piv-tool -a set-mgm-key -n $key - $ yubico-piv-tool -k $key -a change-pin -P 123456 -N $pin - $ yubico-piv-tool -k $key -a change-puk -P 12345678 -N $puk - -=== Creating a Sub-CA -This step is parametrized with the name of the YubiKey user. This -means we will have one Sub-CA for every person authorized to sign -certificates in our CA. - - $ user=Simon - -We first need to load the management key and PIN code from the -previous section. - - $ key=`cat yubico-internal-https-$user-key.txt` - $ pin=`cat yubico-internal-https-$user-pin.txt` - -Generate the private key: - - $ openssl genrsa -out yubico-internal-https-subca-$user-key.pem 2048 - -Generate the Sub-CA certificate request: - - $ cat>yubico-internal-https-subca-$user-csr.conf<yubico-internal-https-subca-$user-crt.conf< yubico-internal-https-subca-$user-crt.srl - -You may inspect the newly generated EE cert with this command: - - $ openssl x509 -text < yubico-internal-https-subca-$user-crt.pem - -Import Sub-CA key to the YubiKey: - - $ yubico-piv-tool -k $key -a import-key -s 9c < yubico-internal-https-subca-$user-key.pem - -Import Sub-CA cert to the YubiKey: - - $ yubico-piv-tool -k $key -a import-certificate -s 9c < yubico-internal-https-subca-$user-crt.pem - -=== Creating End-Entity Certificates -This step is parametrized with the hostname, and the name of the -Sub-CA used to sign the EE, so set it first: - - $ host=munin - $ user=Simon - -We first need to load the PIN code from the previous section. - - $ pin=`cat yubico-internal-https-$user-pin.txt` - -Then generate a new private key and certificate request: - - $ openssl genrsa -out yubico-internal-https-ee-$host-key.pem 2048 - $ cat>yubico-internal-https-ee-$host-csr.conf<yubico-internal-https-ee-$host-crt.conf<