PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Merkwürdiges Problem mit apache,ssl und jacarta/tomcat



pommes
03.05.04, 17:34
Moin,

hab hier nen Problem und weiß echt nicht mehr weiter:

Also:
1 Rechner (SuSE 8.0, 800 MHz P3, 256MB Speicher)
1 Netzwerkkarte
1 SSL Webserver (1.3.27er Apache)
1 Jacarta/Tomcat System (3.3.x) für Java Servelets
2 IPs (im Folgenden IP1 und IP2) (IP2 ist notwendig für einen SSL Virtual Host)
2 DNS Einträge (im Folgenden DNS1 und DNS2)
eth0 mit IP1 und DNS1
Virtuelles device eth0:0 mit IP2 und DNS2
2 gültige Serverzertifikate der hauseigenen CA (Zert1 und Zert2)
aktuelles Wurzelzertifikat

Ich versuch mal das Problem in Worte zu fassen:
Seit 278 Tagen musste der Rechner nicht mehr rebootet werden - lief so stabil wie sonst nix. Die Apache Konfiguration lief völlig problemlos - man konnte sich mit Client Zertifikat auf beiden Systemen anmelden, alles lief ohne Schwierigkeiten.

Heute morgen liefen dann plötzlich die Anwendungen auf DNS1 nicht mehr. Es kommt eine Meldung, dass Zert2 nicht gültig ist. Auf DNS2 läuft alles problemlos. Aber warum wird denn auf einmal beim Aufruf von DNS1 das Zert2 abgefragt?

Ich habe schon so ziemlich alles überprüft, was mir einfällt, woran sowas liegen könnte.
Die Zertifikate sind allesamt noch gültig (Ende 2005 laufen die erst ab), das Wurzelzertifikat ist ebenfalls aktuell. Der httpd läuft, die java Prozesse sind ebenfalls da. Die Conf ist mMn wasserdicht, sie lief ja fast ein Jahr ohne Schwierigkeiten.
Die Conf Files waren vom Datum her auf dem erwarteten Stand vom August letzten Jahres (es hat also auch niemand dran rumgepfuscht). Ich bin mit meinem Latein echt am Ende.

Das Beschrieben passiert gleichermaßen auf allen der folgenden Systeme:
Windows von IE4 bis IE6, Linux, Solaris, mozilla 1 bis 1.6, firefox, netscape
alles getestet
mit und ohne client zert
mit gültigem und ungültigem client zert

Falls irgendjemand eine Idee hat, soll er sie bitte mal posten.
cheers,
pommes

pommes
04.05.04, 17:08
ich schieb den Thread hier mal.

mitlerweile haben wir einige neue Erkenntnisse:
ohne client zertifikat ist DNS2 mit der alten Conf funktionsfähig - aber halt nur als guest, nicht als angemeldeter user
mit client zertifikat bekommt man keine seite - man wird zwar gefragt, welches client zert man vorlegen will, aber dann passiert einfach nichts mehr

neue überlegung war einfach 2 httpd.conf dateien zu bauen und dann einmal mit httpd -f conf1 und einmal mit httpd -f conf2 zu starten
das klappt aber nicht, weil sich dann die ports in die quere kommen
da basteln wir aber noch dran rum

dass der Rechner nicht gehackt worden ist ist ziemlich sicher, netstat liefert genau die gleichen Ergebnisse wie ein nmap von außen - da ist also alles sauber und es laufen auch keine Prozesse, die nicht laufen sollten

pommes
06.05.04, 05:58
es lag interessanterweise an einer fehlerhaften /etc/hosts:

DNS1 IP1
DNS1 IP2

kann ja nicht klappen...

komisch nur, dass die sich ja nicht von selbst ändert, und die 3 Leute mit root Berechtigung "schwören", nichts dran geändert zu haben

pommes
07.05.04, 08:54
ich muss nochmal antworten - vielleicht interessiert das ja doch jemanden

bei der Einrichtung von eth0:0 ist hinterher ein SuSEconfig gelaufen und das hat die /etc/hosts geändert
nach dem Motto: oops, ich hab ja ne neue IP Adresse - also adde ich die mal und setze meinen hostnamen dahinter

ohne reboot macht das nix, weil die Datei nicht neu eingelesen wird, nach dem reboot war's dann aber geschehen...

art
07.05.04, 10:23
auch wenn du hier einen monolog geführt hast - das problem und die lösung dazu sind intressant ... merken

mfg
art

pommes
07.05.04, 11:26
deswegen habe ich das ja gepostet :)
zum Mäusemelken...

wicking
07.05.04, 14:24
Ja danke auch. Wie immer eine ganz einfache Sache. Man sucht SONSTWAS nach Fehlern ab, und dann ist es einfach nur ein falscher Eintrag in der /etc/hosts, der durch ein blödes Konfikurationswerkzeug automatisch erzeugt wurde. ts ts ts...blöde automatisierung

pommes
09.05.04, 07:28
Ja danke auch. Wie immer eine ganz einfache Sache. Man sucht SONSTWAS nach Fehlern ab, und dann ist es einfach nur ein falscher Eintrag in der /etc/hosts, der durch ein blödes Konfikurationswerkzeug automatisch erzeugt wurde. ts ts ts...blöde automatisierung
beim nächsten fälligen Update auf dem Server (und das wird bald sein (ungepatchtes suse8 :rolleyes: )) kommt da auch nicht wieder suse drauf...