In diesem Artikel wird erklärt, wie Sie Zertifikate verwenden, die von einer externen Zertifizierungsstelle (CA) wie Let's Encrypt, Comodo, Symantec, Digicert usw. ausgestellt wurden. Außerdem wird erläutert, wie Zertifikate im Allgemeinen funktionieren.
Zusammenfassung
Die Zertifikate dienen zwei Hauptzwecken: Die Kommunikation zwischen zwei Entitäten zu verschlüsseln und die Authentizität der Entität zu bestätigen. Ersteres kann durch ein sogenanntes selbstsigniertes Zertifikat gewährt werden, aber um die Entität zu authentifizieren, benötigen Sie ein global vertrauenswürdiges Zertifikat, das von einer Root- oder Zwischen-CA ausgestellt wird. In diesem Artikel erfahren Sie, wie Zertifikate diese Authentifizierung im Allgemeinen erreichen, wie Sie das Format des Zertifikats ändern, damit es mit anderen Geräten, einschließlich unserer Firewalls, funktioniert, wie Sie das Zertifikat in Ihre Firewall importieren und wie Zertifikate behandelt werden sollten, um Sicherheitsrisiken zu vermeiden.
Inhaltsverzeichnis
- Wie funktioniert ein Zertifikat?
- Selbstsignierte Zertifikate
- Arbeiten mit Zertifikaten
- Importieren von Zertifikaten in USG/ATP-Firewalls
- Zertifikatssicherheit
Wie funktioniert ein Zertifikat?
Jedes Zertifikat besteht aus zwei Teilen: dem Zertifikat (auch öffentlicher Schlüssel genannt) und dem privaten Schlüssel. Das Zertifikat kann öffentlich geteilt werden und enthält lediglich Informationen zu den Zwecken, für die das Zertifikat ausgestellt wurde und für welche Entität das Zertifikat ausgestellt wurde - dies kann Ihr FQDN, Ihre E-Mail-Adresse oder ein anderer Wert sein.
Zertifikate haben eine begrenzte Gültigkeitsdauer - das hilft in Situationen, in denen nach Jahrzehnten ein altes Zertifikat mit einem privaten Schlüssel irgendwo ausgegraben wird. Wenn die Gültigkeit unendlich wäre, könnte das Zertifikat immer noch von jedem, der es in die Hände bekommt, für böswillige Zwecke verwendet werden. Ab 2021 wird empfohlen, keine Gültigkeitsdauer von mehr als einem Jahr zu verwenden. Mit dem Aufkommen automatischer Neuausstellungsmechanismen wie CertBot kann dieser Zeitraum viel kürzer werden, um die Sicherheit weiter zu verbessern.
Zertifikate können widerrufen werden, falls der private Schlüssel durchgesickert ist – und als Vorsichtsmaßnahme sollte jeder Sicherheitsverletzung, die kompromittierte Hardware mit privaten Schlüsseln enthält, ein Widerruf des Zertifikats und die anschließende Neuausstellung neuer Zertifikate folgen.
Zertifikate können an verschiedene Entitäten ausgestellt werden, wie z. B. FQDN, E-Mail, sogar IP-Adresse oder Vorname. Obwohl es technisch möglich ist, Wildcard-FQDN-Zertifikate zu haben und diese von Benutzern oft bevorzugt werden, denken Sie daran, dass im Falle eines privaten Schlüsselverlusts von einem bestimmten Dienst das Wildcard-Zertifikat den gesamten FQDN authentifiziert - als Folge davon ist ein Leck der privater Schlüssel auf einem Webserver, der der reinen Firmenpräsentation dient, kann auch für MITM-Angriffe zwischen Exchange-Server oder CRM-System verwendet werden. Die Unabhängigkeit der Zertifikate für jede Subdomain trägt dazu bei, die Auswirkungen des Lecks zu mindern, bis das Zertifikat widerrufen wird.
Es ist zwar auch möglich, Zertifikate an IP-Adressen auszustellen, dies ist jedoch veraltet. Der Grund dafür ist, dass die IPs im Vergleich zum FQDN leicht geändert werden können.
Das Grundprinzip von Zertifikaten ist ziemlich einfach. In einem Beispiel möchte Alice auf Bobs Server zugreifen, aber das Problem ist, dass sie nie dort war, sodass sie nie ein gemeinsames Geheimnis austauschen konnten, um sich zu authentifizieren. Wie kann Alice sicher sein, dass sie sich tatsächlich mit Bob verbindet? Hier kommt Charlie ins Spiel. Alice kennt Charlie und hat sein Zertifikat dem Stammzertifikats-Repository hinzugefügt. Daher betrachtet Alice Charlie als vertrauenswürdige Einheit. Wenn Bob sein eigenes Zertifikat und seinen privaten Schlüssel von Charlie ausgestellt hat, kann er sich bei Alice authentifizieren und es spielt keine Rolle, dass Alice nie zuvor mit Bob in Kontakt war, denn Charlie vertraut Bob und da Alice Charlie vertraut, vertraut sie auch Bob . Dies ist eine sogenannte Vertrauenskette.
Werfen wir einen Blick auf die Chain of Trust für unser Support Campus Webzertifikat:
Beachten Sie, dass es auch eine andere Entität namens R3 gibt. Dies wird als Intermediate CA bezeichnet, während DST Root CA X3 Root CA ist. Das Zertifikat kann nur eine Stammzertifizierungsstelle haben, es können jedoch mehrere Zwischenzertifizierungsstellen vorhanden sein. Zwischenzertifizierungsstelle ist eine Entität, der die Erlaubnis erteilt wurde, Zertifikate für ihre Kunden auszustellen. Solange Ihr PC über das DST-Root-CA-X3-Zertifikat in der Liste der vertrauenswürdigen Stammzertifikate verfügt, wird support.zyxel.eu als vertrauenswürdig eingestuft.
Selbstsignierte Zertifikate
Standardmäßig verwenden unsere Firewalls (und viele andere Geräte) selbstsignierte Zertifikate, um eine verschlüsselte TLS-Verbindung herzustellen. Ein solches Zertifikat wird durch eine bekannte Fehlermeldung vom Browser gemeldet: 
Es gibt zwei Gründe, warum dies geschieht. Der erste Grund ist, dass das Zertifikat im Grunde ein Root-CA-Zertifikat ist, das in Ihrem System nicht vorhanden ist. Es reicht jedoch nicht aus, es einfach als Root-CA auf Ihrem Computer zu installieren, da das Zertifikat nicht für Ihre IP oder Domäne ausgestellt wird. Das Zertifikat ist jedoch für eine sichere Verbindung geeignet und seine Verwendung birgt kein Sicherheitsrisiko, solange sein privater Schlüssel nicht durchgesickert ist – das einzige Problem hierbei ist, dass die Identität nicht bestätigt werden kann.
Arbeiten mit Zertifikaten
Im Laufe der Jahre wurden viele Zertifikatsformate entwickelt. Die Zertifikate verwenden jedoch immer noch das gleiche Prinzip und alle Formate können in andere Formate konvertiert werden.
Zertifikatsformate
Das älteste Format wäre das PEM, das den ASCII-codierten Schlüssel enthält. Der Grund dafür ist die ursprüngliche Verwendung in verschlüsselten E-Mails, bei denen das Binärzertifikat falsch formatiert werden kann. PEMs sind in Unix-Systemen üblich und Ihre CA hat Ihnen wahrscheinlich ein Zertifikat zusammen mit einem privaten Schlüssel im PEM-Format geschickt. Verwendet normalerweise die Dateierweiterung .pem oder .cer.
DER ist eine binäre Form des ASCII-PEM-Formatzertifikats. Alle Arten von Zertifikaten und privaten Schlüsseln können im DER-Format codiert werden. Dieses Format unterstützt die Speicherung eines einzelnen Zertifikats und enthält keinen privaten Schlüssel für die Zwischen-/Stammzertifizierungsstelle. Sie haben die Erweiterung .der oder .cer und werden am häufigsten auf Java-Plattformen verwendet.
PKCS#7 ist ein binäres Format, das es ermöglicht, Zertifikate oder die gesamte Zertifikatskette des Vertrauens in einer einzigen Datei zu enthalten. In diesem Format kann jedoch kein privater Schlüssel gespeichert werden. Dieses Format wird am häufigsten von Zertifizierungsstellen verwendet, um eine vollständige Vertrauenskette bereitzustellen. Verwendet die Erweiterung .p7b.
PKCS#12, auch bekannt als PFX, ist ein Format, das die gesamte Vertrauenskette und den privaten Schlüssel enthalten kann. Normalerweise wird dieses Format von CAs bereitgestellt, da es durch ein Passwort gesichert werden kann. Verwendet normalerweise die Erweiterung .p12 oder .pfx.
Zertifikatstools
Windows verfügt über ein integriertes System-CLI-Dienstprogramm certutil, das zum Konvertieren von Zertifikaten verwendet werden kann. Management-Plugins in der Microsoft Management Console ermöglichen auch die Verwaltung von Zertifikaten.
Das Open-Source-Dienstprogramm OpenSSL kann auch Zertifikate verarbeiten und konvertieren. Binärdateien sind für Windows, Linux und macOS (und viele andere Plattformen) verfügbar.
Nützliche certutil-Befehle:
Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.
Nützliche OpenSSL-Befehle:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Zertifikat in USG/ATP-Firewalls importieren
Das aktuelle Design (Stand Juni 2021) beschränkt sich auf den Import von Zertifikaten ohne Zwischenschlüssel. Sollte das Zertifikat einen Zwischenschlüssel enthalten, wird die Datei falsch geparst und der Versuch, ein solches Zertifikat zu verwenden, kann dazu führen, dass Dienste nicht verfügbar sind (z. B. WebGUI). Es ist eine gute Idee, das Zertifikat im .pem-Format zu erhalten und es mit certutil oder OpenSSL in das .pfx-Format zu exportieren. Das Zertifikat kann zusammen mit seinem Passwort im folgenden Menü importiert werden:
Configuration > Objects > Certificates > My Certificates
Zertifikatssicherheit
Jedes Zertifikat hat seinen jeweiligen privaten Schlüssel. Während es sich bei einem Zertifikat um öffentliche Informationen handelt, muss der private Schlüssel als Geheimnis behandelt werden – und sollte von niemandem geteilt werden. Nicht einmal bei uns bei Zyxel - der einzig gültige Weg ist die Verwendung von Remote-Assistance-Tools wie TeamViewer. Wenn Sie den privaten Schlüssel im PEM-Format speichern, überprüfen Sie die Berechtigungen für den Zugriff auf den privaten Schlüssel, um dessen Verlust zu verhindern. Verwenden Sie immer die Passwortverschlüsselung im pfx-Format, um beim Exportieren von Zertifikaten zumindest ein gewisses Maß an Sicherheit zu gewährleisten. Alle Zertifikate mit dem durchgesickerten privaten Schlüssel sollten sofort widerrufen werden.
HAFTUNGSAUSSCHLUSS:
Sehr geehrter Kunde, bitte beachten Sie, dass wir maschinelle Übersetzung verwenden, um Artikel in Ihrer Landessprache bereitzustellen. Möglicherweise werden nicht alle Texte korrekt übersetzt. Bei Fragen oder Unstimmigkeiten zur Richtigkeit der Informationen in der übersetzten Version lesen Sie bitte den Originalartikel hier: Originalversion