Zertifikat - Frage zu URI und DNS - ist FQDN auch möglich?

[opnsense_user12123]

Da ich gerade beim erstellen von diversen Zertifikaten bin, wollte ich fragen

Was genau mit URI gemeint ist?
DNS -> ist hier der FQDN gemeint oder nur der Hostnamen?
Ist die Angabe des FQDN bei der Serverzertifikatserstellung möglich?

Bitte um Hilfe!

Danke

[opnsense_user12123]

also ich habe mich versucht schlau zu machen und auch mit opnsense ein root zertifikat erstellt und im Mozilla und für Windows das Zertifikat unter "Vertrauenswürdige Stammzertifikate" installiert.

HTTPS Verbindungen funktionieren einwandfrei....aber


Dann habe ich ein internal server certificat erstellt und bei "Certificate authority" das root zertifikat ausgewählt.
Meine Domain heißt .net

IP: 192.168.3.2
DNS: drucker.net
URI: https://drucker.net
URI: https://192.168.3.2

das wurde aber auf dem Server für den ich das Serverzertifikat installiert habe, nicht akzeptiert.

Wenn ich dann bei "CN" drucker.net eingetragen habe wurde es zwar als sichere Verbindung akzeptiert, aber leider konnte ich die Webseite nicht aufrufen obwohl sicher.

Muss leider sagen, dass das Ganze bei PFsense einfacher funktioniert hat und vorallem etwas logischer war.
Leider gibt es hier auch nirgends eine Erklärung zur richtigen Vorgehensweise bei der Erstellung von Zertifikaten mir OPNsense.

Kann mir jemand weiterhelfen ?

Danke!

[opnsense_user12123]

Ich habe hier einen Forumeintrag gefunden, der genau mein Problem beschreibt.
https://forum.opnsense.org/index.php?topic=1160.msg3172#msg3172

Kann es sein, dass dieses Problem wieder oder noch immer besteht?

[fabian]

bei mir am Server ist ein Let's Encrypt-Zertifikat für verschiedene Hosts. Da sind alle Domainnamen mit "DNS:"-Präfix versehen - wie es auch von OPNsense erstellt wird. Vermutlich stimmt irgendwas anderes mit dem Zertifikat nicht.

[opnsense_user12123]

hab da eine Verständnisfrage!
Was ist der Unterschied zu dem Zertifikatsmanager unter dem Punkt TRUST?

Ich habe das Plugin nun mal installiert!

Kann ich das Plugin aktivieren oder überschreibe ich damit mein selfsigned certificat das ich bereits auf allen clients installiert habe oder funktioniert dieses dann nicht mehr?

[fabian]

Wenn du damit das acme plugin meinst: das überschreibt seine eigenen Zertifikate aber meines Wissens nach keine anderen.

[opnsense_user12123]

nun funktionieren auch die server mit eigenem certifikat ohne Verwendung von Lets Encrypt!

ich musste dazu "Log SNI information only" aktivieren.

Aufgefallen ist mir jetzt, dass nicht mehr alle HTTPS Seiten nun mein Zertifikat verwenden. Nur noch die HTTPS Seiten, die in meinem LAN laufen, wie diverse Server und das WEBGUI des Routers. Vorher haben alle HTTPS Seiten im Internet auf mein Zertifikat zurückgegriffen, außer ich hatte diese in die " SSL no bump sites" Liste eingetragen.


Ist dieses Verhalten nun richtig oder habe ich etwas falsch konfiguriert?
Kann mir jemand den Zusammenhang erklären?
Was genau macht dieses Feature?
Bringt es Nachteile mit sich es zu aktivieren?

[JeGr]

> Meine Domain heißt .net

Im Ernst? Du hast ein Zertifikat für .net ausgestellt oder für drucker.net? Oder *.net?

Egal wie hört sich das für mich zumindest extrem gruselig an! Man "übernimmt" bzw. überschreibt nicht einfach öffentlichen Domainraum. Das führt mindestens an bestimmten Stellen zu seltsamem Verhalten, an anderen zu komischen Seiteneffekten oder sonstigen Grausamkeiten. Statt einem eigenen Stammzertifikat und dann solchen wilden Versuchen, sich eigene .net domains zu bauen, nehme man lieber eine eigene Domain und Lets Encrypt Zertifikate, ab diesem Quartal dann auch mit Wildcards. Dann funktioniert sowas auch überall und immer und nicht nur in dem einen Client der die eigene interne CA importiert hat und sich öffentlich vergebene Domains überschrieben hat.

Nur ein gutgemeinter Rat!

Gruß

[opnsense_user12123]

> Meine Domain heißt .net

Im Ernst? Du hast ein Zertifikat für .net ausgestellt oder für drucker.net? Oder *.net?

Egal wie hört sich das für mich zumindest extrem gruselig an! Man "übernimmt" bzw. überschreibt nicht einfach öffentlichen Domainraum. Das führt mindestens an bestimmten Stellen zu seltsamem Verhalten, an anderen zu komischen Seiteneffekten oder sonstigen Grausamkeiten. Statt einem eigenen Stammzertifikat und dann solchen wilden Versuchen, sich eigene .net domains zu bauen, nehme man lieber eine eigene Domain und Lets Encrypt Zertifikate, ab diesem Quartal dann auch mit Wildcards. Dann funktioniert sowas auch überall und immer und nicht nur in dem einen Client der die eigene interne CA importiert hat und sich öffentlich vergebene Domains überschrieben hat.

Nur ein gutgemeinter Rat!

Gruß

Ne ne...   .net sollte nur als Beispiel dienen. War leider von mir als Beispiel wirklich schlecht gewählt.

[JeGr]

Phew Dann bin ich ja beruhigt

Mein Rat ist auch schon seit Jahren (auch wenn er erst in jüngster Zeit befolgt wird, seit MS und Co endlich auch das gleiche empfehlen), dass man intern/im LAN/zu Hause etc. eine Subdomain einer echten Domain nutzt. Es gibt viel weniger nervendes Gerangel mit allen Komponenten wenn man dann sauber echte Zertifikate ausstellen kann und Zugriffe auch von außen entsprechend sinnvoll nutzbar machen kann anstatt irgendein .home, .lan oder .local (autsch!) zu nutzen und dann am Ende sich mit anderen Problemen herum zu schlagen (.local rumpelt bei Apple/Linux Geräten ziemlich, .box wurde jetzt eine offizielle TLD, bei .lan/.home wird auch schon drüber nachgedacht...)

Gruß