HCL Notes / Domino / Diverses > Administration & Userprobleme
Certstore issued
Peter Klett:
Ah, witzige Fremdsprachenfalle. Issued heißt "ausgestellt", sagt DeepL, ich dachte, es wäre ein "issue" damit, habe das also als Problem übersetzt.
Ok, bleibt die Suche beim Server, warum der auf http reagiert, aber nicht auf https, certstore scheint gut zu funktionieren (wirklich sehr einfach), sieht aus, als wäre ich ganz kurz vor der Lösung ...
Peter Klett:
--- Zitat von: Christian Kröll am 12.03.24 - 18:12:12 ---Im Serverdokument hast Du sicher den Full Qualified Internet host name gesetzt?
--- Ende Zitat ---
Danke für die Übersetzungshilfe, bin ich genau zeitgleich auch drauf gekommen :-D
Würde er ohne den Full Qualified Internet host name auf http reagieren und nur nicht auf https?
Ich schaue morgen mal weiter
Peter Klett:
Heute früh mit sehr professioneller Hilfe weiter gemacht, aber nach 1,5 Stunden läuft es noch nicht. Das wurde erkannt/geändert
Das Noteslog bemängelte beim Start des http tasks ein kyr file, wie im Serverdokument angegeben kyrfile.kyr. In der certstore.nsf wude dann das Credentials Dokument gelöscht und neu angelegt, zusätzlich das kyr file eingetragen und angefordert. War eine Minute später da (das funktioniert wirklich gut). Start des http loggt kein fehlendes kyr file mehr
Am Server fehlte die Freigabe für den Port 444 in der Firewall, wurde ergänzt. Wir haben jetzt diesen Zustand:
Am Server ein localhost:444 bringt einen Zertifikatsfehler (logisch), funktioniert dann aber. Im Noteslog steht nichts über den Zugriff. Das verwendete Zertifikat ist korrekt
Am Server ein 10.0.0.3:444 funktioniert genauso (interne IP Adresse des Servers)
Am Client ein 10.0.0.3:444 gibt sofort zurück, dass die Seite nicht geöffnet werden kann, im Noteslog werden diese Einträge produziert
--- Code: ---13.03.2024 08:12:54 TLS/SSL connection 10.0.0.29(60695) -> 10.0.0.3(444) failed with rejected unknown record type
13.03.2024 08:12:54 TLS/SSL connection 10.0.0.29(60696) -> 10.0.0.3(444) failed with rejected unknown record type
13.03.2024 08:12:54 TLS/SSL connection 10.0.0.29(60697) -> 10.0.0.3(444) failed with rejected unknown record type
13.03.2024 08:12:54 TLS/SSL connection 10.0.0.29(60698) -> 10.0.0.3(444) failed with rejected unknown record type
13.03.2024 08:12:54 TLS/SSL connection 10.0.0.29(60699) -> 10.0.0.3(444) failed with rejected unknown record type
13.03.2024 08:12:54 TLS/SSL connection 10.0.0.29(60700) -> 10.0.0.3(444) failed with rejected unknown record type
13.03.2024 08:12:54 TLS/SSL connection 10.0.0.29(60701) -> 10.0.0.3(444) failed with rejected unknown record type
13.03.2024 08:12:54 TLS/SSL connection 10.0.0.29(60702) -> 10.0.0.3(444) failed with rejected unknown record type
13.03.2024 08:12:54 TLS/SSL connection 10.0.0.29(60703) -> 10.0.0.3(444) failed with rejected unknown record type
13.03.2024 08:12:54 TLS/SSL connection 10.0.0.29(60704) -> 10.0.0.3(444) failed with rejected unknown record type
--- Ende Code ---
Wenn die Firewall den Zugriff blockieren würde, käme nach meinem Verständnis nichts am Server an. Frage, was ist es dann? Warum reagiert der Server anders, wenn er von einer anderen Maschine aus angesprochen wird? Wir waren beide ratlos (bei mir ist das in dem Umfeld nichts ungewöhnliches ;-) ) und hoffen auf einen Tipp von Euch
Vielen Dank vorab
Christian Kröll:
- Habt Ihr geprüft, ob im Serverdokument die TLS ciphers zum Zertifikat im Store passen? (https://www.ssllabs.com/ssltest/)
- Der Client mag einen zu hohen TLS Cipher nicht unterstützen. Dann muss am Server auch der niedrigere aktiviert sein. Dazu braucht es dann aber auch einen notes.ini Eintrag
Das muss alles zueinander passen
Infos u.a. hier: https://blog.nashcom.de/nashcomblog.nsf/dx/tls-ciphers-in-domino-14.0.htm
Peter Klett:
Vielen Dank,
ein Schritt weiter: habe nun alle Ciphers im InternetSite Dokument aktiviert und den INI Eintrag USE_WEAK_SSL_CIPHERS=1 gesetzt, beim Neustart des Servers loggt er auch, dass diverse Ciphers nun durch den Eintrag enabled sind. Vom Client komme ich dadurch mit 10.0.0.3:444 auf die Seite, natürlich mit Zertifikatfehler, es wird das korrekte Zertifikat ausgegeben.
Von draußen passiert aber nichts. ssllabs sagt: Assessment failed: Unable to connect to the server, auch bei abgeschalteter Firewall
Die Portweiterleitung kann eigentlich nicht falsch sein. Hatte bisher eine für 443, die auf einen Exchange-Server geleitet wurde, der wird abgebaut und ich habe in dem Eintrag nur den Server geändert und die Umleitung auf den Port 444 wg. G DATA, die 443 auf dem gleichen Server schon belegt haben
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln