Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

SSL-Zertifikate

Die Firewall der SRX-Serie, die als SSL-Proxy fungiert, verwaltet SSL-Verbindungen zwischen dem Client an einem Ende und dem Server am anderen Ende. SSL-Proxyserver sorgt für eine sichere Datenübertragung mit Verschlüsselungstechnologie. SSL basiert auf Zertifikaten und privat-öffentlichen Schlüsselaustauschpaaren, um die sichere Kommunikation zu gewährleisten. In diesem Thema erfahren Sie, wie Sie EIN SSL-Zertifikat für SSL-Verbindungen auf Ihrem Sicherheitsgerät generieren und installieren.

Konfigurieren und Laden von SSL-Zertifikaten

Abbildung 1 zeigt eine Übersicht über die Konfiguration des SSL-Proxys. Die Konfiguration von SSL-Proxy umfasst:

  • Konfigurieren des Ca-Stammzertifikats

  • Laden einer CA-Profilgruppe

  • Konfigurieren des SSL-Proxyprofils und zuordnen des Stamm-CA-Zertifikats und der CA-Profilgruppe

  • Anwenden eines SSL-Proxyprofils auf eine Sicherheitsrichtlinie

Abbildung 1: Übersicht über SSL Proxy Configuration Overview die SSL-Proxykonfiguration

Lassen Sie uns diese Prozeduren in den folgenden Abschnitten im Detail besprechen:

Konfigurieren eines CA-Root-Zertifikats

Eine Zertifizierungsstelle kann mehrere Zertifikate in Form einer Baumstruktur ausstellen. Ein Stammzertifikat ist das oberste Zertifikat der Struktur, dessen privater Schlüssel für sign andere Zertifikate verwendet wird. Alle Zertifikate, die direkt unter dem Stammzertifikat liegen, erben die Signatur oder Vertrauenswürdigkeit des Stammzertifikats. Das ist ein bisschen wie eine notarizing Identität.

Zum Konfigurieren eines CA-Root-Zertifikats müssen Sie

  1. Gewinnung eines CA-Root-Zertifikats (durch entweder oder Import eines)

    • Sie können ein CA-Root-Zertifikat mit junos OS CLI auf einer Firewall der SRX-Serie generieren.

    • Abrufen eines Zertifikats von einer externen Zertifizierungsstelle (nicht in diesem Thema behandelt)

  2. Anwenden von Root-CA auf ein SSL-Proxyprofil.

Generieren Eines CA-Root-Zertifikats mit CLI

Um ein selbstsigniertes Zertifikat in CLI zu definieren, müssen Sie die folgenden Details angeben:

  • Zertifikatskennung (im vorherigen Schritt generiert)

  • Vollqualifizierter Domänenname (FQDN) für das Zertifikat

  • E-Mail-Adresse der Entität, die das Zertifikat besitzt

  • Gemeinsamer Name und die beteiligte Organisation

Generieren Sie mithilfe der Junos OS CLI ein CA-Stammzertifikat:

  1. Generieren Sie im Betriebsmodus ein PKI-Paar für öffentliche/private Schlüssel für ein lokales digitales Zertifikat.

    Beispiel:

  2. Definieren sie ein selbstsigniertes Zertifikat.

    Beispiel:

    Indem Sie die add-ca-constraint Option konfigurieren, stellen Sie sicher, dass das Zertifikat zum Signieren anderer Zertifikate verwendet werden kann.

  3. Wenden Sie das geladene Zertifikat im Konfigurationsmodus als root-ca im SSL-Proxyprofil an.

    Beispiel:

  4. Importieren Sie die Stammzertifizierungsstelle als vertrauenswürdige CA in Client-Browser. Dies ist erforderlich, damit die Client-Browser den von der Firewall der SRX-Serie signierten Zertifikaten vertrauenswürdig sind. Siehe Importieren eines CA-Root-Zertifikats in einen Browser.

Konfigurieren einer vertrauenswürdigen CA-Profilgruppe

Das CA-Profil definiert die Zertifikatsinformationen für die Authentifizierung. Es enthält den öffentlichen Schlüssel, den SSL-Proxy beim Generieren eines neuen Zertifikats verwendet. Junos OS ermöglicht es Ihnen, eine Gruppe von CA-Profilen zu erstellen und mehrere Zertifikate in einer Aktion zu laden, Informationen zu allen Zertifikaten in einer Gruppe anzuzeigen und unerwünschte Ca-Gruppen zu löschen. Wenn eine Verbindung hergestellt wird, prüft das verbindende Gerät (z. B. ein Webbrowser), ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde. Ohne diese Zertifikate können Browser die Identität der meisten Websites nicht überprüfen und als nicht vertrauenswürdige Websites kennzeichnen.

