Root-CA (OpenSSL)

Lesedauer: 5 Minuten

Die Root Certification Authority (Root-CA) bildet den Vertrauensanker der internen Public Key Infrastructure (PKI). Sie dient ausschließlich der Signierung nachgelagerter Zertifizierungsstellen (Intermediate-/Issuing-CAs) und stellt selbst keine Endanwender- oder Serverzertifikate aus. Aufgrund ihrer zentralen sicherheitstechnischen Bedeutung wird die Root-CA isoliert und grundsätzlich offline betrieben. Kompromittierungen oder Fehlkonfigurationen auf Ebene der Root-CA hätten Auswirkungen auf die gesamte Vertrauenskette der PKI und würden eine vollständige Neuausstellung aller abhängigen Zertifikate erforderlich machen. Ziel dieser Dokumentation ist die Beschreibung der Architektur, des Betriebsmodells sowie der sicherheitsrelevanten Anforderungen für Aufbau, Verwaltung und Absicherung der Root-CA innerhalb der internen PKI-Infrastruktur.

Installation

Basis der folgenden Prozedur ist Ubuntu-Server 24.04.4 LTS

Installation benötigter Pakete

$ sudo apt install openssl opensc pcscd rng-tools -y

Verwendete Komponenten:

  • openssl: OpenSSL bildet die zentrale technische Grundlage der gesamten PKI und stellt die kryptographischen Werkzeuge bereit für:
    • Schlüsselgenerierung
    • Erstellung von Certificate Signing Requests (CSR)
    • Zertifikatserstellung
    • Signaturprüfung
    • PKI-Operationen
  • opensc: OpenSC wird für spätere Hardware-Integration vorbereitet installiert. Die Komponente ermöglicht die Nutzung kryptographischer Hardware wie:
    • Smartcards
    • HSMs
    • YubiKeys
    • PKCS#11-kompatibler Hardware
  • pcscd: pcscd ist der PC/SC-Dienst für Smartcard-Kommunikation unter Linux. Bereitstellung der Kommunikation zwischen:
    • Betriebssystem
    • Kartenlesern
    • Smartcards
  • rng-tools: rng-tools verbessert die Verfügbarkeit kryptographischer Entropie. Kryptographische Schlüssel sind direkt von ausreichender Entropie abhängig. Dies ist insbesondere relevant:
    • in virtuellen Maschinen
    • auf Headless-Systemen
    • bei frischen Installationen

Erstellung eines dedizierten PKI-Benutzers

Benutzer anlegen:

$ sudo adduser pki

Wechsel zum PKI-Benutzer:

$ su - pki

Zweck:

Die Trennung der CA-Prozesse in einen dedizierten Benutzer reduziert:

  • versehentliche Rechteausweitung
  • Fehlbedienungen
  • Vermischung administrativer Prozesse

Erstellung der CA-Verzeichnisstruktur

Verzeichnisstruktur anlegen:

$ mkdir -p ~/root-ca/{certs,crl,newcerts,private,csr}

Schutz des Schlüsselverzeichnisses:

$ chmod 700 ~/root-ca/private

Initialisierung der OpenSSL-CA-Datenbank:

$ touch ~/root-ca/index.txt
$ echo 1000 > ~/root-ca/serial
$ echo 1000 > ~/root-ca/crlnumber

Zweck der Verzeichnisstruktur

  • ~/root-ca/certs: Speichert ausgestellte Zertifikate.
  • ~/root-ca/crl: Speichert Certificate Revocation Lists (CRLs).
  • ~/root-ca/newcerts: Von OpenSSL verwaltetes Archiv ausgestellter Zertifikate.
  • ~/root-ca/private: Speicherort privater Schlüssel. Dieses Verzeichnis besitzt restriktive Zugriffsrechte.
  • ~/root-ca/csr: Speicherort für Certificate Signing Requests.

OpenSSL-CA-Datenbank

  • ~/root-ca/index.txt: OpenSSL führt eine einfache Zertifikatsdatenbank zur Verwaltung ausgestellter Zertifikate. Die Datei enthält:
    • Seriennummern
    • Statusinformationen
    • Widerrufe
    • Ablaufdaten
  • ~/root-ca/serial: Definiert die nächste zu verwendende Zertifikatsseriennummer.
  • ~/root-ca/crlnumber: Definiert die nächste Versionsnummer für CRLs.

Erstellung der OpenSSL-Konfiguration

Konfigurationsdatei erstellen:

$ vi ~/root-ca/openssl.cnf

Inhalt der Konfigurationsdatei:

[ ca ]
default_ca                     = CA_default

