OpenSSL s_client: Das Proxy-403 kommt vor dem TLS des Ziels
Deuten Sie ein 403 auf CONNECT über einen OpenSSL-Proxy als Fehler in der Tunnelphase und diagnostizieren Sie kein Zielzertifikat anhand eines Handshakes, der nie begonnen hat.
Wenn openssl s_client als Antwort auf seine CONNECT-Anfrage über den Proxy HTTP 403 erhält, beginnen Sie mit dieser Ablehnung. Der angeforderte Tunnel wurde nicht aufgebaut.
Mit -proxy bittet s_client zuerst den HTTP-Proxy, die mit -connect angegebene Zieladresse zu verbinden. Erst eine erfolgreiche CONNECT-Antwort wandelt diesen Austausch in einen Tunnel für den TLS-Handshake des Ziels um.
Diese Reihenfolge erklärt eine sonst verwirrende Ausgabe: ein Proxyfehler, gefolgt von TLS-bezogenen Überschriften, kein Peer-Zertifikat oder eine scheinbar beruhigende Verifikationszeile. Diese Felder belegen nicht, dass das Zertifikat des Ziels empfangen und geprüft wurde. Der Vorgang endete in einem früheren Stadium.
Halten Sie die Antwort des Proxys sowie den angeforderten Zielhost und -port fest. Ein 403 lenkt den Blick auf die Zugriffsentscheidung des Proxys; ein 407 verlangt eine Authentifizierung am Proxy. Keines von beiden wird dadurch behoben, dass die Prüfung des Zielzertifikats abgeschaltet wird.
Wenn der Austausch eingesehen werden darf, kann die -debug-Ausgabe von s_client helfen, die Ablehnung sichtbar zu machen. Halten Sie etwaige Proxy-Anmeldedaten aus gemeinsam genutzten Mitschnitten heraus. Ein erfolgreicher Tunnel bräuchte danach weiterhin eine eigene Bewertung von TLS und Zertifikaten, doch es gibt keine Zielzertifikatskette zu diagnostizieren, solange diese Phase nicht tatsächlich erreicht ist.