Ich versuche, den https-Dienst auf meiner VirtualBox-Gastinstanz einzurichten, auf der Debian Squeeze und Apache 2 laufen.
Beim Versuch, die Testseite meines virtuellen Hosts in einem Browser von meinem Win7-Hostcomputer aus zu laden, erhalte ich die Fehlermeldung „SSL-Fehler: RX-Datensatz zu lang". Gleichzeitig heißt es im Apache-Fehlerprotokoll "Ungültige Methode in Anforderung \x16\x03\x01" für diese Anfrage. Das Problem hat wahrscheinlich nichts damit zu tun, dass ich Apache in einem VirtualBox-Gast ausführe, aber ich wollte Ihnen das Gesamtbild schildern.
Das wirklich Interessante daran ist, dass ich bereits an einem Punkt angelangt bin, an dem die Site ordnungsgemäß geladen wird, allerdings nur für Anfragen, die von localhost kommen (also aus dem VirtualBox Debian Guest). Ich habe dies mit lynx und wget überprüft, sie funktionieren wie erwartet:
wget https://ssltest.intra/ssl.html
--2013-09-13 07:26:49-- https://ssltest.intra/ssl.html
Resolving ssltest.intra (ssltest.intra)... 127.0.0.1
Connecting to ssltest.intra (ssltest.intra)|127.0.0.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 122 [text/html]
Saving to: `ssl.html.1'
100%[======================================>] 122 --.-K/s in 0s
2013-09-13 07:26:49 (1.94 MB/s) - `ssl.html.1' saved [122/122]
Der Inhalt der gespeicherten Datei ist genau wie erwartet. Wenn ich außerdem versuche, über HTTP im Klartext mit dem Server zu kommunizieren, werde ich zu Recht an einen besseren Ort weitergeleitet:
telnet ssltest.intra 443
Trying 127.0.0.1...
Connected to ssltest.intra.
Escape character is '^]'.
GET /ssl.html
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://ssltest.intra/"><b>https://ssltest.intra/</b></a></blockquote></p>
<hr>
<address>Apache/2.2.22 (Debian) Server at ssltest.intra Port 443</address>
</body></html>
Connection closed by foreign host.
Nachfolgend finden Sie die Konfigurationsdateien (ich habe alles aus der Konfiguration entfernt, bis auf das absolute Minimum, damit diese SSL-Site funktioniert)
ports.conf:
Listen 443
httpd.conf: leer
ssltest.intra: (die Virtualhost-Konfiguration)
<VirtualHost *:443>
ServerName ssltest.intra
ServerAdmin [email protected]
SSLEngine On
SSLCertificateFile /etc/ssl/certs/ssltest.intra.crt
SSLCertificateKeyFile /etc/ssl/certs/ssltest.intra.key
DocumentRoot /var/www/ssltest.intra
Options FollowSymLinks
<Directory /var/www/ssltest.intra/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
php_value error_log /var/www/ssltest.intra/php_errors.log
ErrorLog /var/log/apache2/ssltest.intra.error.log
LogLevel warn
CustomLog /var/log/apache2/ssltest.intra.access.log combined
</VirtualHost>
Ich habe überprüft, dass sich die Zertifikatschlüssel am angegebenen Speicherort befinden und dass es sich um gültige (nicht abgelaufene) Schlüssel für die Domäne handelt. Die obige virtuelle Hostkonfiguration wurde aktiviert durch a2ensite ssltest.intra. mod_ssl wurde aktiviert, Apache2 wurde (mehrmals) neu gestartet. Wenn ich Apache starte, ist dies der Eintrag im Protokoll:
Apache/2.2.22 (Debian) PHP/5.3.3-7+squeeze14 with Suhosin-Patch mod_ssl/2.2.22
OpenSSL/1.0.1e mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations
Es gibt keine Firewall-Regeln, die eine Kommunikation über 443 verhindern würden.
Was vermisse ich?
BEARBEITENAnscheinend hat dies etwas mit der Netzwerkkonfiguration von VirtualBox zu tun. Wenn ich versuche, die Site lokal als 127.0.0.1 zu erreichen, funktioniert alles wie erwartet. Wenn ich versuche, (auch lokal) über die andere NAT-Schnittstelle (192.168.56.10) eine Verbindung herzustellen, wird die Anfrage abgelehnt. Gibt es Tipps, wie man das lösen kann?
Antwort1
Ich vermute, dass mein Fall derselbe ist wie der von user242156 und sehr wahrscheinlich auch der des ursprünglichen Verfassers. Das Problem war, dass meine Konfigurationsdateien in sites-enabled/ tatsächlich nicht gelesen wurden, weil die apache2.conf der Distribution nur sites-enabled/*.conf enthielt und meine Dateien diese Erweiterung nicht verwendeten, da sie beispielsweise unter Ubuntu nicht erforderlich ist.
Die richtige Lösung besteht also darin, ssltest.intra in ssltest.intra.conf umzubenennen oder, wenn das wirklich nicht akzeptabel ist, apache2.conf zu ändern und die Zeile hinzuzufügen IncludeOptional sites-enabled/*.
Antwort2
Hatte das gleiche Problem. In meiner Situation hat die folgende Lösung funktioniert (Apache 2.2/Debian Squeeze)
Es scheint, als wäre die SSL-Konfiguration beim Abhören nicht geladen worden. Nach vielen Versuchen und Fehlern mit der virtuellen Host-Konfiguration habe ich die Konfiguration für SSL in apache2.conf hinzugefügt, anstatt im Teil mit der virtuellen Host-Direktive. Die Ports sind in ports.conf konfiguriert. Danach funktionierte mein SSL ordnungsgemäß. Sieht aus wie ein Sequenzproblem beim Laden der Konfigurationsteile.
Der SSL-Teil wurde am Ende von apache2.conf hinzugefügt.
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/<server certificate filename>
SSLCertificateKeyFile /etc/apache2/ssl/<privatekey filename>
SSLCACertificateFile /etc/apache2/ssl/CaCert.crt
Einträge, die bereits in ports.conf vorhanden sind
# If you just change the port or add more ports here, you will likely also
have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz
Listen 80
<IfModule mod_ssl.c>
# SSL name based virtual hosts are not yet supported, therefore no
# NameVirtualHost statement here
Listen 443
</IfModule>