Certstore issued

[Peter Klett]

Hallo,

lange habe ich mich hier nicht mehr sehen lassen, aber heute habe ich eine Frage, die mir bestimmt beantwortet werden kann.

Auf meinem Domino betreibe ich eine private Webseite, bisher nur http. Doch da ich aus zuverlässiger Quelle gehört habe, dass es jetzt "ganz einfach" sein soll, ein Zertifikat einzubinden, habe ich nun beschlossen, es zu probieren. Was habe ich bisher getan?

Als erstes habe ich Server und Client auf Domino/Notes 14 aktualisiert
CertMgr gestartet, so dass die certstore.nsf erzeugt wird
Darin habe ich nun versucht, gemäß der HCL-Doku die relevanten Dokumente anzulegen.

U.a. habe ich ein TLS Credentials Dokument angelegt und "Submit Request" gestartet

Das Dokument hat nun einen Status ganz oben im Dokument (Main, 1. Zeile) "Issued", aber in der 4. Zeile ein "Valid". Auf der zweiten Seite sind auch diverse Schlüssel eingetragen (PEM)

Irgendwie erwarte ich, dass ich noch Schlüssel oder eine Datei importieren muss. Bekomme ich die noch per Mail, oder muss ich den Schlüssel, der unter PEM eingetragen ist, irgendwohin speichern und importieren? Falls ja alles, oder nur Teile? Denn da sind mehrere Blöcke drin.

Habe Port 443 dem Domino zugeordnet und komme auch schon fast hin. Beim Öffnen über HTTPS bekomme ich ein SEC_ERROR_UNKNOWN_ISSUE, und wenn ich mir das Zertifikat anschaue, ist das von G DATA, von denen läuft auf meinem Server eine Antivirensoftware.

Ich gebe zu, dass ich von diesem Thema überhaupt keine Ahnung habe, bekomme schon Pickel, wenn ich nur daran denke. Aber wäre schon schön, wenn ich das zum Laufen bekäme. Vermutlich fehlt auch garnicht wirklich viel, außer Verständnis :-D

BTW die betroffene Seite ist rein Anonymous ohne irgendwelche Userdaten, daher habe ich bisher keine Notwendigkeit für diesen Zertifikats-Aufriss gesehen, aber neulich habe von einem Benutzer gehört, dass ein Download vom Avira-Browser abgelehnt wurde, weil es keine https-Seite ist (obwohl von der http-Seite ein Link auf einem https-Server gestartet wird).

Bin für jeden Tipp dankbar!

EDIT: Nachdem ich nun auf dem Server den Port 443 auf einen anderen umgestellt und entsprechend im Router zugeordnet habe, komme ich garnicht mehr auf die Seite. Glaube aber, dass das nicht falsch ist, denn das G DATA Zertifikat hat m.E. da garnichts zu suchen ...

[eknori]

https://www.hcl-software.com/blog/domino/tutorial-how-to-secure-domino-using-certmgr-task-letsencrypt/

https://opensource.hcltechsw.com/domino-cert-manager/

[Christian Kröll]

Hallo Peter,

da du wohl ein LetsEncryptCertifikat angefordert hast, musst Du auch nichts mehr in das Zertifikat importieren. Das ist nur nötig, falls Du ein Zertifikat bei einem Dienstleister bestellt hast.

wenn Deine Antivirus-Software am Client den https-Verkehr scant, setzt sie sich zwischen die Verbindung Server-Client. Grund ist, dass zB ein Download aus dem Web nicht erst auf deinem Rechner gespeichert wird und dann erst auf Viren geprüft wird. Die Software taucht dann als eigener CA auf. Das kann dann "G Data", "Bitdefender", "R3" oder ein anderer CA Name sein. Als Test einfach mal mit dem Handy auf deine Seite gehen, da dürfte der Name anders sein oder im Antiviren-Programm des Clients den https-scan abschalten.

Ob das LetsEncyptCertifikat verwendet wird, kannst Du auch über das Gültigkeitsdatum prüfen. Sollte zum Datum im Certificate Store identisch sein.

Woher nun aber das SEC_ERROR_UNKNOWN_ISSUE kommt, kann ich Dir nicht sagen. BTW: ISSUE oder ISSUER?
Du schreibst:

obwohl von der http-Seite ein Link auf einem https-Server gestartet wird

Vielleicht liegt ja hier die Ursache, weil dein neues Zertifikat ein anderes ist als das auf dem https-Server und der Browser deswegen ein Problem mit dem Issuer hat. Aber das ist nur geraten!!!

[Peter Klett]

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

[Christian Kröll]

