Zugriff auf EDOMI von Extern mit self signed certificates?

[Crimson]

Hallo zusammen,

ich hoffe ein paar Experten in Sachen SSL und Zertifikaten unter euch können mit weiterhelfen.
Im "Alexa Custom Skill für EDOMI" Thread beschreibt jonofe schön, wie man mit letsencrypt ein Zertifikat erstellt,
um z.B. Amazon den HTTPS Zugriff auf EDOMI zu ermöglichen.

Ich würde nun gerne (zusätzlich) mit Client-Zertifikaten die Authentifizierung für den externen Visu-Zugriff ermöglichen.
Soweit ich weiß ist es mit letsencrypt aber nicht möglich Client-Zertifikate zu signieren.
Also bleibt nur der Weg eine eigene CA zu erstellen, um Zertifikate selbst zu signieren.

Alle Versuche die ich mit Tutorials aus dem Netz hinter mir habe führen aber dazu, dass mir der Browser sagt, die Verbindung sei nicht sicher/privat, usw.
Die Codes sind: ERR_CERT_INVALID oder ERR_CERT_AUTHORITY_INVALID

Die Authentifizierung läuft dort eigentlich immer über den CommonName.
Ich habe rausgefunden, dass man diesen eigentlich seit Ewigkeiten nicht nutzen soll.
Mit einem der letzten Releases wurde die Unterstützung von CommonName im Chrome komplett abgeschaltet.
Seitdem ist SubjectAltName soweit ich das sehe der einzige Weg.
Allerdings schaffe ich es nicht ein Zertifikat zu erstellen, mit dem ich meinen EDOMI-Server erreiche, ohne das der Browser meckert.

Hat das hier schon mal jemand gemacht?

Viele Grüße,
Tim

[DerSeppel]

ERR_CERT_AUTHORITY_INVALID bedeutet, dass dein eigenes CA-Zertifikat nicht als Trusted in deinem Browser hinterlegt ist.
ERR_CERT_INVALID würde vermutlich bedeuten, dass das Cert nicht zur Verbindung passt.

[ThorstenGehrig]

Hier müsste alles stehen: https://knx-user-forum.de/forum/%C3%...hentifizierung

Viel erfolg :-)

(Nachtrag: sehe gerade das es bei mit schon seid 5 Jahren so läuft... wie die Zeit vergeht... - läuft übrigens mit gleicher Konfiguration mittlerweilen mit dem EDOMI- in Verbindung mit Let´s Encrypt... also schau dir nur den Teil mit der PKI und den client Zertifikaten an :-) )

[Crimson]

ERR_CERT_AUTHORITY_INVALID bedeutet, dass dein eigenes CA-Zertifikat nicht als Trusted in deinem Browser hinterlegt ist.

Heißt das, es reicht nicht die erstellte .p12 im Client zu installieren, sondern ich muss zusätzlich auch noch ein weiteres Zertifikat im Browser installieren?

ThorstenGehrig
Ich dachte die Client-Zertifikate müssen von der gleichen CA signiert werden wie das Server Zertifikat. Daher scheidet letsencrypt ja als CA für den Server aus, wenn ich anschließend eine eigene CA für die Clients brauche. Oder habe ich das falsch verstanden und kann tatsächlich für den Server einfach den letsencrypt Teil nutzen und mir anschließend eigene Client-Zertifikate erzeugen?

Viele Grüße,
Tim

[ThorstenGehrig]

Hi Crimson,
das Server-Zertifikat kann von Lets Encrypt sein - das client Zertfifikat von einer Self-Signed PKI... bei mir läuft es genauso.
Auch im Professionellen Kontext kann das sinn machen: eine Webseite mit Symantec Zertifikat aber die User loggen sich mit Client-Zertifikaten der eigenen PKI ein...

Bezüglich des client Zertifikats im Browser: ich bin mir nicht 100 sicher was nötig ist - aber ich habe das Client Zertifikat und das public root zertifikat meiner eigenen PKI importiert & ge-trusted.

Gruß
Thorsten

[Crimson]

Cool, danke Thorsten.
Auf die Idee das einfach mal auszuprobieren hätte ich auch kommen können. ;-)
Ich hab das Server-Zertifikat nun mit letsencrypt erzeugt und mir anschließend die eigene CA für die Client-Zertifikate erstellt.
Funktioniert einwandfrei. Jetzt kann ich weiter konfigurieren.

Viele Grüße,
Tim