Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 32761 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN - Certificate Validation Issue

DanielHeim
Greetings,

I'm trying to set up SSL Remote Access,but I'm stuck on certificates.

We have a windows based PKI with 
an Offline Root CA > Root CA and an issuing enterprise CA > ADM1CA.

The client PC that tries to connect has both certificates installed.
Root CA > Local Machine > Trusted Root CA
ADM1CA > Local Machine > Intermediate CA

On our UTM i installed ADM1CA as CA with private key.

The SSL Installer delivers two certificates:
utm..ca
utm..user

Both certificates look valid.

But while trying to connect, certifcate validation fails. 

Wed Sep 16 08:29:33 2015 TLS: Initial packet from [AF_INET]80.152.58.170:443, sid=419cac96 6d346704

Wed Sep 16 08:29:33 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

Wed Sep 16 08:29:33 2015 VERIFY ERROR: depth=1, error=unable to get local issuer certificate: DC=de, DC=, CN=ADM1CA

Wed Sep 16 08:29:33 2015 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Wed Sep 16 08:29:33 2015 TLS Error: TLS object -> incoming plaintext read error

Wed Sep 16 08:29:33 2015 TLS Error: TLS handshake failed


Any ideas on how to resolve this issue?


This thread was automatically locked due to age.
  • 0
    Hello, dheim, and a belated welcome to the User BB!

    unable to get local issuer certificate: DC=de, DC=, CN=ADM1CA
    SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

    Yes, it looks like you do have a problem.  Were the User certs generated using the same Signing CA as the cert specified in 'Server certificate' on the 'Advanced' tab?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    An intermediate CA cannot be used to issue VPN certs within Sophos, unless you manually modify the openvpn.conf-default file [/var/sec/chroot-openvpn/etc/openvpn] to not use certificate attributes for TLS authentication and instead use a TLS key.  

    When an ICA issues a VPN certificate, the CA that signed the ICA will be the CN of the VPN cert, thus failing TLS authentication, since the CN must be the Sophos user's name (if openvpn.conf-default is left as is).

    Hello, dheim, and a belated welcome to the User BB!


    Yes, it looks like you do have a problem.  Were the User certs generated using the same Signing CA as the cert specified in 'Server certificate' on the 'Advanced' tab?

    Cheers - Bob

    It wouldn't matter, as it's an intermediate CA, which cannot be used with Sophos's default OpenVPN server config
  • 0 in reply to BAlfson
    Hello, dheim, and a belated welcome to the User BB!


    Yes, it looks like you do have a problem.  Were the User certs generated using the same Signing CA as the cert specified in 'Server certificate' on the 'Advanced' tab?

    Cheers - Bob

    It wouldn't matter, as it's an intermediate CA, which cannot be used with Sophos's default OpenVPN server config
  • 0
    Thanks, JW. That's what I missed when I went straight to the log without reading the explanation.  I haven't tried using a CA and a cert with an Intermediate CA with OpenVPN - are you saying that it can't work, or only that he would have been successful if he also had installed the Root CA?

    Cheers - Bob
    PS I've seen your other recent posts about OpenVPN.  It's good to have you around!
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Thanks, JW. That's what I missed when I went straight to the log without reading the explanation.  I haven't tried using a CA and a cert with an Intermediate CA with OpenVPN - are you saying that it can't work, or only that he would have been successful if he also had installed the Root CA?

    Cheers - Bob
    PS I've seen your other recent posts about OpenVPN.  It's good to have you around!

    Thanks! =]

    With the default server config, an intermediate CA cannot be used as the default server config uses the user's vpn certificate attributes for TLS authentication... mainly the CN, which, in order for TLS to authenticate, must be the user's username.  If an intermediate CA is installed, every cert the VPN CA generates will have the CN be the name of the root CA that signed the intermediate CA, thereby failing TLS authentication.

    • Even if Sophos's default server config didn't utilize this specific type of TLS authentication, it's extremely insecure to use the same CN for more than one certificate.


    He can however edit the openvpn.conf-default and change the TLS authentication parameters to something else, such as a TLS key... however, I believe doing so would remove the ability to authenticate with a username and password.  I'm not 100% on that, as I've always used a TLS key until I installed Sophos UTM a week ago.  Normally, configuring the server config for username/password authentication is discouraged because the password has to be stored in plaintext form on the router, however my assumption (as I haven't had time to look into this specific part) is Sophos is able to accomplish this without plaintext passwords due to Sophos using the same username and passwords for user portal login (if I recall right, this also has something to do with the CN of vpn certs being the user's username).

    What I'm not sure about is if vpn certs were generated by an ICA on another device and then imported into Sophos, would the CN be the name of the signing root CA or would the end user be able to set a specific CN.
  • 0
    Hello chaps- apologies for bringing this thread back after so long, but I've reproduced this problem and thought it worth revisiting.

    After reading JW0914_01's comments, I went back over the configs, and noticed a couple of things when looking over the certs.
    The CNs are all correct that I can see- server cert has the FQDN in CN, user cert has user name in CN, issuers match the whole DN of the next cert up, and so on. In short, according to what I know about X.509 certs, everything's right and the user and local server certs check out, so this suggests the whole CN mess is fixed in 9.352.

    What is missing is that the root CA isn't included in the package, just the user cert, and VPN signing (intermediate) CA cert that the UTM used to create it. The logs *suggest* it cannot find the issuer of the server cert,
    VERIFY ERROR: depth=1, error=unable to get local issuer certificate: C=uk, <other attributes of the intermediate CA>
    but I defer to those who know OpenVPN better. Is it saying it cannot find that intermediate CA (which is how it reads to me) or saying it cannot find the issuer of that intermediate CA (the not-included root CA)? Log message suggests one thing, logic suggests the other..

    The other thing I noticed is that if an email address is included in the DN of a cert, the OpenVPN client log reports it using the notation emailAddress= rather than the E= that's in the cert when read by most anything else. Is this just an OpenVPN thing?

    I'll have a play with trying to append the root CA to the openVPN client's package, in case, but any other ideas welcome.

    In case it's important, the reason I'm doing this is I have clients who want all server certs replaced with 4096-bit keys and SHA256 or higher signatures.. so if anyone knows how to get the UTM to create user/server certs with longer keys, I'd be happy to hear it!
  • 0
    Update, if I add the root CA to the file <Server>.ca.crt (it's just PEM encoded text, I pasted the certificate block in at the end) then the client checks out OK, and this solves the verify problem previously posted.

    Next issue, the server side error "error=self signed certificate in certificate chain"
    Well, yes, root CAs generally are self signed...
    The offending root CA is listed as a verification CA (it's the same one used by Webadmin) on the CA page.

    Thoughts welcome, my next step is to look at the UTM config to see whether it needs adjusting to understand this self-signed cert. After all, the factory-default VPN CA is self-signed too...
Unfiltered HTML