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)

Certificate revocation lists A certificate revocation list (CRL) contains information about which certificates have been revoked. A CRL can be used by a client application, suchas a web browser, to check a server’s authenticity. A CRL can also be used by a server application, such as Apache or OpenVPN, to deny access to clients that are no longer trusted.

A CRL is normally published at a publicly accessible location. Third-parties can fetch the CRLfrom this location to check whether any certificates they rely on have been revoked.

Note: Some applications vendors have deprecated CRLs and are instead using the Online Certificate Status Protocol (OCSP).

Prepare the configuration file A certificate authority normally encodes the CRL location into certificates that it signs. Add crlDistributionPoints to the appropriate sections, which usually means the [ server_cert ] section.

[ server_cert ]

1. ... snipped ...

crlDistributionPoints = URI:http://crl.thebc.ch/TheBC-CA.crl.pem

Create the CRL

1. cd /root/ca
2. echo 01 > crl/crl.number
3. openssl ca -config TheBC-CA.conf -gencrl -out crl/TheBC-CA.crl.pem

Note: The CRL OPTIONS section of the `man ca` page contains more informationon how to create CRLs.

View the CRL

1. openssl crl -in crl/ca.crl.pem -noout -text

No certificates have been revoked yet, so the output will state No Revoked Certificates.

The CRL is usually re-created at regular intervals. By default, the CRL expires after 30 days. This is controlled by the default_crl_days option in the [ CA_default ] section.

Revoke a certificate REVOKE: # openssl ca -config TheBC-CA.conf -revoke cert s/bob@example.com.cert.pem REBUILD CRL: # openssl ca -config TheBC-CA.conf -gencrl -out crl/ca.crl.pem

Server-side use of the CRL For client certificates, it’s typically a server-side application (eg, Apache) that is doing the verification. This application needs to have local access to the CRL. In Alice’s case, she can add the SSLCARevocationPath directive to her Apache configuration and copy the CRL to her web server. The next time that Bob connects to the web server, Apache will check his client certificate against the CRL and deny access. Similarly, OpenVPN has a crl-verify directive so that it can block clients that have had their certificates revoked.

Client-side use of the CRL For server certificates, it’s typically a client-side application (eg, web browser) that is doing the verification. This application needs to have remote access to the CRL. When signing a certificate with an extension that includes crlDistributionPoints, the certificate will contain a reference to the location specified. The application can read this information and fetch the CRL.

Online Certificate Status Protocol (OCSP) The Online Certificate Status Protocol (OCSP) was created as an alternative to certificate revocation lists (CRLs). Similar to CRLs, OCSP enables a requesting party (eg, web browser or webserver) to determine the revocation state of a certificate. When a CA signs a certificate, they will typically include an OCSP server address (eg, http://ocsp.thebc.ch) in the certificate. This is similar in function to crlDistributionPoints used for CRLs. As an example, when a web browser is presented with a server certificate, it will send a query to the OCSP server address specified in the certificate. At this address, an OCSP responder listens to queries and responds with the revocation status of the certificate.

Note: It’s recommended to use OCSP instead where possible, though realistically you will tend to only need OCSP for website certificates. Some web browsers have deprecated or removed support for CRLs.

Prepare the configuration file To use OCSP, the CA must encode the OCSP server location into the certificates that it signs. Use the authorityInfoAccess option in the appropriate sections, which in our case means the [ server_cert ] section.

[ server_cert ]

1. ... snipped ...

authorityInfoAccess = OCSP;URI:http://ocsp.thebc.ch:8888

Create a new stanza

[ v3_OCSP ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = OCSPSigning

Create the OCSP pair The OCSP responder requires a cryptographic pair for signing the response that it sends to the requesting party. The OCSP cryptographic pair must be signed by the same CA that signed the certificate being checked.

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

This shows something like this:

	X509v3 Key Usage: critical

	Digital Signature
	X509v3 Extended Key Usage: critical
	OCSP Signing

Revoke a certificate The OpenSSL ocsp tool can act as an OCSP responder, but it’s only intended for testing. Production ready OCSP responders exist, but those are beyond the scope of this guide.

1. Create a server certificate to test. 2. Run the OCSP responder on localhost. Rather than storing revocation statusin a separate CRL file, the OCSP responder reads index.txt directly. Theresponse is signed with the OCSP cryptographic pair (using the -rkey and -rsigner options).

1. 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

In another terminal, send a query to the OCSP responder. The -cert option specifies the certificate to query.

1. 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

The start of the output shows: • whether a successful response was received (OCSP Response Status) • the identity of the responder (Responder Id) • the revocation status of the certificate (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

Revoke the certificate.

openssl ca -config TheBC-CA.conf -revoke certs/<CERT>.cert.pem

As before, run the OCSP responder and on another terminal send a query. Thistime, the output shows Cert Status: revoked and a Revocation 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

TODO: OCSP Responder behind ngix <VirtualHost x.x.x.x:80> ServerName ocsp.cacert.org DocumentRoot /dev/null RewriteEngine on RewriteCond %{CONTENT_TYPE} !^application/ocsp-request$ RewriteRule ^/(.*) http://localhost:2560/ [P] CustomLog /var/log/apache/ocsp.cacert.org-access.log combined ErrorLog /var/log/apache/ocsp.cacert.org-error.log </VirtualHost>

References • 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

CheetSheet Create Server Certificate KEY: # openssl genpkey -out private/<hostname>.key.pem -algorithm RSA -pkeyopt rsa_keygen_bits:4096 CSR: # openssl req -config TheBC-CA.conf -key private/<hostname>.key.pem -new -out csr/ <hostname>.csr.pem SIGN: # openssl ca -config TheBC-CA.conf -extensions v3_OCSP -in csr/<hostname>.csr.pem -out certs/ <hostname>.cert.pem CHECK: # openssl x509 -noout -text -in certs/<hostname>.cert.pem

Possible Server Types: [v3_CA|v3_intermediate_ca|v3_OCSP|usr_cert|server_cert]

Revoke Certificate REVOKE: # openssl ca -config TheBC-CA.conf -revoke certs/<cert-name>.cert.pem REBUILD CRL: # openssl ca -config TheBC-CA.conf -gencrl -out crl/TheBC-CA.crl.pem