Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Certificate revocation list dont work with intermediate certificate

    Scheduled Pinned Locked Moved Deutsch
    4 Posts 2 Posters 777 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • E
      Eisenwerk
      last edited by

      Hallo Zusammen,

      bevor ich zum eigentlichen Thema komme ein paar Worte vorweg:
      Ich nutze pfSense seit über 10 Jahren und finde die Software schlichtweg super!
      Ein Dank an Alle die dieses Projekt entwickelt haben und weiter entwickeln.
      Ich habe eine PKI mit mehreren Zwischenzertifizierungsstellen unteranderem je eine für openVPN und freeRadius. Wenn ich die entsprechende CRL einbinde funktioniert diese nicht. User mit Zertifikaten die auf der CRL stehen können sich weiterhin authentifizieren. Eine CRL funktioniert nur in Verbindung mit einer RootCA
      Also bin ich auf die Suche gegangen und konnte mir helfen in dem ich in der Datei
      /usr/local/share/openssl_x509_crl/X509_CERT.php die Zeile 93 von

      $subject = $cert_root->content[0]->content[$is_v1 ? 4 : 5];
      

      auf

      $subject = $cert_root->content[0]->content[$is_v1 ? 2 : 3];
      

      geändert habe.
      Die Änderung muss ich nach jedem Update wieder vornehmen… vergessen inbegriffen.
      Ob es die richtige Lösung für das Problem ist bin ich mir natürlich nicht sicher.

      JeGrJ 1 Reply Last reply Reply Quote 0
      • JeGrJ
        JeGr LAYER 8 Moderator @Eisenwerk
        last edited by

        @eisenwerk Hallo :)

        Verstehe aber nicht ganz, wo genau das Problem liegt?

        • Ist die CA auf der pfSense erstellt oder erstellst du die extern?
        • Gleiches für die CRL?
        • Hast du die CRL importiert oder was meinst du mit einbinden? Ist die CRL passend zum Root oder Intermediate eingerichtet/importiert, wird das im CA Manager auch ordentlich angezeigt und hat die CRL Inhalt?
        • Ist die CRL dann auch dort ausgewählt und hinterlegt, wo sie genutzt werden soll (Radius, OpenVPN etc. haben da eigene Einstellungen für)

        Ob es die richtige Lösung für das Problem ist bin ich mir natürlich nicht sicher.

        Klingt im ersten Moment erstmal nicht so, denn das würde heißen, dass da Content Array Inhalte falsch sind und du andere Elemente brauchst. Ich kenne den genauen Kontext im PHP jetzt nicht, was da geparsed wird, aber das würde in Richtung falsche/fehlende Kette/Intermediate etc. deuten.

        Wenn das falsch wäre, müsste man da nen Bugreport ins CA/Zert Forum schreiben und/oder das im Redmine reinpacken, da würde ich aber erstmal das vorher im Forum gegenprüfen, ob das andere reproduzieren können.

        Ich habe mit einer simplen 2-stufigen CA bislang noch keine Probleme gehabt:

        • Master CA
        • VPN CA / Web CA
        • Server Cert gg. entsprechende VPN/Web CA gebaut
        • User Certs gg. VPN CA gebaut
        • CRLs für entsprechende Unter-CAs erstellt und in den Servern eingestellt

        Wenn da ein User-Cert gepullt wurde via CRL dann kann der sich auch nicht mehr einloggen. Userlogin geht dann zwar durch, aber Cert wird abgelehnt. Könnte ich aber mal durchspielen und nochmal testen, da bräuchte ich aber mehr Details wie da CA/Intermediate/Certs gebaut und eingespielt sind.

        Cheers

        Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

        If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

        1 Reply Last reply Reply Quote 0
        • E
          Eisenwerk
          last edited by

          Hallo,

          Danke für die schnelle Rückmeldung!

          Die komplette PKI ist auf einer eigenständigen pfSense Instanz erstellt und wird dort auch richtig angezeigt.
          Die PKI ist drei Stufig:
          RootCA -> UserCA -> VpnUserCA
          Auf einer anderen pfSense, wo der openVPN Server läuft, habe ich das RootCA CERT und das UserCA CERT importiert. Das VpnUserCA CERT habe ich mit KEY importiert und dort dann die CRL erstellt.

          Mit einbinden meine ich im ovpnServer unter dem
          'Punkt Peer Certificate Authority' die VpnUserCA
          und unter
          'Peer Certificate Revocation list' die VpnUserCRL.

          Die CRL beinhaltet einige CERTs, ist also nicht leer.

          Meine Änderung ist ja schon ne Weile her, seit dem ändere ich das File nach jedem update und habe es nie wieder gegen getestet.
          Ich werde versuchen mir morgen auf der Arbeit etwas Zeit zu nehmen um alles noch mal zu reproduzieren.
          Ich melde mich wenn ich Ergebnisse habe.
          Grüße

          1 Reply Last reply Reply Quote 0
          • E
            Eisenwerk
            last edited by

            Moin,

            ich konnte das Problem nachstellen, wie schon geschrieben mit einer drei stufigen PKI.
            Ich habe mein CERT auf die CRL gesetzt mit der Änderung

            $subject = $cert_root->content[0]->content[$is_v1 ? 2 : 3];
            

            konnte ich mich nicht mehr anmelden, aus dem VPN Log:
            10.0.2.254:37410 VERIFY ERROR: depth=0, error=certificate revoked: CN=XXX, C=DE, ST=XXX, L=XXX, O=XXX, OU=XXX, serial=1

            dann habe ich die original Zeile wieder hergestellt

            $subject = $cert_root->content[0]->content[$is_v1 ? 4 : 5];
            

            die openVPN instanz neu gestartet und ich konnte mich anmelden.

            Kann es vieleicht daran liegen dass von den übergeordneten CAs nur die CERTs imortiert sind, müssen auch die CRLs importiert werden damit der VPN Server die komplette Kette zurückverfolgen kann?

            Werde ich morgen Testen.

            Grüße

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.