[ CA_default ]
dir                            = /home/pki/root-ca
certs                          = $dir/certs
crl_dir                        = $dir/crl
new_certs_dir                  = $dir/newcerts
database                       = $dir/index.txt
serial                         = $dir/serial
crlnumber                      = $dir/crlnumber

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

default_md                     = sha512
policy                         = policy_strict
email_in_dn                    = no
name_opt                       = ca_default
cert_opt                       = ca_default
copy_extensions                = none

default_days                   = 7300

[ policy_strict ]
countryName                    = match
stateOrProvinceName            = optional
organizationName               = match
organizationalUnitName         = optional
commonName                     = supplied

[ req ]
default_bits                   = 4096
distinguished_name             = req_distinguished_name
string_mask                    = utf8only
default_md                     = sha512
x509_extensions                = v3_ca

[ req_distinguished_name ]
countryName                    = Country Name
countryName_default            = DE

organizationName               = Organization Name
organizationName_default       = Prontosystems

organizationalUnitName         = Organizational Unit Name
organizationalUnitName_default = PKI

commonName                     = Common Name
commonName_default             = Prontosystems Lab Root CA

[ v3_ca ]
subjectKeyIdentifier           = hash
authorityKeyIdentifier         = keyid:always,issuer
basicConstraints               = critical, CA:true
keyUsage                       = critical, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier           = hash
authorityKeyIdentifier         = keyid:always,issuer
basicConstraints               = critical, CA:true, pathlen:0
keyUsage                       = critical, cRLSign, keyCertSign

Erstellung des privaten Root-Schlüssels

Schlüsselgenerierung:

$ openssl genrsa -aes256 -out ~/root-ca/private/root-ca.key.pem 4096

Zugriffsrechte setzen:

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

Zweck:

Dieses Kommando erzeugt:

  • einen RSA-4096-Privatschlüssel
  • verschlüsselt mit AES-256

Der private Schlüssel stellt die eigentliche kryptographische Identität der Root-CA dar.

Ein Verlust oder eine Kompromittierung dieses Schlüssels gefährdet die gesamte PKI.

Erstellung des selbstsignierten Root-Zertifikats

Zertifikat erstellen:

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

Beschreibung der Parameter

  • -config: Verwendet die definierte OpenSSL-Konfiguration.
  • -key: Verwendet den privaten Schlüssel der Root-CA.
  • -new: Erzeugt intern eine neue Zertifikatsanfrage-Struktur.
  • -x509: Erzeugt direkt ein X.509-Zertifikat anstelle eines CSR. Das Zertifikat wird selbstsigniert.
  • -days 7300: Definiert die Laufzeit des Zertifikats auf 20 Jahre.
  • -sha512: Definiert den Hashalgorithmus der Zertifikatssignatur.
  • -extensions v3_ca: Übernimmt die X.509-CA-Extensions aus dem Abschnitt [ v3_ca ]. Diese Extensions definieren das Zertifikat funktional als Certification Authority.

Analyse des erzeugten Root-Zertifikats

Zertifikat anzeigen:

$ openssl x509 -noout -text -in ~/root-ca/certs/root-ca.cert.pem

Zweck:

Das Kommando analysiert und visualisiert:

  • Subject
  • Issuer
  • Public Key
  • Extensions
  • Signaturalgorithmus
  • Gültigkeit
  • Zertifikatsattribute

Es erfolgt keine Veränderung des Zertifikats.

Eigenschaften der erzeugten Root-CA

Die erzeugte Root-CA besitzt:

  • RSA-4096-Schlüssel
  • SHA-512-Signaturen
  • X.509v3-CA-Extensions
  • selbstsigniertes Root-Zertifikat
  • CA-spezifische Key Usage
  • Subject- und Authority-Key-Identifier

Wesentliche CA-Merkmale:
Basic Constraints: CA:TRUE
Key Usage: Certificate Sign, CRL Sign

Diese Extensions definieren die Fähigkeit:

  • andere Zertifikate zu signieren
  • CRLs zu signieren

Sicherheitsbetrachtung

Die Root-CA bildet den kryptographischen Vertrauensanker der gesamten PKI.

Die Root-CA sollte:

  • ausschließlich offline betrieben werden
  • nur zur Signierung von Intermediate-CAs genutzt werden
  • mehrfach verschlüsselt gesichert werden
  • physisch geschützt werden

Der operative Zertifikatsbetrieb sollte ausschließlich über Intermediate-CAs erfolgen.

Loading

Updated on 15. Mai 2026
Was this article helpful?

Related Articles