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" (CRL / OSCP)
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
"Server Seitig"
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".
"Client Seitig"
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 ungefä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 • Datei:Certificate Authority private.pdf
Root CA Zertifikate
Gibt es eine Möglichkeit "Root CA" Zertifikate manuell aus dem Internet runterzuladen?
Wenn man zB einen Device/Server hat der die Funktion der "Root CA" Zertifikate nicht beinhaltet kommt man unweigerlich zur Frage:
--> Kann man die Vertrauenswürdigen Stammzertifikate (Root CA) eine IE exportieren umd diese auf einem Device/Server zu importieren
Ein Bull Export bei Firefox sowie Internet Explorer/Windows ist nicht möglich. Was jedoch möglich ist wäre die "Root CA" von Mozilla aus deren Source runterzuladen. Dazu kann unter Linux ein Perl Script benutzt werden. Das Perl Script findet man unter:
https://raw.githubusercontent.com/bagder/curl/master/lib/mk-ca-bundle.pl
Das Script löst zwei Probleme dh. auf der einen Seite laded diese Script aus dem Mozilla Root CA Tree diese runter jedoch in Clear-Text. Diese Clear-Text File/Informtionen werden als PEM File umkonvertiert und in ein seperates File abgespeichert. Führ dazu folgendes aus:
# mkdir /root/mk-ca-bundle
# cp mk-ca-bundle.pl /root/mk-ca-bundle/
# chmod 700 /root/mk-ca-bundle/mk-ca-bundle.pl
# /root/mk-ca-bundle/mk-ca-bundle.pl -v -d release -p ALL:ALL
Warning: Use of this script may pose some risk, -d risk for more details.
SHA1 of old file: 0
Downloading 'certdata.txt' ...
Get certdata over HTTPS with curl!
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1674k 100 1674k 0 0 402k 0 0:00:04 0:00:04 --:--:-- 809k
curl: unknown --write-out variable: 'response_code'
Failed downloading HTTPS with curl, trying HTTP with LWP
SHA1 of new file: ed3c0bbfb7912bcc00cd2033b0cb85c98d10559c
Processing 'certdata.txt' ...
Parsing: Equifax Secure CA
Parsing: Digital Signature Trust Co. Global CA 1
Parsing: Digital Signature Trust Co. Global CA 3
Parsing: Verisign Class 3 Public Primary Certification Authority
Parsing: Verisign Class 1 Public Primary Certification Authority - G2
Parsing: Verisign Class 2 Public Primary Certification Authority - G2
Parsing: Verisign Class 3 Public Primary Certification Authority - G2
Parsing: GlobalSign Root CA
Parsing: GlobalSign Root CA - R2
Parsing: Verisign Class 1 Public Primary Certification Authority - G3
Parsing: Verisign Class 2 Public Primary Certification Authority - G3
Parsing: Verisign Class 3 Public Primary Certification Authority - G3
Parsing: Verisign Class 4 Public Primary Certification Authority - G3
Parsing: Entrust.net Premium 2048 Secure Server CA
Parsing: Baltimore CyberTrust Root
Parsing: Equifax Secure Global eBusiness CA
Parsing: Equifax Secure eBusiness CA 1
Parsing: AddTrust Low-Value Services Root
Parsing: AddTrust External Root
Parsing: AddTrust Public Services Root
Parsing: AddTrust Qualified Certificates Root
Parsing: Entrust Root Certification Authority
Parsing: RSA Security 2048 v3
Parsing: GeoTrust Global CA
Parsing: GeoTrust Global CA 2
Parsing: GeoTrust Universal CA
Parsing: GeoTrust Universal CA 2
Parsing: UTN-USER First-Network Applications
Parsing: Visa eCommerce Root
Parsing: Certum Root CA
Parsing: Comodo AAA Services root
Parsing: Comodo Secure Services root
Parsing: Comodo Trusted Services root
Parsing: QuoVadis Root CA
Parsing: QuoVadis Root CA 2
Parsing: QuoVadis Root CA 3
Parsing: Security Communication Root CA
Parsing: Sonera Class 1 Root CA
Parsing: Sonera Class 2 Root CA
Parsing: Staat der Nederlanden Root CA
Parsing: UTN DATACorp SGC Root CA
Parsing: UTN USERFirst Email Root CA
Parsing: UTN USERFirst Hardware Root CA
Parsing: UTN USERFirst Object Root CA
Parsing: Camerfirma Chambers of Commerce Root
Parsing: Camerfirma Global Chambersign Root
Parsing: NetLock Qualified (Class QA) Root
Parsing: NetLock Notary (Class A) Root
Parsing: NetLock Business (Class B) Root
Parsing: NetLock Express (Class C) Root
Parsing: XRamp Global CA Root
Parsing: Go Daddy Class 2 CA
Parsing: Starfield Class 2 CA
Parsing: StartCom Certification Authority
Parsing: Taiwan GRCA
Parsing: Swisscom Root CA 1
Parsing: DigiCert Assured ID Root CA
Parsing: DigiCert Global Root CA
Parsing: DigiCert High Assurance EV Root CA
Parsing: Certplus Class 2 Primary CA
Parsing: DST Root CA X3
Parsing: DST ACES CA X6
Parsing: TURKTRUST Certificate Services Provider Root 1
Parsing: TURKTRUST Certificate Services Provider Root 2
Parsing: SwissSign Platinum CA - G2
Parsing: SwissSign Gold CA - G2
Parsing: SwissSign Silver CA - G2
Parsing: GeoTrust Primary Certification Authority
Parsing: thawte Primary Root CA
Parsing: VeriSign Class 3 Public Primary Certification Authority - G5
Parsing: SecureTrust CA
Parsing: Secure Global CA
Parsing: COMODO Certification Authority
Parsing: Network Solutions Certificate Authority
Parsing: WellsSecure Public Root Certificate Authority
Parsing: COMODO ECC Certification Authority
Parsing: MD5 Collisions Forged Rogue CA 25c3
Parsing: IGC/A
Parsing: Security Communication EV RootCA1
Parsing: OISTE WISeKey Global Root GA CA
Parsing: S-TRUST Authentication and Encryption Root CA 2005 PN
Parsing: Microsec e-Szigno Root CA
Parsing: Certigna
Parsing: AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.
Parsing: TC TrustCenter Class 2 CA II
Parsing: TC TrustCenter Class 3 CA II
Parsing: TC TrustCenter Universal CA I
Parsing: Deutsche Telekom Root CA 2
Parsing: ComSign CA
Parsing: ComSign Secured CA
Parsing: Cybertrust Global Root
Parsing: ePKI Root Certification Authority
Parsing: T\xc3\x9c\x42\xC4\xB0TAK UEKAE K\xC3\xB6k Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1 - S\xC3\xBCr\xC3\xBCm 3
Parsing: Buypass Class 2 CA 1
Parsing: Buypass Class 3 CA 1
Parsing: EBG Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1
Parsing: certSIGN ROOT CA
Parsing: CNNIC ROOT
Parsing: ApplicationCA - Japanese Government
Parsing: GeoTrust Primary Certification Authority - G3
Parsing: thawte Primary Root CA - G2
Parsing: thawte Primary Root CA - G3
Parsing: GeoTrust Primary Certification Authority - G2
Parsing: VeriSign Universal Root Certification Authority
Parsing: VeriSign Class 3 Public Primary Certification Authority - G4
Parsing: NetLock Arany (Class Gold) Főtanúsítvány
Parsing: Staat der Nederlanden Root CA - G2
Parsing: CA Disig
Parsing: Juur-SK
Parsing: Hongkong Post Root CA 1
Parsing: SecureSign RootCA11
Parsing: ACEDICOM Root
Parsing: Verisign Class 1 Public Primary Certification Authority
Parsing: Verisign Class 3 Public Primary Certification Authority
Parsing: Microsec e-Szigno Root CA 2009
Parsing: GlobalSign Root CA - R3
Parsing: TC TrustCenter Universal CA III
Parsing: Autoridad de Certificacion Firmaprofesional CIF A62634068
Parsing: Izenpe.com
Parsing: Chambers of Commerce Root - 2008
Parsing: Global Chambersign Root - 2008
Parsing: Bogus Mozilla Addons
Parsing: Bogus Global Trustee
Parsing: Bogus GMail
Parsing: Bogus Google
Parsing: Bogus Skype
Parsing: Bogus Yahoo 1
Parsing: Bogus Yahoo 2
Parsing: Bogus Yahoo 3
Parsing: Bogus live.com
Parsing: Go Daddy Root Certificate Authority - G2
Parsing: Starfield Root Certificate Authority - G2
Parsing: Starfield Services Root Certificate Authority - G2
Parsing: AffirmTrust Commercial
Parsing: AffirmTrust Networking
Parsing: AffirmTrust Premium
Parsing: AffirmTrust Premium ECC
Parsing: Certum Trusted Network CA
Parsing: Certinomis - Autorité Racine
Parsing: Root CA Generalitat Valenciana
Parsing: A-Trust-nQual-03
Parsing: TWCA Root Certification Authority
Parsing: Explicitly Distrust DigiNotar Root CA
Parsing: Explicitly Distrust DigiNotar Services 1024 CA
Parsing: Explicitly Distrust DigiNotar Cyber CA
Parsing: Explicitly Distrust DigiNotar Cyber CA 2nd
Parsing: Explicitly Distrusted DigiNotar PKIoverheid
Parsing: Explicitly Distrusted DigiNotar PKIoverheid G2
Parsing: Explicitly Distrusted Malaysian Digicert Sdn. Bhd. (cyb)
Parsing: Explicitly Distrusted Malaysian Digicert Sdn. Bhd. (en)
Parsing: Security Communication RootCA2
Parsing: EC-ACC
Parsing: Hellenic Academic and Research Institutions RootCA 2011
Parsing: Actalis Authentication Root CA
Parsing: Trustis FPS Root CA
Parsing: StartCom Certification Authority
Parsing: StartCom Certification Authority G2
Parsing: Buypass Class 2 Root CA
Parsing: Buypass Class 3 Root CA
Parsing: T-TeleSec GlobalRoot Class 3
Parsing: EE Certification Centre Root CA
Parsing: TURKTRUST Certificate Services Provider Root 2007
Parsing: D-TRUST Root Class 3 CA 2 2009
Parsing: D-TRUST Root Class 3 CA 2 EV 2009
Parsing: PSCProcert
Parsing: China Internet Network Information Center EV Certificates Root
Parsing: Swisscom Root CA 2
Parsing: Swisscom Root EV CA 2
Parsing: CA Disig Root R1
Parsing: CA Disig Root R2
Parsing: SG TRUST SERVICES RACINE
Parsing: ACCVRAIZ1
Parsing: TWCA Global Root CA
Parsing: TeliaSonera Root CA v1
Parsing: E-Tugra Certification Authority
Parsing: T-TeleSec GlobalRoot Class 2
Parsing: Atos TrustedRoot 2011
Parsing: QuoVadis Root CA 1 G3
Parsing: QuoVadis Root CA 2 G3
Parsing: QuoVadis Root CA 3 G3
Parsing: DigiCert Assured ID Root G2
Parsing: DigiCert Assured ID Root G3
Parsing: DigiCert Global Root G2
Parsing: DigiCert Global Root G3
Parsing: DigiCert Trusted Root G4
Parsing: WoSign
Parsing: WoSign China
Parsing: COMODO RSA Certification Authority
Parsing: USERTrust RSA Certification Authority
Parsing: USERTrust ECC Certification Authority
Parsing: GlobalSign ECC Root CA - R4
Parsing: GlobalSign ECC Root CA - R5
Parsing: USERTrust-temporary-intermediate-after-1024bit-removal
Parsing: VeriSign-C3SSA-G2-temporary-intermediate-after-1024bit-removal
Parsing: Staat der Nederlanden Root CA - G3
Parsing: Staat der Nederlanden EV Root CA
Parsing: IdenTrust Commercial Root CA 1
Parsing: IdenTrust Public Sector Root CA 1
Parsing: S-TRUST Universal Root CA
Parsing: Entrust Root Certification Authority - G2
Parsing: Entrust Root Certification Authority - EC1
Parsing: CFCA EV ROOT
Parsing: Explicitly Distrusted MCSHOLDING CA
Done (203 CA certs processed, 0 skipped).
Durch diesen Vorgang werden zwei Files erstellt dh. eines in Clear-Text und eines im PEM Format:
# ls -lha
total 2.0M
drwxr-xr-x 2 root root 4.0K Aug 14 13:10 .
drwxr-x--- 36 root root 4.0K Aug 14 13:08 ..
-rw-r--r-- 1 root root 333K Aug 14 13:10 ca-bundle.crt
-rw-r--r-- 1 root root 1.7M Aug 14 13:10 certdata.txt
-rwx------ 1 root root 18K Aug 14 13:10 mk-ca-bundle.pl
Nachfolgend ein Beispiel der Files:
Datei:Ca-bundle.crt Datei:Certdata.txt Datei:Mk-ca-bundle.txt
Nun würde man die einzelnen Sektionen zB auf einer FortiGate importieren hätte man die "Root CA" auf einer FortiGate zur Verfügung die normalerweise nicht zur Verfügung steht. Natürlich ist diese im heutigen Zeitpunkt sowie zukünftig ein manueller Vorgang. Wenn dies durchgeführt werden möchte auf einer FortiGate führe folgendes aus:
Import des Root CA "Equifax Secure CA"
Im File "ca-bundle.crt" ist folgender Abschnitt vorhanden:-
--------------- ca-bundle.crt ---------------
Equifax Secure CA
=================
-----BEGIN CERTIFICATE-----
MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTk4MDgyMjE2NDE1MVoXDTE4MDgyMjE2NDE1MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoT
B0VxdWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPR
fM6fBeC4AfBONOziipUEZKzxa1NfBbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+AcJkVV5MW
8Q+XarfCaCMczE1ZMKxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kCAwEAAaOCAQkwggEFMHAG
A1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UE
CxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoG
A1UdEAQTMBGBDzIwMTgwODIyMTY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvS
spXXR9gjIBBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQFMAMB
Af8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUAA4GBAFjOKer89961
zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJXRmm/kEd5jhW6Y7qj/WsjTVbJmcVfewCHrPSqnI0kB
BIZCe/zuf6IWUrVnZ9NA2zsmWLIodz2uFHdh1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee95
70+sB3c4
-----END CERTIFICATE-----
--------------- ca-bundle.crt ---------------
Um das entsprechende Zertifikat zu importieren muss der Name entfernt werden dh.
es darf für die Option "ca" im späteren Kommando nur das effektive Zertifikat
definiert werden. Dies bedeutet ebenfalls:
würde man im File "ca-bundle.crt" "alle" Zertifikats Namen/Bezeichnungen also
"Equifax Secure CA" und die Zeichen "=================" entfernen sowie die
Informationen am Anfang des Files könnten man das File über das WebGui unter
"Certificate CA" direkt auf einmal importieren. Beim Import wird Vorausgesetzt
das im PEM File ausschliesslich folgende Informationen vorhanden sind:
-----BEGIN CERTIFICATE-----
MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTk4MDgyMjE2NDE1MVoXDTE4MDgyMjE2NDE1MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoT
B0VxdWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPR
fM6fBeC4AfBONOziipUEZKzxa1NfBbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+AcJkVV5MW
8Q+XarfCaCMczE1ZMKxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kCAwEAAaOCAQkwggEFMHAG
A1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UE
CxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoG
A1UdEAQTMBGBDzIwMTgwODIyMTY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvS
spXXR9gjIBBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQFMAMB
Af8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUAA4GBAFjOKer89961
zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJXRmm/kEd5jhW6Y7qj/WsjTVbJmcVfewCHrPSqnI0kB
BIZCe/zuf6IWUrVnZ9NA2zsmWLIodz2uFHdh1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee95
70+sB3c4
-----END CERTIFICATE-----
Es dürfen somit kein zusätzliche Informationen vorhanden sein ansonsten wird
der Import verhindert/abgebrochen! Um nun über Kommandozeile das Zertifikat
"Equifax Secure CA" auf einer FortiGate zu importieren führen folgendes aus:
# config vpn certificate ca
# edit "Equifax Secure CA"
# set ca "-----BEGIN CERTIFICATE-----
MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTk4MDgyMjE2NDE1MVoXDTE4MDgyMjE2NDE1MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoT
B0VxdWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPR
fM6fBeC4AfBONOziipUEZKzxa1NfBbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+AcJkVV5MW
8Q+XarfCaCMczE1ZMKxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kCAwEAAaOCAQkwggEFMHAG
A1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UE
CxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoG
A1UdEAQTMBGBDzIwMTgwODIyMTY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvS
spXXR9gjIBBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQFMAMB
Af8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUAA4GBAFjOKer89961
zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJXRmm/kEd5jhW6Y7qj/WsjTVbJmcVfewCHrPSqnI0kB
BIZCe/zuf6IWUrVnZ9NA2zsmWLIodz2uFHdh1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee95
70+sB3c4
-----END CERTIFICATE-----"
# end
Danach ist das Zertifikat über das WebGui unter folgender Position
ersichtlich:
Config > System > Certificates
NOTE Wird das Zertifikat eingespielt werden VPN-SSL sowie IPSec Services im
Hintergrund neu gestartet und bestehende Verbindungen unterbrochen!
Würde man davon ausgehen, dass "alle" Root CA's auf einer FortiGate importiert wurden muss das "Deep Inspection" Profile entsprechend konfiguriert werden:
# config firewall ssl-ssh-profile
# edit [Name des entsprechenden Profiles]
# config https
# set allow-invalid-server-cert disable
# set ssl-ca-list enable
# end
# end
Nun wird jedes Zertifikat betreffend "Root CA" überprüft. Bedenke: Diese Liste benötigt "maitenance" dh. "Root CA" werden immer wieder auf den neusten Stand gebracht dh. dieser Vorgang ist auf einer FortiGate Manuell durchzuführen.
TSL Version
TLS Version 1.3
Das kurz vor der Verabschiedung stehende Verschlüsselungsprotokoll TLS 1.3 könnte sich als grosser Wurf erweisen. Denn anders als bei den Vorgängerversionen, deren Einführung sich über viele Jahre hinzog, bringt eine möglichst schnell Umstellung konkrete Vorteile in Bezug auf Sicherheit und Performance. Das nachfolgende Dokumente geht auf diese Vorteile und Sicherheits-Aspekte ein:
Datei:Weniger-ist-mehr-TLS-1.3.pdf