Schlagwort-Archive: Konfiguration

Konfiguration von TLS-Servern: Aktueller Cipher-String 2019

Bekanntermaßen ist die Konfiguration der Crypto-Parameter von TLS-Servern  eine kontinuierliche Aufgabe, siehe hierzu auch den ausführlichen Artikel Konfiguration von TLS-Servern: Ständige Herausforderung.

Im Vergleich zu unserem letzten Cipher-String von Ende 2017 sind die folgenden Änderungen sinnvoll:

  • TLS 1.0 und 1.1 abschalten
  • RSA für den reinen Schlüsselaustausch deaktivieren
  • CBC deaktivieren

Am zweckmäßigsten scheint inzwischen eine kurze Positiv-Liste mit expliziter Angabe der unterstützten Cipher zu sein. Die DFN-PKI wird auf ihren Servern im Laufe von 2019 die folgende Konfiguration aktivieren:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder On

SSLCipherSuite 'ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256'

Zu einem so konfigurierten Server können die folgenden veralteten Clients keine Verbindung mehr aufnehmen: Safari <= 8, WinPhone 8.1, IE 8-10 auf Win7, Android <= 4.3, Java <= 7.

Bitte beachten Sie auch die weiteren Konfigurations-Empfehlungen aus dem oben genannten Artikel, insbesondere die Anleitung für individuelle Diffie-Hellman-Parameter.

(Jürgen Brauckmann, 07.08.2019)

Konfiguration von TLS-Servern: Aktueller Cipher-String

Bekanntermaßen ist die Konfiguration der Crypto-Parameter von TLS-Servern  eine kontinuierliche Aufgabe, siehe hierzu auch den ausführlichen Artikel Konfiguration von TLS-Servern: Ständige Herausforderung.

In unserem aktuellen Apache Cipher-String haben wir 3DES entfernt:

SSLCipherSuite 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP:!PSK:!DSS:!SEED:!ECDSA:!CAMELLIA'

Bitte beachten Sie auch die weiteren Konfigurationsempfehlungen aus dem oben genannten Artikel , insbesondere die Anleitung für individuelle Diffie-Hellman-Parameter!

(jbr, 10.12.2017)

OCSP-Stapling in nginx

OCSP-Stapling kann in nginx ab Version 1.3.7 leicht angeschaltet werden. Die Basiskonfiguration ist simpel, allerdings gilt es vier Fallen zu umgehen:

Netzwerk

Der Webserver, auf dem OCSP-Stapling konfiguriert werden soll, muss ausgehende Anfragen an http://ocsp.pca.dfn.de stellen können. Sollte der Server durch eine Firewall an ausgehendem Traffic gehindert werden, muss für OCSP-Stapling eine Ausnahme gemacht werden.

Ist dies nicht erwünscht, müssen komplexere Setups genutzt werden, bei denen OCSP-Responses als Datei über mehrere  Etappen bis zum Webserver gelangen. Auf diese Szenarien wird hier aber nicht weiter eingegangen.

DNS

nginx nutzt per Default den DNS Server von Google, IP 8.8.8.8, um die Adresse des OCSP-Responders  (in der DFN-PKI ist dies ocsp.pca.dfn.de) aufzulösen. Die meisten Webserver sind sinnvollerweise so konfiguriert, dass sie keine Verbindung zu externen DNS-Servern aufnehmen können. Daher muss dem nginx die Adresse des lokalen DNS-Servers separat über den Konfigurationseintrag resolver mitgeteilt werden.

Zertifikatsketten

nginx benötigt die vollständige Zertifikatkette des Serverzertifikats inklusive der Wurzel zum Betrieb von OCSP Stapling. Der dafür vorgesehene Konfigurationsparameter ist ssl_trusted_certificate.

Dieser Parameter ist ein wenig problematisch, da die dort enthaltene Zertifikatkette auch im Rahmen des TLS-Handshakes an Endgeräte ausgeliefert wird, wenn in ssl_certificate keine Kette enthalten ist. Im TLS-Handshake soll das Wurzelzertifikat aber nicht mit enthalten sein.

Die Lösung: In ssl_trusted_certificates die vollständige Kette inklusive Wurzelzertifiakt konfigurieren, und in das Serverzertifikat in ssl_certificate die Kette ohne Wurzelzertifikat aufnehmen. Die Reihenfolge der Zertifikate in den Dateien muss „aufsteigend“ bis zur Wurzel sein. Es müssen die reinen PEM-Files ohne Zwischen-Kommentare angegeben werden:
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----

Mehrere virtuelle Hosts

Wenn mehrere virtuelle Hosts im nginx konfiguriert sind, so muss OCSP-Stapling mindestens für den als default_server konfigurierten Host aktiviert sein, damit das OCSP-Stapling dann auch auf den anderen virtuellen Hosts funktionieren kann.

Konfiguration

Konkret sollte der vom OCSP-Stapling betroffene Teil der SSL-Konfiguration eines nginx also folgendermaßen aussehen (die IP-Adressen sind natürlich, wie die Pfade, nur Platzhalter):

ssl_trusted_certificate /pfad/vollstaendige_kette_mit_root
ssl_certificate /pfad/serverzertifikat_inklusive_kette_ohne_root
ssl_stapling on;
ssl_stapling_verify on;
resolver 192.168.100.100 192.168.100.101 valid=300s;
resolver_timeout 10s

Testen

Getestet wird die OCSP-Stapling-Konfiguration auf dem nginx mittels (der Host-Name ist natürlich auch hier nur ein Platzhalter) :

openssl s_client -connect blog.example.org:443 -servername blog.example.org -status < /dev/null 2>&1 | grep -i "OCSP response"

Nach einem Neustart des nginx wird die einzubettende OCSP-Response erst beim ersten Abruf einer Web-Seite des Servers vom OCSP-Responder abgeholt und zwischengespeichert, so dass bei diesem ersten Abruf keine OCSP-Response eingebettet werden kann. Erst beim zweiten Abruf einer Web-Seite des Servers wird dann auch eine eingebettete OCSP-Response mitgeliefert, d.h. nach einem Neustart des nginx muss obiger openssl-Aufruf zweimal hintereinander ausgeführt werden, um ein aussagekräftiges Ergebnis zu liefern.

Dokumentation von nginx:  http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling

(jbr, 17.06.2015, ergänzt am 20.11.2015)

Lightweight-OCSP nach RFC 5019 und FreeRADIUS

Die OCSP-Responder der DFN-PKI arbeiteten lange Zeit gemäß RFC 2560. Dieser Betriebsmodus hat insbesondere in Hochlast-Umgebungen Nachteile; insbesondere wird ein Caching von OCSP-Antworten deutlich erschwert.

RFC 5019, „The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments“, spezifiziert eine OCSP-Variante, die die Caching-Probleme deutlich abmildert.

Seit Mitte Mai wurden die OCSP-Responder der DFN-PKI der Reihe nach auf eine neue Software-Version gebracht, die RFC 5019 verwendet. Damit werden Caching-Header gesetzt und sogenannte Nonces aus eingehenden Anfragen nicht mehr in die OCSP-Antwort kopiert. Viele OCSP-Responder, auch von sehr großen CAs, werden erfolgreich nach RFC 5019 betrieben.

Leider gibt es hierbei einen Nebeneffekt bei FreeRADIUS: Wenn man Nutzerzertifikate zur Authentifizierung verwendet, und zur Validierung der Nutzerzertifikate OCSP aktiviert hat, muss zwingend eine zusätzliche Konfigurationsoption in den OCSP-Abschnitt der eap/tls-Konfiguration gesetzt werden:

ocsp {
   ...
   use_nonce = no
   ...
}

Wird diese Option nicht verwendet, akzeptiert FreeRADIUS das Nutzerzertifikat nicht und schreibt, je nach Loglevel, die folgende Nachricht in das radius.log :

Error: OCSP response has wrong nonce value

(jbr, 05.06.2015)

Konfiguration von TLS-Servern: Ständige Herausforderung

Die Konfiguration von TLS-Servern wird immer mehr zur großen Herausforderung für Administratoren. Die verschiedenen Einstellungsmöglichkeiten für die Algorithmen, die TLS-Version und weitere Nebenparameter sind sehr komplex und für den Einzelnen kaum direkt bewertbar.

