root-ca
Wednesday 2 April 2025 37 versions

Definitionen

Eine “Public Key Infrastructure” (PKI) ist ein System aus vertrauenswürdigen Zertifizierungsstellen (CAs), die eine hierarchische Vertrauenskette (Chain-of-Trust) bilden, um einem Endgerät und einem Netzwerkserver eine abgesicherte Kommunikation via “Transport Layer Security” (TLS) zu ermöglichen.

TLS (früher SSL) ist die Basis für das HTTPS-Protokoll. Es werden X.509 Zertifikate benutzt, um das Vertrauen zwischen den Kommunikationspartnern herzustellen und danach einen Session-Schlüssel auszutauschen und zu benutzen.

X.509-v3 ist ein ITU-Standard, der das Format von “Public Key Certificates” definiert.
Ein X.509 Zertifikat verknüpft eine Identität mit einem Public Key mittels einer Digital Signature.

X.509 Zertifikate existieren in Base64 Formaten PEM (.pem, .crt, .ca-bundle), PKCS-7 (.p7b, .p7s) und binären Formaten DER (.der, .cer), PKCS-12 (.pfx, .p12).

Die technische Basis für die Erstellung der Public Keys, Private Keys und Digital Signatures ist die asymmetrische Verschlüsselungstechnik. Entweder unter Nutzung des RSA-Algorithmus oder auf Basis von ECC (Elliptic Curve Cryptography). Übersichten über beide Verfahren können hier oder hier eingesehen werden.

Im Blog von Bityard gibt’s eine gute Zusammenfassung und Übersicht zum Thema.

Anleitung von SUSE

  • Internet-Ressourcen: Link zum Artikel und Glossar der Fachbegriffe.
    • PDF-Datei zum Herunterladen.
    • Als Tool wird openssl benutzt.
  • Erzeugen von Client Keys, Certificate Signing Requests (CSR) und einer privaten CA.
  • Erzeugen von Zertifikaten und Installation von “Certificate Chains” im Linux Trust Store.

Methoden zum Aufbau einer eigenen Certificate Authority und Self-Signed Certificates

A certificate contains an identity (hostname, organization, etc.) and a public key (RSA, DSA, ECDSA, ed25519, etc.), and is either signed by a Certificate Authority or is Self-Signed.

Werkzeuge für die Kommandozeile

DER Klassiker: openssl

Oft benutzt. Hat ’tausende’ Optionen. –> Kompliziert und unübersichtlich!

Generate CA

  1. Generate RSA key
1openssl genrsa -aes256 -out ca-key.pem 4096
  1. Generate a public CA Cert
1openssl req -new -x509 -sha256 -days 365 -key ca-key.pem -out ca.pem

View Certificate’s content 

1openssl x509 -in ca.pem -text
2openssl x509 -in ca.pem -purpose -noout -text

Generate Certificate

  1. Create an RSA key
1openssl genrsa -out cert-key.pem 4096
  1. Create a Certificate Signing Request (CSR): specify the identity as subject or common name.
1openssl req -new -sha256 -subj "/CN=yourcn" -key cert-key.pem -out cert.csr
  1. Create an extfile with all the SANs (subject alternative names)
1echo "subjectAltName=DNS:your-dns.record,IP:257.10.10.1" >> extfile.cnf
2# optional
3echo "extendedKeyUsage = serverAuth" >> extfile.cnf
  1. Let the CA create the signed certificate
1openssl x509 -req -sha256 -days 365 -in cert.csr -CA ca.pem -CAkey ca-key.pem \
2  -out cert.pem -extfile extfile.cnf -CAcreateserial

Convert Certificates

COMMAND CONVERSION
openssl x509 -outform der -in cert.pem -out cert.der PEM to DER
openssl x509 -inform der -in cert.der -out cert.pem DER to PEM
openssl pkcs12 -in cert.pfx -out cert.pem -nodes PFX to PEM

Verify Certificates 

1openssl verify -CAfile ca.pem -verbose cert.pem

Alternatives PKI-Tool von OpenVPN: easy-rsa

Easy-rsa ist ein Shell-Skript und Frontend für openssl.

  • Tool und Quellcode können von Github heruntergeladen werden.
  • Da ich keine Erfahrung damit habe, wird deshalb hier nur die Existenz erwähnt.

cfssl von Cloudflare macht’s einfacher

Cfssl ist ein Tool von Cloudflare aus dem Jahr 2014, welches ohne die Verwendung von openssl auskommt.

  • Syntax und Kommando-Optionen sind einfacher zu verstehen.
  • Tool und Quellcode können von Github heruntergeladen werden.
  • Ergänzende Blog-Artikel aus 2015 und 2016 erläutern weitere Details des Toolsets.

