PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Apache2, SSL, Debian Sarge



LKH
31.01.05, 09:30
Hi,

am Wochenende hatte ich einen Webserver unter Debian Sarge neu aufgesetzt. Für die administrativen Backends hatte ich einen virtuellen Host mit SSL eingerichtet. Nach der Verbindungsaufnahme über HTTPS kam vom Firefox gleich die Meldung bzgl. des Zertifikats (stimmt, ich bin keine vertrauenswürdige CA). Danach erschien dann die schlichte Willkommensseite.

Nun zum Problem: jeder weitere Seitenaufruf über HTTPS dauerte ca. 10 Minuten. Es gab keinen Timeout, die Logs schwiegen sich ebenfalls aus (nachdem die Seite dann aufbaut war, stand im access.log ganz normal die 200). netstat zeigte die gesamte Zeit eine Verbindung zwischen Client und Host auf Port 442 an. Der Apache schickte aber keine Daten. Lokal auf dem Server war das Problem identisch: ein "telnet localhost 443" antwortete auf ein GET auch erst nach ca. 10 Minuten. Ein Neustart des Apache brachte nur einmal einen Erfolg, dann aber auch nur für den ersten Seitenaufruf.

SSL mit dem Apache2 wird unter Debian durch inkludieren der Dateien ssl.load und ssl.conf erreicht. Diese Dateien befinden sich unter /etc/apache2/mods-available. Aktiviert werden die Module durch Setzen von Symlinks in das Verzeichnis /etc/apache2/mods-enabled. Inhaltlich waren die Dateien in Ordnung.

In den Debian-Listen findet sich viel zu Sarge und Apache2 mit SSL, allerdings hatten die da alle andere Probleme. Ich hatte dan das "Listen 443" mal direkt in die ports.conf geschrieben. Nach einem Neustart des Apache meckerte dieser, dass der Port schon in Benutzung sei. Dann hatte ich den Eintrag wieder gelöscht, den Apache neu gestartet und seitdem gehts. :D

Nun endlich zur Frage: hat jemand eine Ahnung, was das Problem sein könnte? Ohne irgendwelche Meldungen tue ich mich sehr schwer. Was gibts denn noch für Tools um rauszubekommen, was da läuft? Bei einem Produktivsystem kann ich ein solches "geht mal/geht mal nicht" nicht verantworten ...

Danke im voraus,

LKH

Tomek
31.01.05, 09:42
Hmm, ich habe ebenfalls Sarge mit Apache2 und SSL im Einsatz. Ohne Probleme.

Ich poste mal paar Daten von mir, vielleicht hilft es dir weiter.


$ COLUMNS=200 dpkg -l|egrep 'apache|ssl'|grep -v courier
ii apache-common 1.3.33-3 support files for all Apache webservers
ii apache-dev 1.3.33-3 development kit for the Apache webserver
ii apache-utils 1.3.33-3 utility programs for webservers
ii apache2-common 2.0.52-3 Next generation, scalable, extendable web server
ii apache2-mpm-prefork 2.0.52-3 Traditional model for Apache2
ii apache2-prefork-dev 2.0.52-3 Development headers for apache2
ii libapache2-mod-auth-mysql 4.3.9-1 Apache 2 module for MySQL authentication
ii libapache2-mod-auth-plain 2.0.48-4-2.1 Module for Apache2 which provides plaintext authentication
ii libapache2-mod-perl2 1.999.20-1 Integration of perl with the Apache2 web server
ii libapache2-mod-php4 4.3.10-3 server-side, HTML-embedded scripting language (apache 2.0 module)
ii libapache2-mod-security 1.8.4-1.1 Tighten the Web application security for Apache 2.x
ii libio-socket-ssl-perl 0.96-1 Class implementing an object oriented interface to SSL sockets
ii libnet-ssleay-perl 1.25-1 Perl module for Secure Sockets Layer (SSL)
ii libssl-dev 0.9.7e-2 SSL development libraries, header files and documentation
ii libssl0.9.7 0.9.7e-2 SSL shared libraries
ii openssl 0.9.7e-2 Secure Socket Layer (SSL) binary and related cryptographic tools
ii ssl-cert 1.0-11 Simple debconf wrapper for openssl

