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



 

- 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

Ein anderes CDN benutzen, wie https://cdnjs.cloudflare.com/ajax/libs/fullcalendar/6.1.11/index.global.min.js


Ich glaub in den xPages kriegt man das mit biegen und brechen nicht hin, weil es für das Script Element kein escape="false" attribut kriegt. Auch über ein WebTheme kriegt man das nicht hin.

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 ...

Vielen Dank für die Antworten, Doku hatte ich schon einiges gelesen, aber keine war so gut verständlich wie das Tutorial.

Danke auch für den Hinweis, dass nichts zu im- oder exportieren ist. also sollte es eigentlich so aus der Box heraus funktionieren.

Habe nun die Credentials gelöscht, neu angelegt und neu angefordert. Der DNS-A-record sollte nach meinem Verständnis in Ordnung sein, ist ja nur eine Zuordnung einer Domain zu einer IP-Adresse. Domain stimmt, IP auch.

Habe dann am Router die 443 auf die 443 umgeleitet und im Serverdokument https auf 443 gesetzt (enabled war es schon), erhalte dann wieder den Zertifikatsfehler mit Ausweis des G DATA Zertifikats, Gültigkeitsdauer 1000 Jahre.

Also wieder rückwärts, Router gibt 443 weiter auf 444, Serverdokument auf 444 geändert. Daamit komme ich nicht weiter.

Ich sehe zwei Möglichkeiten:

1. irgendetwas muss am Server noch eingerichtet werden, damit er überhaupt auf https hört
2. das Zertifikat ist nicht korrekt eingebunden, es zeigt auch nach dem neuen Versuch ein "Valid" im unteren Status, oben in der ersten Zeile steht wieder "Issued"


Das mit dem Link von der http Seite auf eine andere https-Seite ist hier nicht relevant, der https-Server läuft ganz woanders, war nur eine Erklärung, warum ich schon gerne https für den Domino nutzen würde

Gibt es irgendeinen trick, an den Grund des "Issued" heranzukommen?

Aus dem Log kann ich noch diese Fehlermeldung liefern

12.03.2024 13:21:44   HTTP Server: Error - Unable to Bind port 443, port may be in use or user needs net_privaddr privilege

Das ist vermutlich der G DATA, der auf den 443 lauscht, also wohl korrekt, den Port auf 444 umgebogen zu haben