Da die offizielle Dokumentation von cfssl etwas dürftig ist, sind diese privaten Blog-Artikel sehr hilfreich!

Aus diesen Gründen ist cfssl das (bis jetzt) von mir bevorzugte Tool zum Arbeiten mit X.509-Zertifikaten. Diese Position könnte ihm aber von der Neuentdeckung Smallstep streitig gemacht werden.

Private-Key und CSR Dateien für einen Webservice erstellen

  1. Spezifikation für den CSR als JSON-Datei erstellen. Dabei gleich alle SANs (“Subject Alternate Names”) in den Abschnitt “hosts” einfügen. Das können sowohl DNS-Namen (FQDN) als auch IP-Adressen sein.
 1{
 2  "CN": "my-service.fqdn.tld",
 3  "key": {
 4    "algo": "ecdsa",
 5    "size": 256
 6  },
 7  "names": [
 8    {
 9      "C": "DE",
10      "ST": "RLP",
11      "L": "Ludwigshafen",
12      "O": "AG MicroComputer",
13      "OU": "Pagong"
14    }
15  ],
16  "hosts": [
17    "my-service.fqdn.tld",
18    "10.12.13.14"
19  ]
20}
  1. Public und Private KEY für den CSR erstellen und von JSON- in’s PEM-Format wandeln.
 1$ cfssl genkey my-service-csr.json | cfssljson -bare my-service
 22025/03/21 15:14:28 [INFO] generate received request
 32025/03/21 15:14:28 [INFO] received CSR
 42025/03/21 15:14:28 [INFO] generating key: rsa-2048
 52025/03/21 15:14:28 [INFO] encoded CSR
 6
 7$ ls -l
 8-rw-r--r-- 1 pagong users 1155 Mar 21 15:14 my-service.csr
 9-rw-r--r-- 1 pagong users  322 Mar 21 15:08 my-service-csr.json
10-rw------- 1 pagong users 1679 Mar 21 15:14 my-service-key.pem
11
12$ cfssl certinfo -csr my-service.csr
  1. CSR Datei von (irgend)einer CA unterschreiben lassen. Damit erhält man die signierte CRT Datei.
  • z.B. von openssl oder step-ca oder OPNsense
  • oder auch von cfssl: siehe nächster Abschnitt
  1. Fertiges Zertifikat (CRT-Datei) anzeigen.
1$ cp my-service.pem my-service.crt
2$ cfssl certinfo -cert my-service.crt

Signieren eines CSR von einer CA = Ausstellen eines Zertifikats (CRT) für einen Webservice

  1. Lokales Signieren
1$ cfssl gencert -ca my-ca.pem -ca-key my-ca-key.pem my-service-csr.json |
2    cfssljson -bare my-service
  1. Remote Signieren
1$ cfssl gencert -remote=remote_server my-service.csr.json |
2    cfssljson -bare my-service
  1. Fertiges Zertifikat (CRT-Datei) anzeigen.
1$ ls my-service*
2my-service.csr
3my-service-csr.json
4my-service-key.pem
5my-service.pem
6
7$ cp my-service.pem my-service.crt
8$ cfssl certinfo -cert my-service.crt
  1. Beim cfssl sign Vorgang kann auch noch eine JSON-Konfigurationsdatei cfssl-cfg.json mit Profile-Definitionen genutzt werden, um das “Finetuning” des Verwendungszwecks (oder anderer Parameter) des Zertifkats anzupassen.
1$ cfssl sign -config cfssl-cfg.json -profile profile_name \
2  -ca ca.pem -ca-key ca-key.pem my-service.csr |
3    cfssljson -bare my-service

Eigene Root-CA erstellen

Dieses Beispiel wurde von Rob Blackbourn übernommen.

  1. Spezifikation für die CA als JSON-Datei erstellen.
 1{
 2  "CN": "Custom Widgets Root CA",
 3  "key": {
 4    "algo": "rsa",
 5    "size": 4096
 6  },
 7  "names": [
 8  {
 9    "C": "GB",
10    "L": "London",
11    "O": "Custom Widgets",
12    "OU": "Custom Widgets Root CA",
13    "ST": "England"
14  }
15 ]
16}
  1. Public und Private KEY für die CA erstellen. Die Root-CA ist daran erkennbar, dass sie selbst signiert ist.
    (Also Issuer = Owner bzw. Subject).
1$ cfssl genkey -initca root-ca-csr.json |
2    cfssljson -bare root-ca
3
4$ ls root-ca*
5root-ca.csr
6root-ca-csr.json
7root-ca-key.pem
8root-ca.pem
  1. PEM- in CRT-Datei kopieren und Zertifikat anzeigen.
1$ cp root-ca.pem root-ca.crt
2$ cfssl certinfo -cert root-ca.crt

Eigene (intermediate) Branch-CA erstellen