$ cat /etc/apache2/ports.conf
Listen 80
Listen 443

$ ls /etc/apache2/mods-enabled/
auth_digest.load auth_plain.load headers.load info.load mime_magic.load php4.load ssl.conf
auth_mysql.load expires.load include.load mime_magic.conf php4.conf rewrite.load ssl.load

$ cat /etc/apache2/mods-enabled/ssl.load
LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so

$ cat /etc/apache2/mods-enabled/ssl.conf
<IfModule mod_ssl.c>
# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the SSL library.
# The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
#
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed startup file:/dev/urandom 512
#SSLRandomSeed connect file:/dev/random 512
#SSLRandomSeed connect file:/dev/urandom 512

# Some MIME-types for downloading Certificates and CRLs
#
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl

# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program (`builtin' is a internal
# terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog builtin

# Inter-Process Session Cache:
# Configure the SSL Session Cache: First the mechanism
# to use and second the expiring timeout (in seconds).
#SSLSessionCache none
#SSLSessionCache shmht:/var/run/apache2/ssl_scache(512000)
#SSLSessionCache shmcb:/var/run/apache2/ssl_scache(512000)
SSLSessionCache dbm:/var/run/apache2/ssl_scache
SSLSessionCacheTimeout 300

# Semaphore:
# Configure the path to the mutual exclusion semaphore the
# SSL engine uses internally for inter-process synchronization.
SSLMutex file:/var/run/apache2/ssl_mutex
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSL v2:+EXP:+eNULL

# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
SSLCACertificateFile /etc/ssl/certs/rootCA.crt

</IfModule>
Danach ein paar VHosts erstellen (Beispiel):

$ cat /etc/apache2/sites-enabled/000-default
ErrorLog /var/log/apache2/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog /var/log/apache2/access.log combined

ServerSignature On
ServerTokens Prod

NameVirtualHost 199.199.199.199:80

<VirtualHost 199.199.199.199:80>
Servername domain1.de
ServerAlias www.domain1.de
DocumentRoot /var/www/domain1.de/
[...]
</VirtualHost>

<VirtualHost 199.199.199.199:80>
Servername domain2.de
ServerAlias www.domain2.de
DocumentRoot /var/www/domain2.de/
[...]
</VirtualHost>


NameVirtualHost 199.199.199.199:443

<VirtualHost 199.199.199.199:443>
Servername domain1.de
ServerAlias www.domain1.de
DocumentRoot /var/www/domain1.de/
[...]
</VirtualHost>

<VirtualHost 199.199.199.199:443>
Servername domain2.de
ServerAlias www.domain2.de
DocumentRoot /var/www/domain2.de/
[...]
</VirtualHost>

Tomek
31.01.05, 09:46
Was du noch machen könntest, ist das Loglevel zu erhöhen:

LogLevel debug

LKH
31.01.05, 10:04
Hi,

danke für die Infos. Ich werde mal den Loglevel erhöhen. Zuerst hatte ich "SSLRandomSeed" in Verdacht (da steht ja auch was bzgl. "long connection time"), aber egal welche Variante ich einstellte, das Phänomen blieb gleich.

Um vor Überraschungen geschützt zu sein, hatte ich das System mit gleicher Konfiguration zuvor lokal aufgebaut. Da lief alles sofort ohne Probleme. Ich dachte mir schon "Prima, in 15 Minuten fertig!" :ugly:

Hätte man was anständiges gelernt, müsste man sich nicht mit Computern rumschlagen ...

LKH

Tomek
31.01.05, 10:21
Eine Idee hätte ich noch...

Und zwar: In irgendeiner Firefox-Version, ich glaube 0.9.irgendwas, gabs mal Probleme mit SSL-Verbindungen. Das funktionierte schlecht bzw. gar nicht. Vielleicht hast du ja Firefox 0.9.x?

LKH
31.01.05, 10:41
Hi,

ich hab zwar den 1.0er Firefox, aber um Clientprobleme auszuschließen hatte ich auch andere Browser auf anderen Maschinen genutzt. Selbst lokal, wie geschrieben, bestand das Problem. Ich hatte den Apache in der Zwischenzeit (nachdem es ging) x-mal wieder neu gestartet. Problem weg, mulmiges Gefühl bleibt ...

LKH