Allgemein:Zertifikate-SymmetrischeAsymmetrische
Zertifikate Allgemein
Zertifikate sind selbst für IT-Profis schwierig zu verstehen und oft im täglichen IT-Leben eine Herausforderung. Der korrekte Umgang mit Zertifikaten ist jedoch -speziell in der Security- unerlässlich. Mit dem Begriff "Zertifikat" (certificate) wird dabei sehr "allgemein" Umgegangen und man versteht dabei meistens darunter "öffentliche" Zertifikate und/oder "private" Zertifikate. Dabei ist Wichtig zu wissen, dass ein "öffentliches" (Public Key) Zertifikat auf einem "privaten" (Private Key) Zertifikat basiert.
Ein Webserver-Zertifikat dient der Authentifizierung eines Servers gegenüber dem Browser. Der Server kann sich aber nur dann ausweisen, wenn er auch den "privaten" Schlüssel besitzt. Der Browser hingegen benötigt das Zertifikat (Public Key), um die Authentizität der vom Server erhaltenen Daten zu überprüfen. Folglich benötigt man ein Zertifikat mit "private" Schlüssel, um einen sicheren Kommunikationskanal anzubieten.
Zertifikate - Verschlüsselung
Es gibt Grundsätzlich zwei Arten von Verschlüsselungsverfahren:
[Symmetrische Verschlüsselung] [Asymmetrische Verschlüsselung]
Zertifikate - Symmetrische Verschlüsselung
[Symmetrische Verschlüsselung] Symmetrische Verschlüsselung erfordert, dass jeder Kommunikationspartner im Besitz eines gemeinsamen Schlüssels ([Pre-Shared Key]) ist. Nur dann ist er in der Lage, verschlüsselte Daten zu lesen, zu senden und zu verändern. Aufgrund der Funktionsweise der symmetrischen Verschlüsselung ist es von grösster Wichtigkeit, dass der Schlüssel nicht in die falschen Hände gerät. Mit steigender Anzahl von Teilnehmern erhöht sich auch die Gefahr, dass der Schlüssel kompromittiert wird. Da jeder Teilnehmer denselben Schlüssel verwendet, muss dieser an jeden übermittelt werden, was einen großen Sicherheitsnachteil darstellt. Die bekanntesten Algorithmen zur symmetrischen Verschlüsselung sind: [Advanced Encryption Standard" (AES)] [Data Encryption Standard" (DES)] NOTE DES stellt den Vorgänger dar von AES und sollte nicht mehr benutzt werden!
Zertifikate - Asymmetrische Verschlüsselung
[Asymmetrische Verschlüsselung] Verwendet einen "öffentlichen" (Public Key) und einen "privaten" (Private Key) Anteil, die "mathematisch" in Verbindung stehen. Der geheimer oder privater Schlüssel (Private Key) gehört nur einer einzigen Person und darf nicht öffentlich gemacht oder weitergegeben werden. Der öffentliche Schlüssel (Public Key) darf und "muss" sogar an Kommunikationspartner verteilt werden. Die asymmetrische Verschlüsselung bildet so die Grundlage für Zertifikate. NOTE Diese Verschlüsselungsart "Asymmetrisch" wird auch "[Public Key Cryptography]" genannt.
Alles beginnt mit dem "privaten" Schlüssel (Private Key). Aus ihm wird der "öffentliche" Schlüssel (Public Key) erzeugt und kann jeder Zeit wiederhergestellt werden. Daten, die mit einem der beiden "verschlüsselt" wurden, können nur mit dem anderen wieder "entschlüsselt" werden. Die Übermittlung von verschlüsselten Daten beruht darauf, dass die Daten mithilfe des "öffentlichen" Schlüssels (Public Key) des Empfängers "verschlüsselt" werden, so dass nur noch der Empfänger in der Lage ist, den Klartext zu ermitteln. Denn nur er befindet sich im Besitz des passenden "öffentlichen" Schlüssels (Public Key).
Zertifikate - Asymmetrische Verschlüsselung und die "Diffie-Hellman" Problematik
Die Asymetrische Verschlüsselung wie schon im vorherigen Artikel erklärt basiert im Grundsatz auf einem "private" Key und einem darauf basierenden "public" Key. Zur Erinnerung: Alles beginnt mit dem "privaten" Schlüssel (Private Key). Aus ihm wird der "öffentliche" Schlüssel (Public Key) erzeugt und kann jeder Zeit wiederhergestellt werden. Daten die mit einem "Public-Key" verschlüsselt weren können nur mit dem korrespondierenden "Private-Key" entschlüsselt werden. Die Übermittlung von verschlüsselten Daten beruht darauf, dass die Daten mithilfe des "öffentlichen" Schlüssels (Public Key) des Empfängers "verschlüsselt" werden, so dass nur noch der Empfänger in der Lage ist, den Klartext zu ermitteln. Denn nur er befindet sich im Besitz des passenden "privaten" Schlüssels (Public Key). Diese Verschlüsselungsart "Asymmetrisch" wird auch "[Public Key Cryptography]" genannt.
In diesem Verfahren gibt es einem Umstand dem Rechnung zu tragen. Formal besteht ein "Public-Key-Verschlüsselungsverfahren" aus drei Algorithmen:
- Der Schlüsselerzeugungsalgorithmus erzeugt zu einem gegebenen Sicherheitsparameter (2048bit, 4096bit) ein Schlüsselpaar, das aus einem öffentlichen
(Oeffentlicher Key "public") und dem dazugehörigen geheimen Schlüssel (Privater Key "private") besteht.
- Der Verschlüsselungsalgorithmus erzeugt aus einem Klartext unter Verwendung des öffentlichen Schlüssels (Oeffentlicher Key "public") einen Geheimtext (Cyphertext).
- Der Entschlüsselungsalgorithmus berechnet zu einem Geheimtext (Cyphertext) unter Verwendung des geheimen Schlüssels den passenden Klartext.
Das Problem: Bei der Daten-Übertragung mittels zB SSL/TLS werden mit einem Lanzeitschlüssel (pub-priv-key) sogenannte Sitzungsschlüssel für jede Session erzeugt (Session-keys). Hat ein Angreifer Zugriff auf den Langzeitschlüssel so können sämtliche vergangenen Sitzungsschlüssel errechnet werden und somit die gesamte Kommunikation entschlüsselt werden. Dies wird durch Perfect Forward Secrecy (PFS) unterbunden. Ein möglicher Angreifer kann trotz Kenntnis des Langzeitschlüssels keinerlei Rückschlüsse auf die ausgehandelten Sitzungsschlüssel ziehen. Bei zB. TLS wird dies dadurch erreicht, dass der Langzeitschlüssel zu einem Signaturverfahren gehört und nur benutzt wird, um Kurzzeitschlüssel zu signieren. Mit diesen wird jeweils durch einen Diffie-Hellman-Schlüsselaustausch ein Sitzungsschlüssel ausgehandelt. Wird ein Server kompromittiert, erfährt der Angreifer nur den langfristigen Signaturschlüssel und die Sitzungsschlüssel gerade aktiver Verbindungen. Die Sitzungsschlüssel zurückliegender Verbindungen sind bereits gelöscht und lassen sich nicht mehr rekonstruieren. In diesem Verfahren werden sogenannte "Diffie-Hellmann-Parameter" (auch Diffie-Hellmann-Group) verwendet. Eine DH-Group ist eine Liste von langen Primzahlen welche für das PFS-Verfahren (Perfect Forward Secret) verwendet werden. Bis vor kurzem galten diese Listen als sicherheits-unkritisch und wurden aus diesem Grund vom Hersteller "vorberechnet" und ausgeliefert. Somit verwenden tausende Rechner die gleichen Listen. Seit kurzem steht dieses Verfahren unter Kritik und es wird empfohlen eigene DH-Groups/Params zu erzeugen. Siehe auch:
https://weakdh.org/sysadmin.html
Diesem Umstand kann abgeholfen werden dh. indem eigenen "DH" Parameter erstellt werden. Dabei ist jedoch zu berücksichtigen, dass man im Vorraus nicht weiss welcher Parameter benutzt werden soll dh. einige Clients kommen mit "hardcoded" Parameter und fordern einen "1024" Code an und andere wiederum "512". Dies zwingt uns e nachdem mehrere dieser "DH" Parameter zur Verfügung zu stellen. Diese "DH" Parameter die erstellt werden sind nicht Installations spezifisch dh. Sie können durchaus auch auf einem anderen Server erstellt werden und für mehrere Installationen benutzt werden. Um so einen "DH" Parameter auf einem Linux System anhand "OpenSSL" zu erzeugen kann folgendes durchgeführt werden:
# mkdir /opt/DH-Param
# chmod 700 /opt/DH-Param
# chown root:root /opt/DH-Param
# cd /opt/DH-Param
Nun erzeuge zB einen "256bit" langen "DH" Parameter:
# openssl genpkey -genparam -algorithm DH -pkeyopt dh_paramgen_prime_len:256 -out dh256.pem
........+......+..............+.......+...+...+..+........+.............++*++*++*++*++*++*++*++*++*++*++*++*
Nach der Erzeugung kann der "DH" Parameter ebenfalls mit folgenden Kommando als "text ausgegeben werden:
# openssl pkeyparam -text -in dh256.pem
-----BEGIN DH PARAMETERS-----
MCYCIQD1xBUy+F1DHmgT6t7ET7vHXN1Sm2TbvmlXfbQeoP1JSwIBAg==
-----END DH PARAMETERS-----
PKCS#3 DH Parameters: (256 bit)
prime:
00:f5:c4:15:32:f8:5d:43:1e:68:13:ea:de:c4:4f:
bb:c7:5c:dd:52:9b:64:db:be:69:57:7d:b4:1e:a0:
fd:49:4b
generator: 2 (0x2)
Um einen "DH" Paramter mit höherer Bit Anzahl zu erzeugen zB 512, 1024, 2048 sowie 4096 kann folgendes ausgeführt werden:
# /bin/openssl genpkey -genparam -algorithm DH -pkeyopt dh_paramgen_prime_len:512 -out dh512.pem
# /bin/openssl genpkey -genparam -algorithm DH -pkeyopt dh_paramgen_prime_len:1024 -out dh1024.pem
# /bin/openssl genpkey -genparam -algorithm DH -pkeyopt dh_paramgen_prime_len:2048 -out dh2048.pem
# /bin/openssl genpkey -genparam -algorithm DH -pkeyopt dh_paramgen_prime_len:4096 -out dh4096.pem
Der Vorgang diese "DH" Parameter selber zu erzeugen ist einfach jedoch diese in den verschiedenen Services wie zB Apache, Postfix usw. einzubinden ist eine Andere. Speziell bei Herstellern basierend auf dem eigenen OS fehlt die Schnittstelle of diese erzeugten "DH" Paramter einzubinden. Die nachfolgende Seite zeigt auf wie bei verschiedenen Service wie Apache, Postfix, Cyrus-IMAP vorzugehen ist um den selbst erzeugten "DH" Paramter einzubinden:
https://weakdh.org/sysadmin.html
Zertifikate - Asymmetrische Signatur
Die zweite Anwendung von asymmetrischer Verschlüsselung ist das Erstellen von Signaturen, um die Authentizität von Daten zu gewährleisten. Dabei macht man sich zu Nutze, dass die Verschlüsselung von Daten mithilfe des "privaten" Schlüssels (Private Key) durch den "öffentlichen" Schlüssel (Public Key) rückgängig gemacht werden kann. Dadurch ist jeder (mit dem öffentlichen Schlüssel des Absenders) in der Lage, die Signatur zu entschlüsseln. Allerdings konnte nur der Absender die Signatur erzeugen, da nur er sich im Besitz des "privaten" Schlüssels (Private Key) befindet. Für eine Signatur muss aber nicht die gesamte Nachricht wiederholt werden. Stattdessen wird ein so genannter "Hash-Wert" aus der Klartext-Nachricht erzeugt, der dann mit dem "privaten" Schlüssel (Private Key) des Absenders verschlüsselt wird. Die Überprüfung der Signatur verläuft sehr ähnlich zur Erzeugung:
Der Empfänger erstellt ebenfalls den Hash-Wert der Klartext-Nachricht und vergleicht
diesen mit dem entschlüsselten Hash-Wert des Absenders. Sind diese identisch, handelt
es sich um eine gültige Signatur und die Nachricht kann als authentische eingestuft werden.
NOTE Ein Hash-Wert wird durch eine Funktion erstellt, die aus einem Text beliebiger Länge eine
eindeutige Zeichenkette fester Länge erzeugt. Die Funktion ist nicht umkehrbar, so dass
es unmöglich (oder wenigstens sehr schwer) ist, den Klartext zu einem Hash-Wert zu ermitteln.
Durch die Verwendung von "Public Key Cryptography" kann die Authentizität und Integrität mithilfe von Signaturen sichergestellt werden. Die Vertraulichkeit beruht auf der Verschlüsselung der Nachricht. Damit Public Key Cryptography funktioniert, muss man offensichtlich seinen öffentlichen Schlüssel (Public Key) mit potentiellen Kommunikationspartnern teilen. Da ein öffentlicher Schlüssel (Public Key) aber nur durch eine unpersönliche Zeichenkette repräsentiert wird, wäre es notwendig, ein "Adressbuch" zu pflegen. Darin müsste zu jedem öffentlichen Schlüssel (Public Key) die Identität des Absenders vermerkt sein. Dieses Adressbuch würde aber ein Angriffsziel darstellen. Sollte ein Angreifer den öffentlichen Schlüssel (Public Key) eines bekannten Empfängers austauschen, wäre die Kommunikation kompromittiert. Daher wurde das Zertifikat erfunden. Es verschmilzt einen öffentlichen Schlüssel (Public Key) mit Identitätsinformationen mithilfe einer Signatur. Beispiele zu diesen Ausführungen wären:
Pretty Good Privacy (PGP)
GNU Privacy Guard (GPG)
Diese basieren auf einem so genannten [Web of Trust], einem Netz aus Vertrauensstellungen. Jeder Teilnehmer kann die Zuordnung eines öffentlichen Schlüssels (Public Key) und den Identitätsinformationen mithilfe einer Signatur bestätigen. Dadurch benötigt jeder Teilnehmer nur wenige enge Freunde. Das Netz spannt sich durch die Signaturen untereinander auf. Erhält ein Teilnehmer eine Nachricht von einem (noch) unbekannten, lässt sich die Authentizität durch eine Kette aus vertrauenswürdigen Unterzeichnern überprüfen. Es handelt sich um einen "Community-basierten" Ansatz und erfordert eine kritische Masse von Teilnehmern, damit Kommunikationspartner verbunden sind.
Zertifikate - Erstellen einer eigenen CA (Certificate Authority)
Zu Beginn: Vielen Dank gilt "Philipp Schrödel" für seine ausführliche Dokumentation und Zeitaufwand betreffend den nachfolgenden Informationen! Der nachfolgenden Dokumentation/Informationen unterliegen nachfolgende Allgemeinen Informationen:
Certificate Authority (private)
Dieses CA berücksichtigt folgende Informationen:
• Best practice (2015) regarding crypto, key-length etc.
• Das Root-CA wird erstellt für eine "fiktive" Firma «TheBC».
• Es wird kein "intermediate" Zertifikat Authority erstellt.
• Alle Kommandos basierend auf Linux werden im Verzeichnis "/opt/CA" ausgeführt.
• Der CRL (Certifcate Revocation List) Distribution Point befindet sich auf der URL http://crl.thebc.ch/TheBC-CA.crl.pem
• Der OCSP (Online Certificate Status Protocol) befindet sich auf der URL http://ocsp.thebc.ch:8888
In den nächsten Schritten wird die "CA" erstellt sprich das "Certificate Authority". Dazu erstellen wird die Verzeichnis Struktur resp. das "home" Verzeichnis für das "Certificate Authority":
# mkdir -p /opt/CA/private /opt/CA/certs /opt/CA/crl /opt/CA/csr /opt/CA/newcerts
# cd /opt/CA
Nun benötigen wir einige Files die erstellt werden müssen:
1. Ein "random" File das von der CA benutzt wird.
2. Ein "index" File in dem die erstellten Zertifikate gespeichert werden.
3. Ein "index" File für die CRL (Certificate Revocation List).
4. Anpassen der Rechte für das Verzeichnis "./private"
# openssl rand -out /opt/CA/private/RANDFILE 8192
# touch /opt/CA/index.txt
# echo 01 > crl/crl.number
# chmod 700 /opt/CA/private
Damit unsere "CA" Konsitent ist und bleibt definieren wir ein "Global Configuration". Dieses Konfig File ist unter "OpenSSL" auch als "openssl.cnf" definiert.
# vi /opt/CA/TheBC-CA.conf
--------------- /opt/CA/TheBC-CA.conf ---------------
####################################################################
# CA Definition `man ca`
#
# The [ ca ] section is mandatory. Here we tell OpenSSL to use the
# options from the [ CA_default ] section.
#
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
# The [ CA_default ] section contains a range of defaults.
# Make sure you declare the directory you chose earlier (/opt/CA). [ CA_default ]
# Directory and file locations.
dir = /opt/CA # Where everything is kept
certs = $dir/certs # default place for new certs
crl_dir = $dir/crl # clr directory
new_certs_dir = $dir/newcerts
database = $dir/index.txt # database index file
serial = $dir/serial # Don't initialize with echo, use -create_serial
RANDFILE = $dir/private/RANDFILE # private random number file
# The root key and root certificate
private_key = $dir/private/TheBC-CA.key.pem # CA private key
certificate = $dir/certs/TheBC-CA.cert.pem # CA certificate
# For certificate revocation lists
crlnumber = $dir/crl/crl.number # current crl number
crl = $dir/crl/ca.crl.pem # current crl
crl_extensions = crl_ext # [ crl_ext ]
default_crl_days = 30 # The default life for a certificate and a CRL.
default_md = sha512 # Default digest algorithm
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options
default_days = 365 # The default life for a certificate and a CRL.
preserve = no # openssl will re-order the attributes in the DNs of CSRs
policy = policy_anything # [ policy_anything] default policy section to use
####################################################################
# An alternative policy not referred to anywhere in this file. Can
# be used by specifying '-policy policy_anything' to ca(8).
#
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
# This is where we define how to generate CSRs
# [ req ] section are applied when creating certificates or certificate signing requests.
# Options for the `req` tool (`man req`) [ req ]
default_bits = 4096 # Size of keys
distinguished_name = req_distinguished_name # [ req_distinguished_name ]
string_mask = utf8only # permitted characters
default_md = sha512 # message digest algorithm
####################################################################
# Per "req" section, this is where we define DN info
# The [ req_distinguished_name ] section declares the information normally required in a certificate signing request. You can optionally specify some defaults.
#
[ req_distinguished_name ]
#countryName = Country Name (2 letter code)
#countryName_default = US
#countryName_min = 2
#countryName_max = 2
#stateOrProvinceName = State or Province Name (full name)
#stateOrProvinceName_default = NEW YORK
#localityName = Locality Name (city, district)
#localityName_default = NEW YORK
0.organizationName = Organization Name (company)
0.organizationName_default = TheBC
organizationalUnitName = Organizational Unit Name (department, division)
organizationalUnitName_default = Certificate Authoriy Departement
emailAddress = Email Address
emailAddress_max = 64
emailAddress_default = sysop@thebc.ch
commonName = Common Name (hostname, IP, or your name)
commonName_max = 64
####################################################################
# The next few sections are extensions that can be applied when signing certificates.
# For example, passing the -extensions v3_ca command-line argument will apply the options set in [ v3_ca ].
####################################################################
# We’ll apply the v3_ca extension when we create the root certificate. [ 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
####################################################################
# We’ll apply the v3_ca_intermediate extension when we create the intermediate certificate. pathlen:0 ensures that there can be no further certificate authorities below the intermediate CA.
[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
####################################################################
# Stanza for OCSP servers [ v3_OCSP ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = critical, OCSPSigning
####################################################################
# We’ll apply the usr_cert extension when signing client certificates, such as those used for remote user authentication.
[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
#nsCertType = server # ssl server
#nsCertType = objsign # ssl object signing
#nsCertType = client, email # client
nsCertType = client, email
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection
####################################################################
# We’ll apply the server_cert extension when signing server certificates, such as those used for web servers. [ server_cert ]
# Extensions for server certificates (`man x509v3_config`). basicConstraints = CA:FALSE
#nsCertType = server # ssl server
#nsCertType = objsign # ssl object signing
#nsCertType = client, email # client
nsCertType = server
subjectKeyIdentifier = hash
--------------- /opt/CA/TheBC-CA.conf ---------------
Als nächstes erstellen wir den "root key" (TheBC-CA.key.pem) für unser "CA" und dieser muss absolut abgesichert sein gegenüber unerlaubten Zugriffen. Wenn jemand Besitz erlangt über den "root key" kann dieser anhand diesem "Trusted Zertifikate" erstellen. Aus diesem Grund wird der "root key" mit AES256 Verschlüsselt anhand einem "sicheren" Passwort.
NOTE Erstelle all "root" sowie "intermediate" Zertifikat Key's mit einer Key Länge von 4096bit. Obwohl 4096bit benutzt wird können später
Server und Client Zertifikate mit einer tieferen bit Länge erzeugt werden!
# openssl genpkey -aes256 -out private/TheBC-CA.key.pem -algorithm RSA -pkeyopt rsa_keygen_bits:4096
# chmod 400 private/TheBC-CA.key.pem
Nun erstelle den "root certificate signing request". Benütze den "root key" (ca.key.pem) um das "root" Zertifikat (ca.cert.pem) zu erstellen. Vergebe bei der Erstellung des "root" Zertikates ein spätes Verfalldatum von ca. 20 Jahren. Wenn das "root" Zertifikat abläuft werden alle darauf basierenden und gezeichnete Zertifikate ungültig.
# openssl req -config TheBC-CA.conf -key private/TheBC-CA.key.pem -new -extensions v3_ca -out csr/TheBC- CA.csr.pem
NOTE Als "CN" resp. Common Name muss nicht der FQDN des Server benutzt werden sonden zB "TheBC-Root-CA"
Das "root" Zertifikat ist erstellt nun zeichne dieses und denke an das Verfalldatum da in unsere "Global Configuration File" als "default_days" 365 definiert ist und dies mit unseren Angaben übersteuert wird (3650 Tage = 10 Jahre):
# openssl ca -create_serial -config TheBC-CA.conf -selfsign -days 3650 -extensions v3_ca -in csr/TheBC- CA.csr.pem -out certs/TheBC-CA.cert.pem
# chmod 444 certs/TheBC-CA.cert.pem
Nun überprüfe das "root" Zertifikat:
# openssl x509 -noout -text -in certs/TheBC-CA.cert.pem
Bei dieser Ueberüfung sollten folgende Position kontrolliert werden:
• Der benutzte "Signature Algorithm" (sha512WithRSAEncryption)
• Das Ablaufdatum "Certificate Validity"
• Die Public-Key bit Länge (4096 bit)
• Der "Issuer", das ist der "entity" der das Zertifikat gezeichnet hat
• Das "Subject", dieser referenziert auf das Zertifikat selber
• Der "Basic Constraints" sollte "CA:TRUE" sein
• Der "Key Usage" sollte auf "Digital Signature , Certificate Sign. CRL Sign" sein
NOTE Der "Issuer" und "Subject" sind identisch da es sich um ein "Self-Sign" Zertifikat handelt. Alle "root" Zertifikate
sind "Self-Signed"!
Nun erstelle den "Chain":
# cat intermediate/certs/intermediate.cert.pem certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
# chmod 444 intermediate/certs/ca-chain.cert.pem
Wenn kein "Intermediate Certificate Authority" vorhanden ist kopiere das "public" Zertifikat vom "root" Zertifikat:
# cp certs/TheBC-CA.cert.pem certs/TheBC-CA-chain.cert.pem
# chmod 444 certs/TheBC-CA-chain.cert.pem
Nun zum "Final" check hie eine Uebersicht über unsren Files und Struktur (CA-directory-tree):
:/opt/CA> tree
.
├── certs
│ ├── TheBC-CA.cert.pem # Public Cert of the CA
│ └── TheBC-CA-chain.cert.pem # Certificate Chain
├── crl
│ └── crl.number # Index of the CRL (atm. 01)
├── csr
│ └── TheBC-CA.csr.pem # CSR for the CA (can be deleted)
├── index.txt # DB with the issued certificates
├── index.txt.attr # Contains some extra attributes ???
├── index.txt.old # Backup file
├── newcerts
│ └── B15E2E0017A94F06.pem # The same as TheBC-CA.cert.pem
├── private
│ ├── RANDFILE # Contains some random numbers
│ └── TheBC-CA.key.pem # Private key of the CA (SENSITIVE!)
├── serial
└── TheBC-CA.conf # The configuration file for the CA
5 directories, 12 files
:/opt/CA>
Zertifikate - Erstellen eines "Server Certificates" anhand unsere CA (Certificate Authority)
Als nächstes erstellen wir basierend auf unserer eigenen "CA" ein Server Zertifikat resp. den "server key":
# openssl genpkey -out private/thebc.ch.key.pem -algorithm RSA -pkeyopt rsa_keygen_bits:4096
Nun ertelle den Zertifikat "signing request":
# openssl req -config TheBC-CA.conf -key private/thebc.ch.key.pem -new -out csr/thebc.ch.csr.pem
Nun zeichne den Zertifikat "signing request":
# openssl ca -config TheBC-CA.conf -extensions server_cert -in csr/thebc.ch.csr.pem -keyfile private/ ca.key.pem -out certs/thebc.ch.cert.pem
# openssl ca -config TheBC-CA.conf -extensions server_cert -in csr/thebc.ch.csr.pem -out certs/ thebc.ch.cert.pem
Beispiel
:/opt/CA> openssl ca -config TheBC-CA.conf -extensions server_cert -in csr/thebc.ch.csr.pem -out certs/ thebc.ch.cert.pem
Using configuration from TheBC-CA.conf
Enter pass phrase for /opt/CA/private/TheBC-CA.key.pem: Check that the request matches the signature
Signature ok Certificate Details:
Serial Number: 12780703370455895815 (0xb15e2e0017a94f07) Validity
Not Before: Jun 24 20:09:41 2015 GMT
Not After : Jun 23 20:09:41 2016 GMT
Subject:
organizationName = TheBC
organizationalUnitName = Certificate Authoriy Departement commonName = thebc.ch
emailAddress = sysop@thebc.ch X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type: SSL Server
X509v3 Subject Key Identifier: 91:73:EA:91:8D:D9:F2:9D:EA:51:A0:0C:61:21:35:ED:1C:16:66:0D
X509v3 Authority Key Identifier: keyid:B1:9C:83:84:2C:3B:64:B6:A0:BE:C2:CD:DB:20:70:C6:75:32:70:AE
DirName:/O=TheBC/OU=Certificate Authoriy Departement/CN=TheBC-Root-CA/ emailAddress=sysop@thebc.ch
serial:B1:5E:2E:00:17:A9:4F:06
X509v3 Key Usage: critical
Digital Signature, Key Encipherment X509v3 Extended Key Usage:
TLS Web Server Authentication X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.thebc.ch/TheBC-CA.crl.pem
Authority Information Access:
OCSP - URI:http://ocsp.thebc.ch:8888
Certificate is to be certified until Jun 23 20:09:41 2016 GMT (365 days) Sign the certificate? [y/n]:
Um nun das Zertifikat dem Server zur Verfügung zu stellen benötigen wir folgende Files:
• TheBC-CA-chain.cert.pem (CA Certificate Chain)
• thebc.ch.key.pem (private)
• thebc.ch.cert.pem (public)
Zertifikate - Erstellen einer "Certificate Revocation List"
Eine "Certification Revocation List (CRL) beinhaltet Informationen über die Zertifikate und welche Wiederrufen wurden (revoked). Eine "CRL" kann als "Client" Applikation wie zB ein WebBrowser um die "Authentität" eines Server zu überprüfen oder für eine "Server" Applikation wie zB ein Apache oder OpenVPN um zu verhindern das Client sich verbinden die nicht mehr "trusted" Vertrauenswürdig sind. Ein "CRL" wird unter normalen Umständen öffentlich publiziert zB über eine URL. Drittanbieter können diese CRL Informationen über zB diese URL abfragen um festzustellen ob basierend auf dem Zertifikat diese noch gültig ist oder nicht (revoked). Im nächsten Schritt fügen wir unserem "Global Configuration File" den entsprechenden Eintrag hinzu für den "Distribution Point" (URL):
NOTE Einige Applikationsanbieter unterstützen diesen Vorgang nicht mehr und benützen stattdessen das "Online
Certificate Status Protocol (OCSP)!
# vi /opt/CA/TheBC-CA.conf
--------------- /opt/CA/TheBC-CA.conf ---------------
[ server_cert ]
crlDistributionPoints = URI:http://crl.thebc.ch/TheBC-CA.crl.pem
--------------- /opt/CA/TheBC-CA.conf ---------------
Generiere die "CRL":
# cd /root/ca
# echo 01 > crl/crl.number
# openssl ca -config /opt/CA/TheBC-CA.conf -gencrl -out crl/TheBC-CA.crl.pem
NOTE Die "CRL Options" können anhand "man ca" eingesehen werden und enthält zusätzliche Informationen!
Um die "CRL" einzusehen kann folgender Befehl benutzt werden
# openssl crl -in crl/ca.crl.pem -noout -text
Im "output" ist zu ersehen das keine Zertifikate "revoked" sind dh. der "output" zeigt an "No Revoked Certificates". Eine "CRL" wird unter normalen Umständen in Abstäden von 30 Tagen neu erstellt. Per Standard läuft eine "CRL" nach 30 Tagen ab. Dieser Vorgang resp. Umstand wird kontrolliert über die Definition "default_crl_days" im File "/opt/CA/TheBC-CA.conf" innerhalb des Absatzes "[ CA_default ]". Wenn ein Zertifikat als ungültig erklärt werden soll muss ein "revoke" auf dieses Zertifikat durchgeführt werden. Dies geschieht folgendermassen:
# openssl ca -config /opt/CA/TheBC-CA.conf -revoke cert s/bob@example.com.cert.pem
Danach muss die CRL neu erstellt werden:
# openssl ca -config /opt/CA/TheBC-CA.conf -gencrl -out crl/ca.crl.pem
Wenn "Server Seitig" eine "CRL" benutzt wird überprüft im normal Fall die Server Applikation das Client Zertifikat über dessen Gültigkeit. Diese "Server Seitige" Applikation benötigt lokalen Zugriff auf die "CRL". Als Beispiel: Der Admin fügt dem "Apache" Server die Konfiguration "SSLCARevocationPath" hinzu und verweist lokal auf das File "ca.crl.pem". Wenn ein User zB "Bob" auf den "Apache" zugreifft überprüft der "Apache" ob das "Client Zertifikat" von "Bob" in der "CRL" noch gültig ist oder nicht. Ist das "Client Zertifikat" nicht mehr gültig verweigert der "Apache" den Zugriff von "Bob".
Wenn "Client Seitig" eine "CRL" benutzt wird dh. ein "Server Zertifikat" vorhanden ist überprüft die lokale Application zB der Browser das Zertifikat. Diese lokale Applikation benötigt Zugriff auf die "CRL" (URL). Wenn ein Zertifikat signiert wird die den "crlDistributionPoints" beinhaltet, kann dieses "Client Zertifikat" die überprüfung anhand dieses "crlDistributionPoints" zB URL durchführen.
Das "Online Certificate Status Protocol (OCSP) wurde erstellt als Alternative zur "CRL" (Certication Revocation List). Aehnlich wie bei der "CRL" aktiviert "OCSP" den Antragsteller zB WebBrowser, WebServer usw. zu eruieren ob das Zertifikat noch über seine Gültigkeit verfügt. Wenn eine "Certificate Authority" ein Zertifikat signiert enthält es typischerweise die Adresse des OSCP Servers zB http://ocsp.thebc.ch. Dies kommt der Definiton "crlDistributionPoints" gleich wie Analog der "CRL". Als Beispiel: Wenn einem WebBrowser ein "Server Certificate" überprüft sendet dieser eine Anfrage an den "OCSP" Server (enthalten im Zertifikat). Der "OSCP" Server verarbeitet die Anfrage und Antwortet mit dem Status des Zertifikates resp. "revocation status".
NOTE Es ist empfohlen "OSCP" zu benutzen anstelle von "CRL" da die Untersützung betreffend "CRL" in einigen Browsern entfernt wurde!
Für "OSCP" muss wiederum dem "Global Configuration File" (/opt/CA/TheBC-CA.conf) wie bei der "CRL" die Konfiguration betreffend zB URL hinzugefügt werden. Dies wird mit der Konfiguration "authorityInfoAccess" durchgeführt im Absatz "[ server_cert ]":
# vi /opt/CA/TheBC-CA.conf
--------------- /opt/CA/TheBC-CA.conf ---------------
[ v3_OCSP ] basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = OCSPSigning
[ server_cert ]
authorityInfoAccess = OCSP;URI:http://ocsp.thebc.ch:8888
--------------- /opt/CA/TheBC-CA.conf ---------------
Nun muss ein "OCSP pair" erstellt werden. Der "OSCP" Responder benötigt ein "cyrptographic pair" um den eingehenden Request zu signieren. Dieses "OCSP pair" muss vom gleichen "Certificate Authority (CA) signiert werden sowie muss das gleiche "CA" sein mit dem das Zertifikat signiert wurde anhand dessen eine Uebrprüftung stattfindet zum "OSCP" Server.
KEY:
# openssl genpkey -out private/ocsp.thebc.ch.key.pem -algorithm RSA -pkeyopt rsa_keygen_bits:4096
CSR:
# openssl req -config TheBC-CA.conf -key private/ocsp.thebc.ch.key.pem -new -out csr/ocsp.thebc.ch.csr.pem
SIGN:
# openssl ca -config TheBC-CA.conf -extensions v3_OCSP -in csr/ocsp.thebc.ch.csr.pem -out certs/ocsp.thebc.ch.cert.pem
CHECK:
# openssl x509 -noout -text -in certs/ocsp.thebc.ch.cert.pem
Bei diesem "output" wird als Beispiel ungfähr folgendes angezeigt:
X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing
Der "OpenSSL OSCP Tool" kann als "OSCP" Server eingesetzt werden jedoch ist dieser im Status "Testing". Andere "OSCP" Server existieren sind jedoch "out of scope" in dieser Dokumentation. Um ein Zertifikat zu "revoken" sprich als Ungültig zu erklären kann folgendes Beispiel herangezogen werden:
1. Erstelle zu Testzwecken ein Server Zertifikat
2. Starte den "OpenSSL OSCP Server" über Localhost. Anstelle das die "revoke" Liste in einem seperaten "CRL"
File gespeichert wird liest der "OSCP Server" das File "index.txt" aus. Beantwortet wird die Anfrage auf
den "OSCP Server" mit einem "cryptographic par" (benutzt dabei werden die Optionen -rkey und -rsigner):
# openssl ocsp -port 2560 -text -sha256 \
-index index.txt \
-CA certs/ca-chain.cert.pem \
-rkey private/ocsp.thebc.ch.key.pem \
-rsigner certs/ocsp.thebc.ch.cert.pem \
-nrequest 1
Ueber ein seperates Terminal/Session sende nun eine Anfrage zum "OSCP Server". Die Option "-cert" definiert
das Zertifikat für die Ueberprüfung:
# openssl ocsp -CAfile intermediate/certs/ca-chain.cert.pem \
-url http://localhost:2560 -resp_text \
-issuer certs/intermediate.cert.pem \
-cert certs/test.example.com.cert.pem
Der "output" zu Beginn der Anfrage sieht folgendermassen aus:
• ob eine Anfrage erfolgreich erhalten wurde (OCSP Response Status)
• die Identität des "responder" (Responder Id)
• der "revoke" Status des Zertifikates für die Ueberprüfung (Cert Status)
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: ... CN = ocsp.example.com
Produced At: Apr 11 12:59:51 2015 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334
Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9
Serial Number: 1003
Cert Status: good
This Update: Apr 11 12:59:51 2015 GMT
Nun führe für das Zertifikat einen "revoke" aus:
# openssl ca -config TheBC-CA.conf -revoke certs/<CERT>.cert.pem
Nun führe wiederum in einem seperaten Terminal/Session eine Ueberprüfung durch und diesesmal
zeigt der "output" des Zertifikat Status "revoke"sowie die "revoke time":
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: ... CN = ocsp.example.com
Produced At: Apr 11 13:03:00 2015 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334
Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9
Serial Number: 1003
Cert Status: revoked
Revocation Time: Apr 11 13:01:09 2015 GMT
This Update: Apr 11 13:03:00 2015 GMT
Für diese Dokumentation wurden folgenden Referenzen benutzt:
• https://jamielinux.com/docs/openssl-certificate-authority/index.html • http://www.phildev.net/ssl/ • https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.2.pdf • https://calomel.org/nginx.html • http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling_responder • http://itigloo.com/security/generate-an-openssl-certificate-request-with-sha-256-signature/ • https://www.openssl.org/docs/apps/ • http://isrlabs.net/wordpress/?p=169