Noch unangenehmer wird die Situation dadurch, dass inzwischen mehrmals pro Jahr neue Erkenntnisse über die Sicherheit von TLS-Konfigurationen veröffentlicht werden; aktuelles Beispiel ist Logjam. Diese Erkenntnisse spiegeln sich direkt in Änderungen an sehr wichtiger Software wie Mozilla Firefox oder Google Chrome wieder, die als unsicher geltende Konfigurationen dann auch klar und deutlich markieren. Über deren Auto-Update-Funktion dauert es dann nur wenige Wochen, bis Endanwender neue Fehlermeldungen über unsichere Konfigurationen zu sehen bekommen.

Man kann sich daher nicht auf eine einmal gefundene Konfiguration verlassen, sondern muss ständig Anpassungen vornehmen, damit ein TLS-Server sicher bleibt und moderne Client-Software ohne störende Warnmeldungen darauf zugreifen kann.

Andererseits gibt es viele alte Software, die mit modernen Konfigurationen nicht kompatibel ist. Betroffen ist sowohl die Server- als auch die Client-Seite. Die direkte Übernahme von Konfigurationsvorschlägen kann dadurch auch unerwünschte Nebenwirkungen haben und für ernsthafte Betriebsstörungen sorgen.

Um welche Server muss man sich kümmern?

Generell muss bei jedem Server, der in irgendeiner Art TLS unterstützt und verwendet, die TLS-Konfiguration vom Administrator regelmäßig überprüft werden. Betroffen sind z.B. die folgenden Dienste/Protokolle :

  • Webserver
  • IMAP/POP3
  • SMTP
  • OpenVPN
  • LDAPS
  • FTPS

Konfigurationsempfehlungen

Es ist dringend anzuraten, die Konfiguration eines TLS-Servers nicht komplett selbst zu erstellen, sondern immer von Empfehlungen von Experten auszugehen und Änderungen nur vorsichtig und mit Bedacht vorzunehmen. Es gibt zahlreiche Empfehlungen, denen man folgen kann:

Bettercrypto

Das Bettercrypto-Projekt erstellt einen Katalog an Algorithmen- und Konfigurationsempfehlungen für verschiedenste Software und reagiert sehr schnell auf neue Entwicklungen. Die Vielfalt und die kryptographische Expertise sorgen allerdings auch für eine kleine Schwäche des Projektes: Der Leitfaden ist sehr umfangreich und damit etwas unübersichtlich. Dafür erhält man aber auch Konfigurationsempfehlungen für selten behandelte Software.  https://bettercrypto.org/

Mozilla

Für den Einstieg leichter zu lesen sind die Empfehlungen des Operating-Teams des Mozilla-Projekts: https://wiki.mozilla.org/Security/Server_Side_TLS

Allerdings ist der von Mozilla vorgestellte Ciphersuite-String sehr unübersichtlich und aus unser Sicht unnötig komplex. Eigene Anpassungen sind alleine aufgrund der Länge des Strings praktisch nicht möglich.

Besonders interessant ist der „Mozilla SSL Configuration Generator“, mit dem man sich für diverse Server-Software eine fertige Konfiguration erzeugen lassen kann: https://mozilla.github.io/server-side-tls/ssl-config-generator/

Spezialfall Microsoft Server

Microsoft Server wie IIS oder Exchange arbeiten system-typisch nicht mit einer Konfigurationsdatei, sondern über Registry-Keys, wodurch die Übersichtlichkeit deutlich leidet. Microsoft dokumentiert die vorhandenen Registry-Keys auf der folgenden Seite:

https://technet.microsoft.com/en-us/library/dn786418.aspx

Konkrete Ratschläge für eine brauchbare Konfiguration finden sich z.B. bei Alexander Hass:

https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12

Microsoft liefert Anpassungen an die TLS-Konfiguration teilweise auch per Update aus, so dass der Bedarf, selbst Änderungen vorzunehmen, nicht ganz so groß ist wie z.B. bei Apache httpd. Trotzdem sollte auch bei Microsoft-Servern regelmäßig getestet werden, ob die Sicherheit der TLS-Konfiguration noch gegeben ist

