Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 32763 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.
Parents
  • 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!
Reply
  • 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!
Children
No Data
Unfiltered HTML