Apache erzeugt viele Nur-SSL-Fehler, obwohl die Daten im Browser in Ordnung zu sein scheinen

7

Ich habe ein selbstsigniertes SSL-Zertifikat für die Website installiert, die ich auf localhost verwende. Es scheint, dass die Daten, die den Browser erreichen, sowohl für die SSL- als auch für die Nicht-SSL-Version vollständig und korrekt sind, aber ich erhalte eine Menge Apache-Fehler, die auf etwas anderes hinweisen.

Wenn ich auf Aktualisieren drücke, werden sofort einige dieser Zeilen im Protokoll angezeigt

AH01964: Connection to child 0 established

Auch Kind 2, 6, 4 usw. können in keiner bestimmten Reihenfolge erscheinen.

In den nächsten Sekunden bekomme ich mehrere davon

(70014)End of file found: [client 127.0.0.1:32839] AH01991: SSL input filter read failed.
[client 127.0.0.1:32840] AH01382: Request header read timeout

Ich gehe davon aus, dass die Vielzahl dieser Zeilen auf Skripte, CSS usw. zurückzuführen ist. Wenn ich zu "Quelle anzeigen" gehe und dieses Fenster aktualisiere , erhalte ich eine davon

AH01964: Connection to child 4 established

...und sonst nichts. All dies geschieht nur für https-Verbindungen. Das Protokoll für http ist stumm.

Ist etwas wirklich falsch? Ich wiederhole, der Inhalt scheint vollständig und korrekt bereitgestellt zu sein, was der Sprache "Lesen fehlgeschlagen" und "Zeitüberschreitung" im Protokoll zu widersprechen scheint. Sind diese Fehler nur Rauschen oder muss ich etwas beheben?

Wie schalte ich sie aus, wenn sie nur harmlose Geräusche sind?

So richte ich alles ein. (Ich habe diesen Prozess stückweise aus verschiedenen Tutorials erhalten, ohne ihn vollständig zu verstehen.)

In / etc / hosts habe ich

127.0.0.1 x.com

Ich habe ein selbstsigniertes SSL-Zertifikat über das folgende Skript erstellt

openssl genrsa -des3 -out x.com.key 2048
openssl req -new -key x.com.key -out x.com.csr
cp x.com.key x.com.key.org
openssl rsa -in x.com.key.org -out x.com.key
openssl x509 -req -days 3650 -in x.com.csr -signkey x.com.key -out x.com.crt
chmod 400 x.com.{key,crt,csr}
sudo chown www-data x.com.{key,crt,csr}
sudo mv x.com.{key,crt,csr} /path/to/website/

Während dieses Vorgangs gebe ich ein

Common Name (e.g. server FQDN or YOUR name) []:x.com

Ich habe sowohl ein <VirtualHost x.com:80>als auch ein <VirtualHost x.com:443>Setup in sites-enabled / 000-default.conf und der Unterschied zwischen ihnen ist dieser Abschnitt:

SSLEngine on
SSLCertificateFile /path/to/website/x.com.crt
SSLCertificateKeyFile /path/to/website/x.com.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog ${APACHE_LOG_DIR}/x.com.ssl.log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Und das haben sie gemeinsam:

LogLevel info
apache-2.2  ssl 
— Spraff
quelle

Antworten:

3

Diese Frage scheint dieselbe zu sein wie diese , die ich offensichtlich bei der Diagnose derselben gefunden habe.

Das Problem wird dadurch verursacht, dass anstelle einer IP-Adresse ein Name basierend (oder ein Platzhalter-Catchall) auf einen VirtualHost festgelegt wird. Das Problem besteht darin, dass der Domänenname erst nach dem Herstellen der Verbindung an einen Webserver übergeben wird. In diesem Stadium muss die SSL / TLS-Verbindung bereits aktiv sein, sodass der Server den richtigen SSL-Schlüssel basierend auf den verfügbaren Mindestinformationen und auswählen muss Dies ist die IP-Adresse für diesen virtuellen Host.

Auf der Apache-Website finden Sie detailliertere Informationen und Beispielkonfigurationsinformationen. Grundsätzlich möchten Sie jedoch ändern <VirtualHost x.com:443>, <VirtualHost 1.2.3.4:443>wo die IP-Adresse für diesen Host / diese Schnittstelle verwendet wird.

— Ben
quelle
1
Neuere Apache-Versionen verfügen über SNI, das mehrere VirtualHosts auf derselben IP-Adresse zulässt, sodass der Wildcard-Virtualhost funktionieren sollte. Aber leider bleiben diese Info-Nachrichten bestehen.
— etwas
Beeindruckend! Ich habe mich schon eine Weile darüber gewundert. Ich habe die IP-Adresse anstelle des Platzhalters ( *:443) eingegeben und die Warnungen ganz heruntergeschrieben.
— Alexis Wilke
Dies ist in der Tat der Grund. Obwohl 2.4 SNI unterstützt, scheint es zuweilen fehlzuschlagen, wenn die Domäne gleichzeitig mit dem Zertifikat übereinstimmt, wenn zu viele Anforderungen gleichzeitig eingehen. Als ich * auf die IP der Schnittstelle umstellte, stiegen die Anforderungen / Sek. An eine https: // URL im Durchschnitt um 50%, und es traten keine derartigen SSL-Verbindungsfehler auf.
— Unity100
1
Diese Antwort ist nicht korrekt. Ich habe Apache 2.2.15 mit <VirtualHost 1.2.3.4:443> eingerichtet und meine Protokolle sind voll von diesen Fehlern.
— Joe
6

Wie andere gesagt haben, werden diese Nachrichten protokolliert, weil Ihre auf eingestellt LogLevelist info. Wenn Sie diese spezifischen Nachrichten nicht möchten, aber dennoch Ebenenprotokolle möchten info, können Sie dies in Ihrer Apache-Konfiguration neu konfigurieren:

LogLevel info ssl:warn

— Cipriano Groenendal
quelle
1
Fehler: LogLevel verwendet ein Argument, den Grad der Ausführlichkeit bei der Fehlerprotokollierung (Apache-2.2.32). Diese Option ist nur für Apache 2.3 und höher verfügbar. Siehe serverfault.com/a/158369/120479
— Will Sheppard
1

LogLevel info ist höchstwahrscheinlich die Ursache, und es sieht definitiv nach harmlosem Lärm aus.

Gibt es einen bestimmten Grund, warum Sie die Protokollierung auf diese ausführliche Einstellung einstellen müssen, oder können Sie sie auf etwas wie noticeoder warnzurückrufen?

— Shane Madden
quelle
3
Ja, ich kann die Protokollstufe reduzieren, aber a) ich möchte einige Nachrichten auf Informationsebene und b) sie scheinen zu sagen, dass etwas nicht stimmt. Ich möchte es nicht unter den Teppich bürsten.
— Spraff
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.