Auswirkungen von Fehlern bei der TLS-Konfiguration

Zu alte Konfiguration: Veraltete Konfigurationen sind generell unsicher, ermöglichen das Abhören der Verbindung und möglicherweise sogar die Manipulation von übertragenen Daten.

Aber auch ohne einen konkreten Angreifer gibt es deutliche Konsequenzen: Unterstützt man alte Algorithmen, beschweren sich moderne Webbrowser wie Firefox und Chrome sehr aggressiv, und präsentieren dem Nutzer Warnhinweise über die unsichere Verbindung oder verweigern den Verbindungsaufbau gleich ganz.

Zu moderne Konfiguration: Hat man zu aggressiv nur die modernsten Algorithmen konfiguriert, sperrt man ältere Software aus. Während Windows XP hoffentlich bei niemandem mehr ernsthaft ein Thema ist, wird der Support von Android 4.3 für viele öffentlich erreichbare Webserver Pflicht sein. Die modernsten Einstellungen werden aber nur von Internet Explorer ab Version 11, Java 8, und Android ab 4.4 unterstützt. Dagegen sind Firefox und Chrome, auch durch die Auto-Updates, relativ unkritisch.

Java 6 (was übrigens seit Februar 2013 keine Sicherheitspatches mehr erhält und dringend außer Betrieb genommen werden sollte) ist sehr empfindlich und kaum noch vernünftig zu bedienen. Muss man solche alten Systeme unterstützen, hat man ein größeres Problem. Größtes Problem bei Java 6 ist die fehlende Unterstützung für Diffie-Hellman-Parameter mit mehr als 1024 Bit.

Tests

Aufgrund der Komplexität der vielen Einstellungsmöglichkeiten sollte man immer einen Test durchführen. Ohne Test kann niemand garantieren, dass einerseits die Kompatibilität zu den gewünschten Systemen da ist, andererseits der Server aber trotzdem eine sichere Konfiguration hat.

Eine sehr schöne Möglichkeit ist der SSL-Test von Qualys, der eine gute Übersicht über die Sicherheit des TLS-Servers bietet und dazu direkt die Kompatibilität zu über 30 Browsern und Betriebssystemen prüft: https://www.ssllabs.com/ssltest/

Leider liegt der Fokus der meisten Testtools auf Webserver/Port 443. Für andere Protokolle sind die Testmöglichkeiten rar.

Beispielkonfiguration

Als Beispiel soll hier die Apache-Konfiguration dieses Blogs, wie sie aktuell (Juni 2015) gesetzt ist, beschrieben werden. Übernehmen Sie diese Konfiguration nicht kritiklos, sondern prüfen Sie, ob sie Ihren Anforderungen genügt, und testen Sie gründlich!

Die Konfiguration ist nach unserem Kenntnisstand mit den meisten Systemen kompatibel, mit den verschmerzbaren Ausnahmen IE6/Windows XP und Java 6.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCompression Off
SSLCipherSuite 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:ECDH+3DES:DH+3DES:RSA+3DES:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP:!PSK:!DSS:!SEED:!ECDSA:!CAMELLIA'

Diffie-Hellman-Parameter

Um speziell gegen Logjam sicher zu sein, sollte man eigene, individuelle Diffie-Hellman-Parameter verwenden. Für Apache httpd muss man diese selbst erzeugen. Der folgende Aufruf erzeugt sichere 2048-Bit Parameter und gibt sie auf die Konsole aus. Es wird empfohlen, dass die Länge der Diffie-Hellman-Parameter gleich der Länge des Server-Schlüssels ist, um ein gleichmäßiges Sicherheitsniveau zu erreichen. openssl kann übrigens durchaus einige Zeit an den neuen Parametern rechnen.

openssl dhparam 2048

Zur Konfiguration eines Apache httpd gibt es zwei Varianten, je nach Version: Bei nicht Top-aktuellen Versionen von Apache und openssl müssen die erzeugten Parameter an das Ende des Serverzertifikats (konfiguriert in SSLCertificateFile) angehängt werden, Beispiel:

[...]
 /s0FbDV+wjkbr9xzW4cG2ehbx2nsMXicRrrER1X5DGxl4KbzK0jzUTiLX9bAlEtK
 QGRICP74bb97RkfFTnK9D1Y0prhyh8gnNsircca6jbu+P0wYTkElSckyekwuDvUs
 g/YbnNdlHRxsO4dPP4lqlRux0YUVmhcfqAoJv5Ld5KY7v78S89nkpR1WKnlGkV6U
 2uO0HMmdZBheAvayBcfL
 -----END CERTIFICATE-----
 -----BEGIN DH PARAMETERS-----
 MIGHAoGBAKwwFBBNL7Vml7Fwl5U3P8XN8P3PSDnvlhpVRNm9aIiBXV9CsgBw8EMV
 2eASd0S38h5gJt/by9vCBMRtaDlKHnYt0J33Vu7r7RcriXBWlhaSyl2ljZcLYkRH
 [...]

Nach jedem Wechsel des Serverzertifikats müssen die Parameter neu eingetragen werden.

Setzt man einen Apache >= 2.4.8 mit openssl >= 1.0.2 ein, kann die oben erzeugten Parameter auch in eine eigene Datei auslagern und  separat konfigurieren (Information von https://weakdh.org/sysadmin.html, nicht selbst getestet):

SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"

Weitere Sicherheitsparameter

Für zusätzliche Sicherheit können noch die folgenden Parameter gesetzt werden. Insbesondere erhält man damit einen erhöhten Schutz gegen Frame-Einbettungs-Angriffe und einige Formen von XSS-Angriffen.

Strict-Transport-Security ist eine Anweisung an Web-Browser, bis zum Ablauf von max-age mit dieser Webseite ausschließlich über https zu kommunizieren, selbst wenn der Nutzer eine http-URL verwendet oder http-Ressourcen von der Seite nachgeladen werden sollen. Durch diesen Header werden sogenannte SSL-Stripping-Angriffe abgewehrt.

Für Webseiten, die auch unverschlüsselt erreichbar sein sollen, ist diese Option also nicht geeignet.

 Header always set Strict-Transport-Security "max-age=15768000"
 Header always set X-Frame-Options SAMEORIGIN
 Header always set X-XSS-Protection "1; mode=block"
 Header always set X-Content-Type-Options nosniff

OCSP-Stapling

Ebenfalls zu empfehlen ist die Verwendung von OCSP-Stapling, mit dem Sie die Ladezeiten Ihrer Seite etwas reduzieren und Ihren Nutzern mehr Anonymität bieten können. Für Erläuterungen und Konfigurationshinweise lesen Sie den separaten Artikel: Mehr Privacy für den Nutzer: OCSP-Stapling

Fazit

Befassen Sie sich regelmäßig mit der TLS-Konfiguration Ihrer Server, und testen Sie diese mit verfügbaren Test-Tools. Tun Sie dies nicht, riskieren Sie, dass die Verbindungen zu Ihrem Server nicht mehr sicher sind, und sich Nutzer über Warn- oder Fehlermeldungen beschweren.

(jbr, 04.06.2015)

FREAK-Attack: Konfiguration von TLS-Servern prüfen

Am 3. März 2015 wurde ein neuer Angriff auf verschiedene TLS-Implementierungen wie Safari und openssl bekannt, der wieder einmal deutlich macht, wie wichtig eine korrekte Konfiguration von TLS-Servern ist:

https://www.smacktls.com/#freak

http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html

Ein aktiver Man-In-The-Middle kann unter bestimmten Umständen einen Client dazu bringen, alte und vollkommen unsichere SSL-Algorithmen zu akzeptieren. Dadurch kann die Verbindung vom Angreifer sehr leicht entschlüsselt werden. Der Angriff kann nur durchgeführt werden, wenn die folgenden beiden Bedingungen zusammen erfüllt sind:

  • Der Client verwendet eine verwundbare TLS-Software
  • Der Server erlaubt veraltete Cipher Suites

Die FREAK-Attacke kann also, wie zahlreiche anderen Angriffe auf verschlüsselte Verbindungen in der letzten Zeit, von jedem Administrator eines TLS-Servers nur durch Konfigurationseinstellungen abgewehrt werden.

Wir empfehlen dringend, regelmäßig die Konfigurationseinstellungen Ihrer TLS-Server zu überprüfen und beispielsweise mit den Anleitungen von BetterCrypto.org  abzugleichen. Externe Werkzeuge wie der Test von SSL Labs können diese Arbeit deutlich erleichtern.

Bitte beachten Sie bei der Nutzung von externen Diensten, dass Sie damit Daten über Ihre Server an Dritte weitergeben.

(jbr, 04.03.2015)

Mehr Privacy für den Nutzer: OCSP-Stapling

[Update 20.5.2016: Fehlerhafter Hinweis auf SSLCACertificateFile für Apache entfernt.]

Zertifikate für Webserver enthalten die URL eines OCSP-Responders, der von der Zertifizierungsstelle betrieben wird. Viele Webbrowser wie z.B. Firefox oder Internet Explorer (aber nicht Google Chrome) führen beim Aufrufen einer https-Webseite mit dieser URL eine Prüfung durch, ob das Zertifikat gesperrt wurde. Hierzu stellen sie nach dem Verbindungsaufbau mit der Webseite eine weitere Anfrage an den OCSP-Responder, dessen URL im Serverzertifikat enthalten ist.

ocsp

Ablauf eines Webseitenaufrufs inklusive OCSP-Abfrage

Dieses Verhalten offenbart dem Betreiber des OCSP-Responders, von welcher IP-Adresse welcher Webserver aufgerufen wurden. Selbstverständlich werden auf den OCSP-Respondern der DFN-PKI keine IP-Adressen geloggt. Für Zertifikate aus anderen PKIs ist das Logging-Verhalten der zugehörigen OCSP-Responder aber nicht einfach zu klären.

Ein weiterer Nachteil ist die erhöhte Latenz durch den zusätzlichen Verbindungsaufbau zum OCSP-Responder.

Zur Lösung dieses Problems gibt es seit einiger Zeit ein Verfahren namens OCSP-Stapling, standardisiert in http://tools.ietf.org/html/rfc6066

ocsp_stapling_angewandt

Ablauf eines Webseitenaufrufs mit OCSP-Stapling

Beim OCSP-Stapling bezieht der Webserver regelmäßig (z.B. jede Stunde) vom OCSP-Responder eine OCSP-Antwort über sein eigenes Zertifikat, und schickt diese direkt im initialen TLS-Handshake zum Webbrowser des Nutzers. Damit muss der Webbrowser des Nutzers keine Verbindung zum OCSP-Responder aufnehmen.

Da die OCSP-Antwort immer vom OCSP-Responder signiert ist und diese Signatur vom Webbrowser verifiziert wird, ist die Sicherheit des Verfahrens gewährleistet.

OCSP-Stapling ist ein Feature, das die Software des Webservers unterstützen muss, und das teilweise separat konfiguriert werden muss. Es wird z.B. von folgender Software unterstützt:

  • Microsoft IIS ab Version 8.0
  • Apache ab 2.3.3
  • nginx ab 1.3.7

In Microsoft IIS ist OCSP-Stapling per Default aktiviert, es ist keine Konfiguration notwendig. In Apache lässt es sich sehr einfach einschalten:

SSLStaplingCache shmcb:/tmp/stapling_cache(102400)
SSLUseStapling on
SSLStaplingReturnResponderErrors off

Bedingungen für die Nutzung im Apache:

  • Das socache_shmcb-Modul muss geladen sein.
  • SSLStaplingCache muss außerhalb eines VirtualHost gesetzt werden.
  • Der Server muss den OCSP-Responder erreichen können (Ausgehende Verbindung in der Firewall, evtl. DNS).

Ob ein Server so konfiguriert ist, dass OCSP-Stapling genutzt wird, kann entweder mit den Test-Werkzeugen von SSL Labs geprüft werden, oder aber direkt mit openssl:

# openssl s_client -connect www.example.org:443 -status
CONNECTED(00000003)
depth=3 C = DE, O = Test, CN = Test Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
[...]

Es ist zu empfehlen, wo immer möglich OCSP-Stapling zu aktivieren, da es für alle Beteiligten nur Vorteile bietet.

(jbr, 04.03.2015)