Die Konfiguration einer vertrauenswürdigen CA-Profilgruppe umfasst die folgenden Schritte:

  • Abrufen einer Liste vertrauenswürdiger CA-Zertifikate. Sie können vertrauenswürdige CA-Zertifikate mit einer der folgenden Methoden erhalten:

    • Junos OS stellt eine Standardliste vertrauenswürdiger CA-Zertifikate als PEM-Datei bereit (z. B. trusted_CA.pem). Nachdem Sie das Junos OS-Paket heruntergeladen haben, sind die Standardzertifikate auf Ihrem System verfügbar.

      Laden Sie im Betriebsmodus die standardmäßigen vertrauenswürdigen Zertifizierungsstellenzertifikate (der Gruppenname identifiziert die CA-Profilgruppe):

      Beispiel:

      Wir empfehlen die Verwendung dieser Methode.

    • Definieren Sie Ihre eigene Liste vertrauenswürdiger CA-Zertifikate und importieren Sie sie in Ihr System. Sie erhalten die Liste der vertrauenswürdigen CAs in einer einzigen PEM-Datei (z. B. IE-all.pem) und speichern die PEM-Datei an einem bestimmten Speicherort (z. B. /var/tmp). Siehe Knowledge Base-Artikel KB23144.

      Laden Sie aus dem Betriebsmodus die vertrauenswürdige Liste auf das Gerät (der Gruppenname identifiziert die CA-Profilgruppe):

      Beispiel:

    • Laden Sie die neueste CA-Paketliste von einem anderen Drittanbieter wie Mozilla (https://curl.haxx.se/docs/caextract.html) herunter. Die Liste der vertrauenswürdigen Zertifizierungsstelle kann sich im Laufe der Zeit ändern. Stellen Sie sicher, dass Sie das neueste CA-Paket verwenden.

    • Importieren Sie Ihre eigenen vertrauenswürdigen CA-Zertifikate mithilfe der Public Key Infrastructure (PKI). Die PKI hilft bei der Überprüfung und Authentifizierung der Gültigkeit der vertrauenswürdigen CA-Zertifikate. Sie erstellen CA-Profilgruppen, die vertrauenswürdige CA-Zertifikate enthalten, und importieren dann die Gruppe zur Serverauthentifizierung auf Ihrem Gerät.

  • Anfügen der CA-Gruppe an das SSL-Proxyprofil.

    • Fügen Sie alle CA-Profilgruppen an:

      Beispiel:

    • Fügen Sie eine CA-Profilgruppe an (der Gruppenname identifiziert die CA-Profilgruppe).

      Beispiel:

Sie können problemlos Informationen zu allen Zertifikaten in einer CA-Profilgruppe anzeigen:

Sie können eine CA-Profilgruppe löschen. Denken Sie daran, dass beim Löschen einer CA-Profilgruppe alle Zertifikate gelöscht werden, die zu dieser Gruppe gehören:

Was kommt als nächstes

Fahren Sie nun mit der KONFIGURATION des SSL-Proxyprofils fort und wenden Sie das SSL-Proxyprofil auf die Sicherheitsrichtlinie an. Siehe Konfigurieren von SSL-Proxy.

Importieren eines CA-Root-Zertifikats in einen Browser

Damit Ihr Browser oder System automatisch allen Zertifikaten vertraut, die von der Root-Zertifizierungsstelle im SSL-Proxyprofil konfiguriert sind, müssen Sie Ihre Plattform oder Ihren Browser anweisen, dem CA-Root-Zertifikat zu vertrauen.

So importieren Sie ein Ca-Zertifikat:

  1. Generieren Sie eine Datei im PEM-Format für die konfigurierte Stammzertifizierungsstelle.
  2. Importieren Eines Ca-Root-Zertifikats in einen Browser.

    Von Internet Explorer (Version 8.0):

    1. Wählen Sie im Menü Extras die Option Internetoptionen aus.
    2. Klicken Sie auf der Registerkarte Inhalt auf Zertifikate.
    3. Wählen Sie die Registerkarte Trusted Root Certification Authorities aus , und klicken Sie auf Importieren.
    4. Navigieren Sie im Zertifikatimportassistenten zu dem erforderlichen Ca-Stammzertifikat, und wählen Sie es aus.

    Von Firefox (Version 39.0):

    1. Wählen Sie im Menü Extras die Option Optionen aus.
    2. Wählen Sie im Menü Erweitert die Registerkarte Zertifikate aus, und klicken Sie auf Zertifikat anzeigen.
    3. Wählen Sie im Fenster "Certificate Manager" die Registerkarte "Behörden " aus, und klicken Sie auf "Importieren".
    4. Navigieren Sie zum erforderlichen Ca-Root-Zertifikat, und wählen Sie es aus.

    Von Google Chrome (45.0):

    1. Wählen Sie im Menü "Einstellungen " die Option "Erweiterte Einstellungen anzeigen".
    2. Wählen Sie im Menü Erweitert die Registerkarte Zertifikate aus, und klicken Sie auf Zertifikat anzeigen.
    3. Klicken Sie unter HTTPS/SSL auf Zertifikate verwalten.
    4. Wählen Sie im Zertifikatsfenster vertrauenswürdige Stammzertifizierungsstellen aus , und klicken Sie auf Importieren.
    5. Navigieren Sie im Zertifikatimportassistenten zu dem erforderlichen Ca-Stammzertifikat, und wählen Sie es aus.

Implementierung von Zertifikatsketten

Ab Junos OS Version 15.1X49-D30 unterstützt SSL-Weiterleitungs-Proxy die Implementierung der Zertifikatskette. Wir erläutern, wie Sie die Konzepte der Zertifikatskette verstehen und wie sie auf einer Firewall der SRX-Serie konfiguriert werden können.

  • Certificate Authority (CA)— CA ist ein vertrauenswürdiger Dritter, der für die Validierung der Identitäten von Entitäten (z. B. Websites, E-Mail-Adressen, Unternehmen oder Einzelpersonen) verantwortlich ist und stellt ein digitales Zertifikat durch Bindung kryptografischer Schlüssel aus. Wenn Ihr Unternehmen über einen CA-Server verfügt, werden Sie Ihre eigene CA und verwenden selbstsigniertes Zertifikat.

  • Root Certificate– Ein Root-Zertifikat ist ein Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt wird. Das Stammzertifikat ist das oberste Zertifikat der Struktur, dessen privater Schlüssel zum Signieren anderer Zertifikate verwendet wird. Alle Zertifikate, die direkt unter dem Stammzertifikat liegen, erben die Signatur oder Vertrauenswürdigkeit des Stammzertifikats. Diese Zertifikate werden verwendet, um eine Verbindung zwischen zwei Endgeräten herzustellen.

  • Intermediate CA Certificate– Ein zwischengeschaltetes CA-Zertifikat ist ein untergeordnetes Zertifikat, das vom vertrauenswürdigen Stamm speziell zur Validierung von Endentitätszertifikaten signiert wird.

  • Certificate Chain Eine Zertifikatskette ist die geordnete Liste der Zertifikate, die das SSL-Zertifikat, das Zwischenzertifikat und das Stammzertifikat enthalten. Einige Zertifizierungsstellen (Certificate Authorities, CAs) unterzeichnen nicht mit ihrem Stammzertifikat, sondern verwenden stattdessen ein Zwischenzertifikat. Eine Zwischenzertifizierungsstelle kann Zertifikate im Namen des Stammzertifizierungszertifikats signieren. Die Stammzertifizierungsstelle signiert das Zwischenzertifikat und bildet eine Vertrauenskette.

    Das Zwischenzertifikat muss auf demselben Server wie das SSL-Zertifikat installiert sein, damit das verbindende Gerät (Browser, Anwendungen, mobiles Gerät usw.) es vertrauen kann.

Wenn Sie eine Verbindung herstellen, überprüft das verbindende Gerät (z. B. ein Webbrowser), ob das Zertifikat authentisch ist und von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde, die in den Trusted Store des Browsers eingebettet ist.

Wenn das SSL-Zertifikat nicht von einer vertrauenswürdigen Zertifizierungsstelle stammt, überprüft das verbindende Gerät weiterhin, ob das SSL-Zertifikat von einer Zwischenzertifizierungsstelle ausgestellt wurde und diese Zwischenzertifizierungsstelle von einer Root-CA signiert wird. Die Prüfung wird fortgesetzt, bis die Stammzertifizierungsstelle gefunden ist. Wenn eine Root-CA gefunden wird, wird eine sichere Verbindung hergestellt. Wenn keine Stammzertifizierungsstelle gefunden wird, wird die Verbindung unterbrochen, und Ihr Webbrowser zeigt eine Fehlermeldung über ein ungültiges Zertifikat oder nicht vertrauenswürdiges Zertifikat an.

Dieses Beispiel zeigt, wie Sie die Zertifikatskette installieren, damit Browser Ihrem Zertifikat vertrauenswürdig sind.

Anforderungen

Vor der Konfiguration dieser Funktion ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.

Übersicht

In diesem Beispiel haben Sie eine Domäne, example.domain-1, und Sie möchten ein Zertifikat von XYZ-Authority für Ihre Domäne erwerben. XYZ -Authority ist jedoch keine Root-CA, und der besuchende Webbrowser vertraut nur root-CA-Zertifikat. Mit anderen Worten, das Zertifikat ist nicht direkt in Ihren Webbrowser eingebettet und daher nicht explizit vertrauenswürdig.

In diesem Fall wird die Vertrauenswürdigkeit wie folgt über die Zertifikatskette (der Zwischenzertifikate) hergestellt.

Topologie

Lassen Sie uns versuchen, diese Kette durch Abbildung 2 zu visualisieren. Das Bild zeigt eine vollständige Zertifikatskette, vom Stamm-CA-Zertifikat bis zum Endbenutzerzertifikat. Die Kette endet am Endbenutzerzertifikat.

Abbildung 2: Zertifizierungspfad vom Zertifikatsbesitzer zur Stammzertifizierungsstelle Certification Path from the Certificate Owner to the Root CA
Tabelle 1: Details zur Zertifikatsverkettung

Benutzer

Verwendet Das Zertifikat

Unterzeichnet von

Typ

beispiel.domain-1

Endbenutzerzertifikat

XYZ-Autorität

Endbenutzerzertifikat. Die, die Sie von der CA kaufen.

XYZ-Autorität

Zertifikat-1

Intermediate CA-1

Intermediate-Zertifikat

Intermediate CA-1

Zertifikat-2

Intermediate CA-2

Intermediate-Zertifikat

Intermediate CA-2

Zertifikat-3

Intermediate CA-3

Intermediate-Zertifikat

Intermediate CA-3

Zertifikat-4

Root-Example-Authority. Dies ist eine Root-CA.

Root-Zertifikat

Das Zertifikat ist direkt in Ihren Webbrowser eingebettet. daher kann es explizit vertrauenswürdig sein.

Wenn Sie Ihr Endbenutzerzertifikat für server example.domain-1 installieren, müssen Sie alle Zwischenzertifikate bündeln und zusammen mit Ihrem Endbenutzerzertifikat installieren. Die Zertifikatskette umfasst alle Zertifikate, die von Certificate-1 bis Root-CA-Zertifikat beginnen. Da der Webbrowser der Stammzertifizierungsstelle vertraut, vertraut er auch implizit allen Zwischenzertifikaten. Wenn die SSL-Zertifikatskette ungültig oder kaputt ist, wird Ihr Zertifikat von einigen Geräten nicht vertrauenswürdig.

Hinweis:
  • Alle Zertifikate müssen im PEM-Format (Privacy-Enhanced Mail) vorliegen.

  • Wenn Sie die verkettete Zertifikatsdatei in das Gerät importieren, stellt die Zertifizierungsstelle ein Bündel verketteter Zertifikate bereit, die dem signierten Serverzertifikat hinzugefügt werden müssen. Das Serverzertifikat muss vor den verketteten Zertifikaten in der kombinierten Datei angezeigt werden.

Konfiguration

Die Konfiguration der SSL-Zertifikatskette umfasst die folgenden Aufgaben:

  • Erwerben Sie ein SSL-Zertifikat von einer CA, das ein Signaturzertifikat und einen entsprechenden Schlüssel enthält.

  • Konfigurieren Sie eine vertrauenswürdige CA-Profilgruppe.

  • Laden Sie das Signaturzertifikat und den Schlüssel auf Ihr Gerät.

  • Laden Sie die Zwischen- und Root-CA im PKI-Speicher (Public Key Infrastructure). Diese Zertifikatsdatei enthält alle erforderlichen CA-Zertifikate nacheinander im PEM-Format.

  • Erstellen Sie ein vertrauenswürdiges CA-Profil für das Zwischen- oder Stammzertifizierungszertifikat.

  • Richten Sie Ihr Gerät so ein, dass das von der Zertifizierungsstelle erhaltene Signaturzertifikat verwendet wird, indem Sie das SSL-Proxyprofil konfigurieren und auf eine Sicherheitsrichtlinie anwenden. SSL-Weiterleitungs-Proxy speichert diese Zertifikatsketteninformationen (CA-Zertifikatsprofilname) im jeweiligen SSL-Profil. Als Teil der Implementierung von Sicherheitsrichtlinien werden SSL-Profile mit Zertifikatsketteninformationen und CA-Zertifikaten verwendet.

Die folgenden Komponenten sind an der Verarbeitung von Zertifikatsketten beteiligt:

  • Administrator lädt die Zertifikatskette und das lokale Zertifikat (Signaturzertifikat) in den PKI-Daemon-Zertifikatscache.

  • Der Network Security Daemon (nsd) sendet eine Anfrage an den PKI-Daemon, um die Zertifikatsketteninformationen für ein im SSL-Proxyprofil konfiguriertes Signaturzertifikat bereitzustellen.

In diesem Beispiel wird davon ausgegangen, dass Sie bereits ein SSL-Zertifikat von einer Zertifizierungsstelle erworben haben.

Konfigurieren der Zertifikatskette auf dem Gerät

Schritt-für-Schritt-Verfahren

So konfigurieren Sie die Zertifikatskette:

  • Laden Sie das lokale Zertifikat in den PKI-Speicher.

    Die folgende Meldung wird angezeigt:

    Beachten Sie, dass die Zertifikats-ID im root-ca Abschnitt im SSL-Proxyprofil verwendet wird.

  • Laden Sie das Zwischen- oder Root-CA-Zertifikat in den PKI-Speicher.

    Das CA-Profil enthält die für die Authentifizierung verwendeten Zertifikatsinformationen. Es enthält den öffentlichen Schlüssel, den SSL-Proxy beim Generieren eines neuen Zertifikats verwendet.

    Dieses Zertifikat wird als Zertifikatskette angefügt.

  • Fügen Sie die CA-Profilgruppe an das SSL-Proxyprofil an. Sie können eine vertrauenswürdige Zertifizierungsstelle nacheinander anfügen oder alle in einer Aktion laden.

  • Wenden Sie das Signaturzertifikat als root-ca im SSL-Proxyprofil an.

  • Erstellen Sie eine Sicherheitsrichtlinie und geben Sie die Übereinstimmungskriterien für die Richtlinie an. Geben Sie als Übereinstimmungskriterien den Datenverkehr an, für den Ssl-Proxy aktiviert werden soll. In diesem Beispiel wird davon ausgegangen, dass Sie bereits Sicherheitszonen basierend auf den Anforderungen erstellt haben.

    Ssl-Weiterleitungs-Proxy speichert diese Zertifikatsketteninformationen (CA-Zertifikatsprofilname) in dem jeweiligen SSL-Profil. Als Teil der Implementierung von Sicherheitsrichtlinien werden SSL-Profile mit Zertifikatsketteninformationen und CA-Zertifikaten verwendet.

    Sie können die Zertifikatskette im verbundenen Webbrowser (dem Client) anzeigen.

Fehler bei der Serverauthentifizierung ignorieren

Serverauthentifizierung

Implizite Vertrauenswürdigkeit zwischen dem Client und dem Gerät (weil der Client das vom Gerät generierte Zertifikat akzeptiert) ist ein wichtiger Aspekt des SSL-Proxys. Es ist äußerst wichtig, dass die Serverauthentifizierung nicht kompromittiert wird. in der Realität gibt es jedoch selbstsignierte Zertifikate und Zertifikate mit Anomalien im Überfluss. Anomalien können abgelaufene Zertifikate, Instanzen von gemeinsamem Namen, die nicht mit einem Domänennamen übereinstimmen, usw. umfassen.

Die Serverauthentifizierung wird durch die Einstellung der ignore-server-auth-failure Option im SSL-Proxyprofil gesteuert. Die Ergebnisse der Einstellung dieser Option sind in Tabelle 2 verfügbar.

Tabelle 2: Option "Serverauthentifizierungsfehler ignorieren"

AKTION des SSL-Proxy-Profils

Ergebnisse

Die ignore-server-auth-failure Option ist nicht festgelegt (Standardoption)

  • Wenn die Authentifizierung erfolgreich ist, wird ein neues Zertifikat generiert, indem die Schlüssel ersetzt und der Name des Ausstellers in den Namen des Ausstellers geändert wird, der im Stammzertifikat der CA im Proxyprofil konfiguriert ist.

  • Wenn die Authentifizierung fehlschlägt, wird die Verbindung unterbrochen.

Die ignore-server-auth-failure Option ist festgelegt

  • Wenn das Zertifikat selbstsigniert ist, wird durch Ersetzen der Schlüssel ein neues Zertifikat generiert. Der Name des Emittenten wird nicht geändert. Dadurch wird sichergestellt, dass der Client-Browser eine Warnung anzeigt, dass das Zertifikat nicht gültig ist.

  • Wenn das Zertifikat abgelaufen ist oder der gemeinsame Name nicht mit dem Domänennamen übereinstimmt, wird ein neues Zertifikat generiert, indem die Schlüssel ersetzt und der Name des Herausgebers in SSL-PROXY: DUMMY_CERT:GENERATED AUFGRUND eines SRVR-AUTH-FEHLERS geändert wird.

    Dadurch wird sichergestellt, dass der Client-Browser eine Warnung anzeigt, dass das Zertifikat nicht gültig ist.

  • Wir empfehlen diese Option für die Authentifizierung nicht, da die Konfiguration dazu führt, dass Websites überhaupt nicht authentifiziert werden. Sie können diese Option jedoch verwenden, um die Ursache für unterbrochene SSL-Sitzungen effektiv zu ermitteln. Siehe Aktivieren von Debugging und Tracing für SSL-Proxy.

Client-Authentifizierung

Derzeit wird die Client-Authentifizierung in SSL-Proxy nicht unterstützt. Wenn ein Server die Clientauthentifizierung anfordert, wird eine Warnung ausgegeben, dass kein Zertifikat verfügbar ist. Mit der Warnung kann der Server festlegen, ob er fortfahren oder beenden soll.

Zertifikatssperrlisten für SSL-Proxy

Arbeiten mit den Zertifikatssperrlisten für SSL-Proxy

Die Zertifizierungsstelle (Certificate Authority, CA) veröffentlicht regelmäßig eine Liste des widerrufenen Zertifikats mithilfe einer Zertifikatssperrliste (Certificate Revocation List, CRL). Das Sicherheitsgerät lädt die zuletzt ausgestellte CRL herunter und speichert sie zwischen. Die CRL enthält die Liste der digitalen Zertifikate mit Seriennummern, die vor ihrem Ablaufdatum abgebrochen wurden.

Die Zertifizierungsstelle widerruft das ausgestellte Zertifikat, wenn die Möglichkeit besteht, dass das Zertifikat kompromittiert wird. Einige andere Gründe für den Widerruf eines Zertifikats sind:

  • Nicht spezifiziert (es wird kein bestimmter Grund angegeben).

  • Der private Schlüssel, der dem Zertifikat oder der Zertifizierungsstelle, die das Zertifikat ausgestellt hat, zugeordnet ist, wurde kompromittiert.

  • Der Besitzer des Zertifikats ist nicht mehr mit dem Aussteller des Zertifikats verbunden

  • Ein anderes Zertifikat ersetzt das Originalzertifikat.

  • Die Zertifizierungsstelle, die das Zertifikat ausgestellt hat, funktioniert nicht mehr.

  • Das Zertifikat befindet sich in der Warteschleife, bis weitere Maßnahmen eingeleitet werden. Sie wird als widerrufen behandelt, kann aber in Zukunft akzeptiert werden.

Wenn ein teilnehmende Gerät ein digitales Zertifikat verwendet, überprüft es die Zertifikatssignatur und -gültigkeit. Standardmäßig ist die CRL-Überprüfung im SSL-Proxyprofil aktiviert.

Ab Junos OS Version 15.1X49-D30 und Junos OS Version 17.3R1 unterstützen Firewalls der SRX-Serie zertifikatssperrliste (Certificate Revocation List, CRL). Die CRL-Validierung auf der Firewall der SRX-Serie umfasst die Prüfung auf die widerrufenen Zertifikate von Servern.

Auf der Firewall der SRX-Serie ist die Prüfung der Zertifikatssperrung für SSL-Proxyprofil standardmäßig aktiviert. Sie können die CRL-Validierung aktivieren oder deaktivieren, um Ihre spezifischen Sicherheitsanforderungen zu erfüllen.

  • Deaktivieren Sie die CRL-Überprüfung.
  • Aktivieren Sie die CRL-Verifizierung erneut.

Sie können die Sitzungen zulassen oder löschen, wenn eine CRL-Information aus Gründen wie fehlgeschlagener CRL-Download oder Nichtverfügbarkeit des CRL-Pfads im Stamm- oder Zwischenzertifikat nicht verfügbar ist.

  • Lassen Sie die Sitzungen zu, wenn keine CRL-Informationen verfügbar sind.

  • Löschen Sie die Sitzungen, wenn keine CRL-Informationen verfügbar sind.

  • Konfigurieren Sie eine Firewall der SRX-Serie so, dass sie ein Zertifikat akzeptiert, ohne dass eine zuverlässige Bestätigung für den Sperrstatus verfügbar ist, und lassen Sie die Sitzungen zu, wenn ein Zertifikat widerrufen wird und der Sperrgrund auf Eis liegt.

SSL-Leistungsverbesserungen

Die SSL-Leistungsverbesserung der Firewall der SRX-Serie umfasst die folgenden Funktionen:

Optimierung der SSL-Leistung

Der SSL/TLS-Handshake ist ein CPU-intensiver Prozess. Da SSL/TLS das am häufigsten verwendete Sicherheitsprotokoll im Web ist, hat die Leistung erhebliche Auswirkungen auf die Webleistung.

Ab Junos OS Version 15.1X49-D120 können Sie die folgenden Optionen zur Leistungsoptimierung verwenden:

  • Verwenden Sie einen optimierten RSA-Schlüsselaustausch

  • Authentifizierte Verschlüsselung mit verknüpften Daten (AEAD) verwenden – AES128-CBC-SHA, AES256-CBC-SHA

  • Wartung des Zertifikatscaches: Im Zertifikatscache werden das zwischen den Handlungen enthaltene Serverzertifikat zusammen mit den Serverzertifikatsdetails gespeichert. Während des SSL/TLS-Handshake kann der SSL-Proxy das zwischengespeicherte, interdiktierte Zertifikat dem Client präsentieren, anstatt das neue interdicted-Zertifikat zu generieren.

Die Verbesserung der SSL-Leistung führt zu einer verbesserten Website-Leistung, ohne die Sicherheit zu beeinträchtigen und die Benutzererfahrung zu maximieren.

Sie können optional die folgenden Einstellungen für den Zertifikatscache konfigurieren. Wir empfehlen jedoch, die Standardwerte beizubehalten.

Beispiel:

  • (Optional) Legen Sie den Timeoutwert für den Zertifikatscache fest (Beispiel: 300 Sekunden).

    In diesem Beispiel speichert der Zertifikatscache die Zertifikatsdetails 300 Sekunden lang. Der Standard-Timeout-Wert ist 600 Sekunden.

  • (Optional) Deaktivieren Sie den Zertifikatscache.

    Wenn Sie den Zertifikatscache deaktivieren, ermöglicht das Gerät den vollständigen SSL-Handshake für eine neue Verbindung. Standardmäßig ist der Zertifikatscache aktiviert.

  • (Optional) Ungültig machen Sie den vorhandenen Zertifikatscache.

    In diesem Beispiel wird der vorhandene Zertifikatscache ungültig, wenn die Zertifikatsperrliste (Certificate Revocation List, CRL) aktualisiert wird. Standardmäßig ist das Ungültigen des Zertifikatcaches bei der CRL-Aktualisierung deaktiviert.

Wiederaufnahme der Sitzung

Die Wiederaufnahme von SSL-Sitzungen bietet einen Mechanismus, um eine vorherige Sitzung unter Verwendung bereits ausgehandelter Sitzungs-IDs wieder aufzunehmen. Die Wiederaufnahme der Sitzung spart dem Client und dem Server den Rechenaufwand eines vollständigen SSL-Handshakes und der Generierung neuer Primärschlüssel.

Die Wiederaufnahme der Sitzung verkürzt den Handshake-Prozess und beschleunigt SSL-Transaktionen, was zu einer verbesserten Leistung bei gleichzeitiger Aufrechterhaltung eines angemessenen Sicherheitsniveaus führt.

TLS 1.2 unterstützt die Wiederaufnahme von Sitzungen mit Sitzungskennungen und Sitzungstickets-Mechanismen. Eine Wiederaufnahme der SSL-Sitzung umfasst die folgenden Schritte:

  • Ein Sitzungs-Caching-Mechanismus speichert Sitzungsinformationen, wie z. B. den geheimen Pre-Master-Schlüssel und vereinbarte Chiffren für den Client und den Server.

  • Die Sitzungs-ID identifiziert die zwischengespeicherten Informationen.

  • Bei späteren Verbindungen stimmen beide Parteien zu, die Sitzungs-ID zum Abrufen der Informationen zu verwenden, anstatt einen pre-master-geheimen Schlüssel zu erstellen.

Ab Junos OS Version 22.1R1 unterstützt TLS 1.3 die Wiederaufnahme von Sitzungen mithilfe eines pre-shared key (PSK) im SSL-Proxy. Die Wiederaufnahme der Sitzung mit PSK ermöglicht das Wiederaufsetzen einer Sitzung mit einem zuvor festgelegten gemeinsamen geheimen Schlüssel, um den Aufwand für SSL-Handshake zu reduzieren.

PSK ist ein einzigartiger Verschlüsselungsschlüssel, der aus dem anfänglichen TLS-Handshake abgeleitet wurde. Nach einem erfolgreichen TLS-Handshake sendet der Server eine PSK-Identität an den Client. Der Client verwendet diese PSK-Identität in den zukünftigen Handshakes, um die Verwendung des zugehörigen PSK zur Fortsetzung der Sitzung auszuhandeln.

Eine Wiederaufnahme der SSL-Sitzung mit TLS1.3 umfasst die folgenden Schritte:

  1. Nach einem ersten TLS-Handshake sendet der Server eine neue Session Ticket-Nachricht an den Client, die die PSK-Identität (verschlüsselte Kopie des PSK) enthält.

  2. Wenn der Client das nächste Mal versucht, die Sitzung wieder aufzunehmen, sendet er dasselbe Sitzungsticket in der Hallo-Nachricht an den Server.
  3. Der Server entschlüsselt die Nachricht, identifiziert den PSK und ruft die Sitzungsinformationen aus seinem Cache ab, um die Sitzung wieder aufzunehmen.

Eine SSL-I (SSL-Initiierung) verwendet PSK mit ECDHE-Schlüsselaustauschmodus, und SSL-T (SSL-Terminierung) verwendet PSK und PSK mit ECDHE-Austauschmodi.

SSL-Proxysitzung unterstützt die Interoperabilität zwischen TLS1.3 und TLS1.2 und früheren Versionen an zwei Enden einer Verbindung für die Wiederaufnahme der Sitzung.

Standardmäßig ist die Wiederaufnahme der Sitzung für SSL-Proxy aktiviert. Sie können die Wiederaufnahme der Sitzung gemäß Ihren Anforderungen löschen oder erneut aktivieren.

  • So löschen Sie die Wiederaufnahme der Sitzung:
  • So aktivieren Sie die Wiederaufnahme der Sitzung:

Verwenden Sie den folgenden Befehl, um den Sitzungs-Timeoutwert zu konfigurieren.

Sie können den Timeoutwert zwischen 300 Sekunden und 86400 Sekunden konfigurieren. Der Standardwert ist 86400 Sekunden (24 Stunden).

Sitzungs-Neuaushandlung

Die Firewall der SRX-Serie unterstützt Sitzungs-Neuverhandlungen. Nachdem eine Sitzung erstellt und der SSL-Tunnel-Transport eingerichtet wurde, erfordert eine Änderung der SSL-Parameter eine Neuaushandlung. SSL-Proxy unterstützt sowohl sichere (RFC 5746) als auch nicht sichere (TLS v1.0, TLS v1.1 und TLS v1.2) Neuverhandlungen. Wenn die Wiederaufnahme der Sitzung aktiviert ist, ist die Neuaushandlung von Sitzungen in den folgenden Fällen nützlich:

  • Cipher-Schlüssel müssen nach einer längeren SSL-Sitzung aktualisiert werden.

  • Für eine sicherere Verbindung müssen stärkere Chiffren angewendet werden.

Wenn Sie das SSL-Proxyprofil ändern, indem Sie ein Zertifikat oder eine Chiffrestärke oder eine Liste vertrauenswürdiger CA ändern, spült das System die Cache-Einträge, wenn Sie die geänderte Richtlinie bestätigen. In diesem Fall ist ein vollständiger Handshake erforderlich, um die neuen SSL-Parameter festzulegen. (Es gibt keine Auswirkungen auf Nicht-SSL-Sitzungen.)

Wenn das SSL-Proxyprofil nicht geändert wird, werden cache-Einträge, die diesem Profil entsprechen, nicht gelöscht, und die Sitzung wird fortgesetzt.

Aushandlung von StartTLS für SMTP-Sitzungen

StartTLS ermöglicht eine SMTP-Sitzung von einer anfänglichen einfachen TCP-Verbindung zu einer sichereren TLS-Verbindung. StartTLS ermöglicht eine SMTP-Sitzung zwischen Server und Client über die TLS-Ebene nach erfolgreicher Aushandlung zwischen den Peers. StartTLS aktualisiert eine vorhandene unsichere einfache SMTP-Verbindung auf eine sichere SSL/TLS-Verbindung.

Sie können den Schwellenwert festlegen, damit Sie entscheiden können, wie lange Sie warten müssen, bevor Sie die Sitzung ignorieren, wenn StartTLS nicht vom Client empfangen wird.

Sie können die folgenden Optionen konfigurieren:

  • Byte-Schwellenwert: Minimale Bytes an nicht verschlüsselter Sitzung, bevor die Sitzung ignoriert wird, wenn StartTLS nicht vom Client empfangen wird. Bereich 100 bis 300.
  • Paket-Schwellenwert: Anzahl der nicht verschlüsselten Pakete, die in Client-to-Server-Richtung zulässig sind, bevor die Sitzung ignoriert wird, wenn StartTLS nicht vom Client empfangen wird. Bereich 1 bis 15.

Beispiel:

In diesem Exaple erlaubt der SSL-Proxy 100 Bytes einfachen (unverschlüsselten) SMTP-Datenverkehr. Nach Erreichen von 100 Bytes ignoriert es die Sitzung, wenn StartTLS nicht vom Client empfangen wird.

In diesem Beispiel lässt der SSL-Proxy 2 Pakete mit einfachem (unverschlüsselten) SMTP-Datenverkehr zu. Nach Erreichen von 2 Paketen ignoriert es die Sitzung, wenn StartTLS nicht vom Client empfangen wird.

Dynamische Auflösung von Domänennamen

Die mit Domänennamen verknüpften IP-Adressen sind dynamisch und können sich jederzeit ändern. Wenn sich eine Domain-IP-Adresse ändert, wird sie an die SSL-Proxykonfiguration weitergegeben (ähnlich wie bei der Konfiguration der Firewall-Richtlinien).

Tabelle "Versionshistorie"
Release
Beschreibung
15.1X49-D30
Ab Junos OS Version 15.1X49-D30 und Junos OS Version 17.3R1 unterstützen Firewalls der SRX-Serie zertifikatssperrliste (Certificate Revocation List, CRL).