OPNsense SSO einrichten - letsencrypt Zertifikat

Hallo!

Ich versuche Single Sing-On SSO auf dem OPNsense einzurichten.
Beim Prüfen erhalte ich aber eine Fehlermeldung „Authentifizierung fehlgeschlagen“.
Unter Protokolldateien -> Allgemein ist zu finden:
„opnsense: LDAP bind error [error:14090086: SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate),Can’t contact LDAP server]“

Auf dem Server wurde das selbstsignierte Zertifikat durch ein letsencrypt-Zertifikat ersetzt.
Nun muss ich sicherlich dem OPNsense dieses mit auf den Weg geben.
Wie muss ich vorgehen?

Gruß - Rainer

Hallo Dominik! @foer

Du hast das sicherlich schon umgesetzt. Hast du mir eine kurze Anleitung, dann muss ich nicht lange suchen und/oder probieren.

Gruß - Rainer

Hallo Rainer,

ich bin dieses Problem noch nicht angegangen.
Nur so ins Blaue…unter System-Sicherheit-Aussteller die chain.pem von letsencrypt importieren. Dann unter System-Zugang-Server ldapzugang bearbeiten und unter Peer-Zertifizierungsstelle das neue Zertifikat auswählen und dann speichern. Dann kannst du unter System-Zugang-Prüfer schauen ob es klappt…

LG Dominik

…klappt bei mir nicht…hast du das hinbekommen? Wenn ich die Auth auf Standart TCP stelle klappts.

Weiß sonst jemand, warum die Opnsense das letsencrypt RootCA nicht akzeptiert?

Gruß
Dominik

Hallo Dominik!

Nach über 2 Tagen Suche habe ich seit heute eine Lösung:

OPNsense → System → Sicherheit → Aussteller → hinzufügen

letsencrypt-Zertifikat quersigniert von IdenTrust (siehe
https://letsencrypt.org/de/certificates/)
(/usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt)

  • Beschreibender Name: le
  • Vorgehen: Eine existierende Zertifikatsstelle importieren
  • Zertifikatdaten: Inhalt von
    /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt oder aus
    Internet (https://www.identrust.com/dst-root-ca-x3) per copy & paste
    einfügen
  • Private Key des Zertifikats: leer lassen
  • Serial für nächstes Zertifikat: 1
    -> speichern.

Anschließend unter OPNsense → System → Zugang → Server:
Servername: linuxmuster → bearbeiten
Peer-Zertifizierungsstelle auf „le“ ändern (siehe oben)
-> speichern

Bei mir hat es erst funktioniert, als ich zuerst ohne Verschlüsselung (TCP), dann mit StartTLS und dann erst mit SSL verschlüsselt gespeichert habe. Vielleicht hätte es StartTLS nicht gebraucht oder wäre auch ein Neustart gegangen?

Gruß - Rainer

1 Like

Hallo Rainer,

mega das versuche ich nach dem Urlaub!

Leider haben sie bei Untis irgendwas geändert und der Login geht nicht mehr…ging jetzt seit zwei Wochen mit dem Letsencrypt Zert problemlos…wie ist das bei dir?

LG Dominik

Hallo Dominik!

Untis ist noch nicht auf dem Plan.
Aktuell funktioniert mit dem AD:

  • Linuxclient
  • nextcloud
  • wiki
  • webUI
    Fehlt noch:
  • moodle (BelWue) und
  • Untis (wird bisher nur von Lehrern benutzt und hat daher noch eine eigene Benutzerverwaltung)

Ich wünsch dir einen schönen Urlaub. Du wirst ihn genauso brauchen wie ich nach der Einrichtung der 7. :wink:

Gruß - Rainer

Hallo, Rainer,
hallo, Dominik,

ich habe das gleiche Problem, bedauerlicherweise lies sich das nicht durch die von Rainer vorgeschlagene Lösung beheben.

Ich bin wie beschrieben vor gegangen, das andere Zertifikat anzuwenden, erhalte aber unterschiedliche Fehlermeldungen, je nach verwendeter Transport Option:

  • TCP - Standard
    opnsense: LDAP bind error [80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1,Invalid credentials]

  • StartTLS
    opnsense: Could not startTLS on ldap connection [error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate),Connect error]

  • SSL Verschlüsselt
    opnsense: LDAP bind error [error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate),Can’t contact LDAP server]

Ich habe das Passwort für den Nutzer extra zuvor nochmal neu gesetzt, um sicher zu gehen, dass es nicht daran liegen kann.

Die Fehlermeldungen habe ich so den Protokolldaten -> Allgemein entnommen.

Habt ihr eine Idee, was ich sonst noch versuchen kann?

Beste Grüße,
Maik

P.S.: Ich bin mir bewusst, dass das Zertifikat nur auf verschlüsselte Transport-Protokolle Einfluss hat, habe aber zu jedem mal die Anmeldung versucht, da meines Erachtens ein Gesamtbild oft bei der Fehlersuche Hilft. Unter TCP bedeutet das „data 52e“ für mich, dass Nutzername korrekt ist, aber PW falsch, das habe ich jedoch direkt zuvor nochmal gesetzt, um sicher zu gehen.

Edit: die Fehlermeldung im TCP ist auch dann die gleiche, wenn ich einen nicht vorhandenen Nutzer versuche.