Dieses Beispiel wurde ebenfalls von Rob Blackbourn übernommen.

  1. Spezifikation für den CSR der Branch-CA als JSON-Datei erstellen.
 1{
 2  "CN": "Custom Widgets Branch CA",
 3  "key": {
 4    "algo": "rsa",
 5    "size": 2048
 6  },
 7  "names": [
 8    {
 9      "C":  "GB",
10      "L":  "London",
11      "O":  "Custom Widgets",
12      "OU": "Custom Widgets Branch CA",
13      "ST": "England"
14    }
15  ],
16  "ca": {
17    "expiry": "42720h"
18  }
19}
  1. Public und Private KEY für den CSR der Branch-CA erstellen. Dabei entsteht auch eine nicht benötigte PEM-Datei.
1$ cfssl gencert -initca branch-ca-csr.json |
2    cfssljson -bare branch-ca
  1. Und den CSR gleich von der Root-CA signieren lassen. Dabei wird die ‘unnötige’ durch die ‘richtige’ PEM-Datei ersetzt.
1$ cfssl sign -config cfssl-cfg.json -profile branch_ca \
2  -ca root-ca.pem -ca-key root-ca-key.pem branch-ca.csr |
3    cfssljson -bare branch-ca
4  
5$ ls branch-ca*
6branch-ca.csr
7branch-ca-csr.json
8branch-ca-key.pem
9branch-ca.pem
  1. PEM- in CRT-Datei kopieren und Zertifikat anzeigen.
1$ cp branch-ca.pem branch-ca.crt
2$ cfssl certinfo -cert branch-ca.crt

Eigene Leaf-CA erstellen

Dies erfolgt ähnlich zum Vorgang der Signierung der Branch-CA durch die Root-CA. Nur wird in diesem Fall die Leaf-CA durch die Branch-CA signiert.

  1. Spezifikation für den CSR der Leaf-CA als JSON-Datei erstellen.
 1{
 2  "CN": "Custom Widgets Leaf CA",
 3  "key": {
 4    "algo": "ecdsa",
 5    "size": 384
 6  },
 7  "names": [
 8    {
 9      "C":  "GB",
10      "L":  "London",
11      "O":  "Custom Widgets",
12      "OU": "Custom Widgets Leaf CA",
13      "ST": "England"
14    }
15  ],
16  "ca": {
17    "expiry": "8760h"
18  }
19}
  1. Public und Private KEY für den CSR der Leaf-CA erstellen. Dabei entsteht auch eine nicht benötigte PEM-Datei.
1$ cfssl gencert -initca leaf-ca-csr.json |
2    cfssljson -bare leaf-ca
  1. Und den CSR gleich von der Branch-CA signieren lassen. Dabei wird die ‘unnötige’ durch die ‘richtige’ PEM-Datei ersetzt.
1$ cfssl sign -config cfssl-cfg.json -profile leaf_ca \
2  -ca branch-ca.pem -ca-key branch-ca-key.pem leaf-ca.csr |
3    cfssljson -bare leaf-ca
4
5$ ls leaf-ca*
6leaf-ca.csr
7leaf-ca-csr.json
8leaf-ca-key.pem
9leaf-ca.pem
  1. PEM- in CRT-Datei kopieren und Zertifikat anzeigen.
1$ cp leaf-ca.pem leaf-ca.crt
2$ cfssl certinfo -cert leaf-ca.crt

Verwendung von KEY und CRT Dateien

Umwandeln von KEY- und CRT-Dateien zu Kubernetes secrets zur Verwendung in einem mit TLS abgesicherten Web-Service.

1$ CRT="$SRCDIR/my-service.crt"
2$ KEY="$SRCDIR/my-service.key"
3$ kubectl -n my-namespace  create secret tls  my-service-tls  --cert="$CRT" --key="$KEY"
4$ kubectl -n my-namespace  describe secret  my-service-tls

Grafische Werkzeuge

Firewall OPNsense (GUI im Web-Browser)

OPNsense ist eine Firewall-Software, die auf FreeBSD basiert. Neben der Aufgabe als Firewall können damit über Plugins auch viele andere Netzwerk-Dienste (u.A. DNS, DHCP, NTP, VPN, etc.) eingerichtet und verwaltet werden.

OPNsense enthält Plugins, die ein grafisches Frontend zu openssl und ACME bieten:

Windows

Im MatrixPost-Blog wird die Nutzung der PKI Möglichkeiten in Windows Server gezeigt.

THEMA LINK
PKI Design Part 1
Offline Root CA Part 2
Intermediate CA Part 3
Client Certificates Part 4
Auto Enrollment Part 5

Automationswerkzeuge

Zertifikate für Kubernetes: cert-manager

Der cert-manager wird für das automatisierte Anfordern und Erneuern von Zertifikaten in Kubernetes-Clustern benutzt.