Der Status "Issued", bei unserer deutschen Maske "ausgegeben" und der Status "Valid" ist richtig.
Das Zertifikat hast Du sicherlich im Credential Store ja auch schon mit "Examine internet certificates" geprüft. Da steht die Zertifikatskette und nach Auswahl eines Eintrags die Details. Ich gehe davon aus, dass das alles passt?

Ich würde in der G-Data den https-Scan mal kurz unterbrechen und schauen, ob dann der Verkehr über 443 überhaupt klappt. Im Serverdokument hast Du sicher den Full Qualified Internet host name gesetzt? Kannst Du an den Server ohne den Router einen telnet auf hostname + Port schicken?
Kann ja nur eine blöde Kleinigkeit sein...

Erstmal trotzdem einen schönen Abend Peter!

[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]

Im Serverdokument hast Du sicher den Full Qualified Internet host name gesetzt?

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

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



 

[Erik Schwalb]

Verständnisfrage: Hat sich Dein Domino Server denn ein TLS Zertifikat von Let's Encrypt geholt...oder (noch) nicht?
Falls ja, dann...
1) prüfe, ob Domino das korrekte Zertifikat verwendet: tell certmgr show certs
2) nimm testweise alle non-Domino Komponenten (Gdata, OS Firewall, etc.) aus dem Spiel und mache den Domino http task für https direkt auf port 443 erreichbar

Falls es dann klappt, kannst Du anschließend wieder Deine Portumleitung, Gdata, etc. aktivieren (one step at a time).

[Peter Klett]

Vielen Dank für die Hinweise. Aktueller Stand ist der, dass es grundsätzlich funktioniert. Das Zertifikat wird bei Beantragung innerhalb 1-2 Minuten bereitgestellt. Zugriff vom Client aus über https://InterneIPAdresseServer:Port funktioniert unter Nutzung des korrekten Zertifikats. Einzig der Port 443 ist von außen überhaupt nicht sichtbar. Es gibt auch keine Portweiterleitung für G DATA, trotzdem lauscht G DATA auf dem Server, auf dem auch der Domino läuft, auf 443, ist auch in der Firewall eingetragen. Ich weiß nicht, wozu das da ist, aber verwendet wird das bei mir definitiv nicht.

Ich hatte bis letzte Woche einen Exchange Server laufen, auf einem anderen Server als dem Domino. Der konnte über 443 angesprochen werden und hatte auch eine entsprechende Weiterleitung im Router (meist war die aber abgeschaltet, weil das S in MS nicht Security heißt). Der Exchange ist nun gestorben, weil die neueste Sicherheitslücke auf meinem Server dazu genutzt wurde, die Warteschlange mit 2500 Phishing Mails vollzuschreiben. Das ist mindestens das zweite Mail, dass meine Maschine einem erfolgreichen Angriff ausgesetzt war, nun ist es genug. Habe meine Postfächer auf ein gehostetes Exchange umgezogen, nicht in die Cloud, das wäre das Letzte, was ich täte. Das hat soweit gut geklappt, und morgen hilft mir ein befreundeter Netzwerker beim finalen Abbau des Exchange, den werde ich auch nach dem Port befragen, wird der schon hinbekommen.

Am G DATA will ich nicht herumfummeln, never change a running System ...

Ich werde berichten, woran es gelegen hat, sobald es läuft, ist sicherlich nur eine Kleinigkeit, die mir nicht auffällt, weil es einfach nicht meine Kernkomptenz ist

[Peter Klett]

So, hier der letzte Stand: Ich gebe es auf. Es schein logisch alles korrekt zu sein, Serverdokument rauf und runter geprüft und alles mögliche ausprobiert, Router ist korrekt, Firewall ok, alles passt anscheinend, aber es läuft nicht.

Dann eben nicht. Wäre schön gewesen, aber habe genug Rest-Lebenszeit damit verschwendet. Für meinen Anwendungsfall ist es nicht zwingend notwendig, lebe ich halt damit. Vielleicht ist es eine der letzten http-Seiten auf der Welt, wäre ja auch mal was besonderes ... 

Allen vielen Dank fürs Mitdenken und die vielen Tipps. Wünsche ein angenehmes Wochenende!

[Peter Klett]

Au Mann, habe es im Zusammenhang mit einem anderen Thema gefunden: am Forti Router reicht nicht alleine die Weiterleitung, es muss auch eine Regel für die Firewall eingetragen werden. Interessanterweise existierte die auch, hatte aber die Weiterleitung geändert. Möglicherweise aktualisiert die Änderung nicht die Firewall. Firewall Regel gelöscht und neu eingetragen, jetzt läuft es

Was für eine schwere Geburt ...