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

    OpenVPN: OpenSSL: error:140890C7 (peer did not return a certificate)

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 2 Posters 5.8k 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.
    • F
      falcon_lnhg
      last edited by

      I tried to configure a VPN using OpenVPN on my pfSense (latest version 2.4.3-RELEASE-p1 (amd64)), following the guide at: https://vorkbaard.nl/set-up-openvpn-on-pfsense-with-user-certificates-and-active-directory-authentication/

      LDAP authentication works perfectly, as tested from the Diagnostics->Authentication option.

      When I try to connect to the VPN (both on UDP or TCP), the client (Linux, using --verb 3) sees:

      Mon Jul 30 18:19:11 2018 WARNING: file 'server001-tls.key' is group or others accessible
      Mon Jul 30 18:19:11 2018 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2018
      Mon Jul 30 18:19:11 2018 library versions: OpenSSL 1.1.0g  2 Nov 2017, LZO 2.08
      Enter Auth Username: myuser
      Enter Auth Password: ********
      Mon Jul 30 18:19:18 2018 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
      Mon Jul 30 18:19:18 2018 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
      Mon Jul 30 18:19:18 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:1194
      Mon Jul 30 18:19:18 2018 Socket Buffers: R=[87380->87380] S=[16384->16384]
      Mon Jul 30 18:19:18 2018 Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194 [nonblock]
      Mon Jul 30 18:19:19 2018 TCP connection established with [AF_INET]x.x.x.x:1194
      Mon Jul 30 18:19:19 2018 TCP_CLIENT link local: (not bound)
      Mon Jul 30 18:19:19 2018 TCP_CLIENT link remote: [AF_INET]x.x.x.x:1194
      Mon Jul 30 18:19:19 2018 TLS: Initial packet from [AF_INET]x.x.x.x:1194, sid=65axx884 644xxa2a
      Mon Jul 30 18:19:19 2018 VERIFY OK: depth=1, C=US, ST=Texas, L=Houston, O=HOU Lab, emailAddress=admin@mydomain.local, CN=OpenVPN_CA, OU=Testing
      Mon Jul 30 18:19:19 2018 VERIFY KU OK
      Mon Jul 30 18:19:19 2018 Validating certificate extended key usage
      Mon Jul 30 18:19:19 2018 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
      Mon Jul 30 18:19:19 2018 VERIFY EKU OK
      Mon Jul 30 18:19:19 2018 VERIFY X509NAME OK: C=US, ST=Texas, L=Austin, O=Lab, emailAddress=admin@mydomain.local, CN=vpn.mydomain.local, OU=Testing
      Mon Jul 30 18:19:19 2018 VERIFY OK: depth=0, C=US, ST=Texas, L=Austin, O=Lab, emailAddress=admin@mydomain.local, CN=vpn.mydomain.local, OU=Testing
      Mon Jul 30 18:19:19 2018 Connection reset, restarting [0]
      Mon Jul 30 18:19:19 2018 SIGUSR1[soft,connection-reset] received, process restarting
      Mon Jul 30 18:19:19 2018 Restart pause, 5 second(s)
      

      And the server sees this:

      Jul 30 23:19:18 sverver001 openvpn[35836]: TCP connection established with [AF_INET]y.y.y.y:44294
      Jul 30 23:19:19 sverver001 openvpn[35836]: y.y.y.y:44294 OpenSSL: error:140890C7:SSL routines:ssl3_get_client_certificate:peer did not return a certificate
      Jul 30 23:19:19 sverver001 openvpn[35836]: y.y.y.y:44294 TLS_ERROR: BIO read tls_read_plaintext error
      Jul 30 23:19:19 sverver001 openvpn[35836]: y.y.y.y:44294 TLS Error: TLS object -> incoming plaintext read error
      Jul 30 23:19:19 sverver001 openvpn[35836]: y.y.y.y:44294 TLS Error: TLS handshake failed
      Jul 30 23:19:19 sverver001 openvpn[35836]: y.y.y.y:44294 Fatal TLS error (check_tls_errors_co), restarting
      

      My server config file looks like this:

      dev ovpns1
      verb 1
      dev-type tun
      dev-node /dev/tun1
      writepid /var/run/openvpn_server1.pid
      #user nobody
      #group nobody
      script-security 3
      daemon
      keepalive 10 60
      ping-timer-rem
      persist-tun
      persist-key
      proto tcp4-server
      cipher AES-256-GCM
      auth SHA1
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      client-connect /usr/local/sbin/openvpn.attributes.sh
      client-disconnect /usr/local/sbin/openvpn.attributes.sh
      local x.x.x.x
      tls-server
      server 192.168.100.0 255.255.255.0
      client-config-dir /var/etc/openvpn-csc/server1
      username-as-common-name
      auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user QWN0a12345dG9yeQ== true server1 1194" via-env
      tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'vpn.mydomain.local' 1"
      lport 1194
      management /var/etc/openvpn/server1.sock unix
      push "dhcp-option DOMAIN mydomain.local"
      push "dhcp-option DNS 192.168.0.2"
      push "redirect-gateway def1"
      ca /var/etc/openvpn/server1.ca
      cert /var/etc/openvpn/server1.cert
      key /var/etc/openvpn/server1.key
      dh /etc/dh-parameters.1024
      tls-auth /var/etc/openvpn/server1.tls-auth 0
      ncp-ciphers AES-256-OFB:AES-256-CFB8:AES-256-CFB1:AES-256-CFB
      topology subnet
      

      and my client config is this one:

      dev tun
      persist-tun
      persist-key
      cipher AES-256-GCM
      ncp-ciphers AES-256-OFB:AES-256-CFB8:AES-256-CFB1:AES-256-CFB
      auth SHA1
      tls-client
      client
      resolv-retry infinite
      remote x.x.x.x 1194 tcp-client
      verify-x509-name "vpn.mydomain.local" name
      auth-user-pass
      ca server001-ca.crt
      #cryptoapicert "SUBJ:"
      tls-auth server001-tls.key 1
      remote-cert-tls server
      auth-nocache
      

      x.x.x.x=VPN Server
      y.y.y.y=VPN Client
      mydomain.local=LDAP domain

      Any ideas ? I am currently testing on TCP to make sure the connection is available (client can see port 1194/tcp open) - I could not test that on UDP. Once it works I will switch it back to UDP.

      Please let me know if you need additional information.

      Thank you very much in advance,

      F4

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by Derelict

        I don't see that you have cert or key directives pointing to the client credentials. The server is expecting the client to provide one because it is in tls-server mode:

        To use TLS mode, each peer that runs OpenVPN should have its own local certificate/key pair ( --cert and --key ), signed by the root certificate which is specified in --ca.

        https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

        I am currently testing on TCP to make sure the connection is available (client can see port 1194/tcp open) - I could not test that on UDP. Once it works I will switch it back to UDP.

        PCAP on the server on UDP 1194 and try the connection. If you see the traffic, the port is "open."

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • F
          falcon_lnhg
          last edited by

          From the OpenVPN Export Utility, I generated a ZIP file (Bundled Configurations -> Archive), that contains the following files:

          server001.ovpn
          server001.p12
          server001-ca.crt
          server001-tls.key

          I was trying these yesterday (see above):

          openvpn --config server001.ovpn --verb3
          

          If I try:

          openvpn --config server001.ovpn --verb3 --key server001-tls.key --cert server001-ca.crt
          

          I get:

          Tue Jul 31 14:12:19 2018 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2018
          Tue Jul 31 14:12:19 2018 library versions: OpenSSL 1.1.0g  2 Nov 2017, LZO 2.08
          Enter Auth Username: myuser
          Enter Auth Password: ********
          Tue Jul 31 14:12:26 2018 Error: private key password verification failed
          Tue Jul 31 14:12:26 2018 Exiting due to fatal error
          

          Should have I gotten other files from the server? Am I using these files incorrectly?

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            I would just use the config exporter, generate an inline config, and use the data in there.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • F
              falcon_lnhg
              last edited by

              Thanks for the help ...

              I have not been using Inline, because I get this when trying to generate:

              The following input errors were detected:
              
              Microsoft Certificate Storage cannot be used with an Inline configuration.
              Failed to export config files!
              

              Any suggestions ?

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                The user certificates are in the .p12 file. Try exporting with Microsoft Certificate Storage enabled. You are exporting for Linux, not Windows!

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

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