Neuentdeckung: Open Source PKI Smallstep

Während der Vorbereitung dieses Vortrags bin ich auf ein “YouTube”-Video und Blog gestossen, in welchem Open-Source-Tools der Firma Smallstep zum Aufbau einer privaten CA benutzt wurden:

Bei der weiteren Recherche habe ich dieses Dokument des Firmengründers Mike Malone gefunden. Dort werden alle Eigenschaften von X.509v3-Zertifikaten und deren Life-Cycle klar und präzise erläutert:

Ich bin von Smallstep begeistert und werde mich verstärkt darum kümmern. Leider war die Zeit bis zum LinuxTag zu kurz, um tiefer einsteigen zu können. Die beiden u.g. Tools könnten cfssl ergänzen (oder sogar ersetzen).

Step-CA

Server-Tool:

  • Dokumentation] zum Tool step-ca zum Betreiben einer Certificate Authority CA.
  • Download des Source-Codes und der Software-Pakete von Github
  • Betrieb als Linux-Daemon oder im Docker-Container möglich

Step CLI

Client-Tool:

  • Dokumentation zum CLI-Tool step zum Anfordern und Verwalten von Zertifikaten aller Art.
  • Download des Source-Codes und der Software-Pakete von Github

Beispiele

Diese Artikel im Smallstep-Blog werden als Basis und Inspiration für meine Experimente dienen.

ACME: Automated Certificate Management Environment

Let’s Encrypt

Das Projekt “Let’s Encrypt” hat zum Ziel, dass alle Web-Seiten und sämtlicher Internet-Traffic nur noch in verschlüsselter Form (per TLS-Protokoll) übertragen werden.

  • Früher waren die dafür benötigten Zertifikate recht teuer und konnten zusammen mit einer DNS-Domäne gekauft werden. (Achtung: ABO-Modell!)
  • Es gibt aber DynDNS-Provider, die einer Hobby-Seite Zugang zu einer kostenlosen DNS-Domäne ermöglichen. Und seit es “Let’s Encrypt” gibt (also seit 2015), werden auch die dazu passenden X.509-Zertifikate kostenlos ausgestellt.

Zur Überprüfung, dass ein Webseiten-Betreiber tatsächlich die Kontrolle über den FQDN der Webseite hat, wurde das ACME-Protokoll eingeführt, welches “Domain-Validation” DV benutzt:

  1. Auf Anfrage durch den ACME-Client erzeugt der ACME-Server eine zufällige Information, die der Client auf einer speziellen HTTP-Unterseite der Webseite (oder als TXT-Record im DNS-System) veröffentlicht.
  2. Im nächsten Schritt überprüft der ACME-Server die HTTP-Unterseite (oder den TXT-Record). Falls dort die gleiche Zufallsinformation gefunden wird, die er vorher dem ACME-Client gesendet hat, kann er davon ausgehen, daß der Client echt ist. Mit anderen Worten: die Domäne ist validiert.
  3. Zum Schluss stellt der ACME-Server ein zeitlich befristetes Zertifikat (meist 90 Tage) für die DNS-Domäne des ACME-Clients aus, welches für die Übertragung der per TLS verschlüsselten HTTPS-Seiten des Web-Servers genutzt wird.
  4. Vor Ablauf der Frist muss sich der ACME-Client wieder an den ACME-Server wenden und um die Zertifikats-Verlängerung (d.h. Austellung eines ‘frischen’ Zertifikats) bitten.

Neben “Let’s Encrypt” gibt es auch noch andere Provider, die die ACME-Protokolle implementiert haben und oft auch kostenlose X.509-Zertifikate ausstellen.

Neueste Nachrichten!

  • Laut “Heise”-Newsticker arbeitet “Let’s Encrypt” an der Verkürzung der Zertifkats-Gültigkeit von 90 auf 6 Tage.
  • Die Trump-Regierung stoppt die Förderung von Open-Source-Projekten, wie “Let’s Encrypt”, “TOR” und “F-Droid”.

SmallStep ACME

Both step and step-ca are natively integrated with the ACME protocol. step can be used to request ACME certificates from any ACME server, while step-ca is a fully functional private ACME server that works with all popular ACME clients.

Zero-SSL

Im “Caddy” Webserver ist, anstelle von “Let’s Encrypt”, der Zertifikatsprovider “Zero-SSL” automatisch aktiviert.

Andere ACME-Clients

Certbot

Certbot is EFF’s tool to obtain certs from “Let’s Encrypt”. It’s written in Python.
It can also act as a client for any other CA that uses the ACME protocol.

LEGO

Let’s Encrypt/ACME client and library written in Go.

acme.sh

A pure Unix shell script implementing ACME client protocol.

Backlinks