Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    OpenVPN with a PKI

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 3 Posters 2.5k Views 3 Watching
    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.
    • P Offline
      Pycrs
      last edited by

      Hello,
      I have setup the following PKI: Root CA -> Intermediate VPN CA (signs vpn client certs + the vpn server cert).

      The OVPN profile has the Root CA cert in the <ca/> to verify the server, which works. It then has the client cert alongside the intermediate which signed it.

      The server has its own cert (the cert itself + the VPN intermediary so that clients only need to have the Root to verify it). When it comes to the peer ca configured on the server is where I get confused. I would think it should get set to the Root CA (like the client), that doesn't work, the server is spitting error logs about not being able to verify the depth=0 cert (so the client cert im guessing). When i set it to be the VPN intermediary cert everything works.

      So I guess my question is whats the correct configuration here? Both parties sending their respective certs + the issuers cert and both using the Root to verify? Thanks.

      1 Reply Last reply Reply Quote 0
      • G Offline
        giuliafw70
        last edited by

        For the server side, selecting the VPN intermediate as the peer CA is usually the cleaner setup here. That is the CA that actually issued the client certificates, so OpenVPN can verify the presented client cert directly against the CA you told it to trust.

        Using the root as the peer CA would only make sense if the server also has the intermediate available as part of the trust chain and the verify depth/chain building matches what OpenVPN expects. Even then, I would normally prefer a dedicated VPN intermediate anyway, because it limits that OpenVPN server to certs issued for this VPN purpose instead of anything under the root.

        P 1 Reply Last reply Reply Quote 0
        • P Offline
          Pycrs @giuliafw70
          last edited by

          Alright so then the client only sends their client cert (unlike the server, which is sending the issuer aswell) which simplifies the PKCS bundling but rotating intermediates will require a swap of the peer CA on the server.

          Great, thanks for the help.

          1 Reply Last reply Reply Quote 0
          • P Offline
            Pycrs
            last edited by

            Interestingly enough, the intermediate cert isn't enough for the server. When I supply only it, it complains about not having the root available to verify the intermediate. I would think if i tell it to trust the intermediate using capath it would just disregard anything up the chain. But apparently I have to supply it with both (imported both root and intermediate into a single CA in pfsense).

            1 Reply Last reply Reply Quote 0
            • M Offline
              MalagaFirewall8
              last edited by

              That behaviour is not too surprising. The intermediate is the issuer of the client cert, but OpenVPN still wants to build a complete trusted chain for that intermediate unless the config treats it as an explicit trust anchor. In pfSense, using a CA entry that contains the root plus the VPN intermediate is often the least confusing option. Then keep the server's peer CA scoped to that VPN chain, and set the verify depth high enough for client -> intermediate -> root. I would also avoid putting a broad root-only CA there unless every cert under that root is meant to be eligible for this VPN.

              1 Reply Last reply Reply Quote 0
              • P Offline
                Pycrs
                last edited by

                So all things considered, my situation is relatively speaking a correct configuration right?

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