OCSP Stapling gibt dem Serveradministrator die Möglichkeit, seine SSL-Zertifikate für den Benutzer als gültig zu deklarieren, ohne dass selbiger erst den Zertifikatserver des Ausstellers abrufen muss. Bei der Erstellung eines OCSP Responders jedoch gibt es einige Tücken. Dies ist insbesondere dann der Fall, wenn der Zertifikatserver hinter CloudFlare geschützt ist.
Eigentlich ist das Erstellen eines OCSP Responders, also einer Datei, die vom Webserver genutzt werden kann, um die Gültigkeitslänge des Zertifikats auf sichere Weise zu deklarieren, einfach und mit einem Befehl per OpenSSL in der Konsole erstellt:openssl ocsp -noverify -no_nonce -respout ocsp.resp -issuer issuer.crt -cert domain.crt -url http://ocsp2.globalsign.com/gsalphasha2g2
Die issuer.crt ist dabei das Zertifikats des Zertifikatausstellers, in meinem Fall AlphaSSL, und die domain.crt das Zertifikat für meine Domain.
Hierbei sollte die Datei ocsp.resp erstellt werden, welche die Informationen zur Gültigkeit des SSL-Zertifikats enthält und vom Webserver weiterverwendet werden kann.
Die Angabe der URL, der sogenannten „OCSP URI“, wird durch folgenden Befehl herausgefunden:openssl x509 -in domain.crt -text | grep "OCSP - URI:" | cut -d: -f2,3
Dies muss nicht zwangsweise der Fall sein. Dann muss man sich im Internet schlau machen (Suchbegriff: OCSP URI <ZERTIFIKATAUSSTELLER>). In meinem Fall kam die oben genannte URL heraus.
Gebe ich allerdings den Befehl von oben so ein, wie er ist, erhielt ich nur folgende Fehlermeldung:
Error querying OCSP responsder
140400807491240:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:ocsp_ht.c:250:Code=403,Reason=Forbidden
Der HTTP-Statuscode 403 verhieß hier nichts Gutes. Auch wenn ich die URL im Browser öffne, erhielt ich nur folgende Meldung: „An error occured during the request handling!!“ Auch nicht sehr erfolgversprechend.
Erst nach langem Suchen (das ist auch der Grund für diesen Artikel) fand ich die Lösung:
Der Zertifikatserver von AlphaSSL liegt hinter CloudFlare und ist damit nicht per IP-Adresse direkt aufrufbar, wenn man diese über den Hostnamen herausfinden will. Genau das tut jedoch OpenSSL in der Standardvariante. Letztendlich bekommt er jedoch nur die IP-Adresse von CloudFlare zurück und versucht damit auf deren Server das Verzeichnis /gsalphasha2g2 aufzurufen. Logischerweise kommt dann der Fehlercode 403 zustande, da dieses Verzeichnis nicht existiert und man damit auch keine Berechtigung hat, es anzeigen zu lassen.
Das lässt sich sehr einfach umgehen, indem man den -header-Parameter von OpenSSL nutzt. Damit kann man explizit spezielle Header angeben, die bei der Abfrage mitgesendet werden. In diesem Falle ist es der Header „HOST“.
Damit sieht die Abfrage dann wie folgt aus:openssl ocsp -noverify -no_nonce -respout ocsp.resp -issuer issuer.crt -cert domain.crt -url http://ocsp2.globalsign.com/gsalphasha2g2 -header "HOST" "ocsp2.globalsign.com"
Als korrekte Antwort erhielt ich damit:
domain.crt: good
This Update: Feb 25 09:32:45 2015 GMT
Next Update: Feb 25 21:32:45 2015 GMT
Ebenfalls war die ocsp.resp generiert und ich konnte sie fehlerfrei in den Webserver einbinden.