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

Validate Server Certificate

Hey guys, reaching out for some much-needed help. Have read similar posts but nothing makes sense to me in them.

I have purchased a certificate as well as created a local active directory certificate server. (All Witchcraft to me)

Have installed them on the sophos XG firewall under Certificates. All working well it appears.

I go to:

Configure -> Authentication -> Servers and set up my SSL/TLS connection to active directory.

Select Test Connection and all is good. 

However, when I select Validate server Certificate I get:

What is the firewall doing here, which server is down or unreachable? Is it my Root CA server that is in active directory? Or is it the domain controller? (CA is install on a Domain Member, not on the domain controller)

Note: Firewalls are not active on the Windows Domain Controller and Domain Members. 

All active directory servers and workstation are on the local network. I don't think I am restricting anything on the local network. Or is there a predefined rule that does?

What am I missing here? Any advice would be greatly appreciated. 

Thankyou. 



This thread was automatically locked due to age.
Parents Reply Children
  • Ok No Luck, there must be a step missing??

    I can connect and authenticate without "Validate server certificate" Ticked. Once Ticked I get the error message below as before.

    ldp can be run on the Active Directory

    ld = ldap_sslinit("localhost", 636, 1);
    Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
    Error 0 = ldap_connect(hLdap, NULL);
    Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
    Host supports SSL, SSL cipher strength = 256 bits
    Established connection to localhost.
    Retrieving base DSA information...
    Getting 1 entries:
    Dn: (RootDSE)

  • Are you using any external certificate on your AD ? As the option "Validate server certificate." is to Validate  the certificate on the external server for a secured connection

    And if not then with that option disabled, the functionality will not be affected, may we know your use case to use the option of validating the certificate ? 

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Global Support & Services 

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case


    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • No, I'm not, AD is using an Internal Cert from the internal CA I thought.  "Validate server certificate" is for the external server? I thought this for TLS comms to AD; a Cert from the internal certificate server (hence why the tutorials get us to setup an internal CA?) I recently purchased a certificate from rapidSSL for my public domain name with wildcard. I thought I installed it correctly as well. So, I have installed the intermediate Certificate for Rapid SSL and the Root Certificate for my internal CA as per: Import a certificate - Sophos Firewall. Sorry I am very green to all this but what to fully understand how its working, greatly appreciate your feed back.  I think I will follow this tonight. It may have something to do with my issue perhaps: (+) Sophos xg can't resolve own hostname and internal server - Discussions - Sophos Firewall - Sophos Community (They seem to have the CN issue as well).

  • Would you know what "client" on the sophos firewall, "Validate Server Certificate" using to verify the certificate. Thx

  • Hey  ,

     If you turn this option "Validate server certificate" on, you must upload the AD server certificate to the firewall on Certificates > Certificates > Add > Upload certificate. If you don't upload it, the connection to the AD server fails.

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Global Support & Services 

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case


    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • Yeah I have done that, (Certificates are not my thing) I even included the private key in a test. However, "Validate server certificate" still fails. Do I need to reboot firewall or restart a service?

    This may not be important for things to work but I really want it to work and understand what I am doing wrong or if there is an underlining issue :-)

    Mercury is the name of the firewall. Do I need to install its certificate on the Active Directory Server as well?

    Thanks for your patience's. 

  • I've taken another approach to test things:

    On the Firewall I did the following

    SFVH_SO01_SFOS 19.5.0 GA-Build197# openssl s_client -connect servername.agility.vorpallogic.com.au:636
    CONNECTED(00000003)
    depth=1 DC = au, DC = com, DC = vorpallogic, DC = agility, CN = Agility-CA
    verify return:1
    depth=0 CN = servername.agility.vorpallogic.com.au
    verify return:1
    ---
    Certificate chain
    0 s:CN = servername.agility.vorpallogic.com.au
    i:DC = au, DC = com, DC = vorpallogic, DC = agility, CN = Agility-CA
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----

    Cert info removed

    -----END CERTIFICATE-----
    subject=CN = servername.agility.vorpallogic.com.au

    issuer=DC = au, DC = com, DC = vorpallogic, DC = agility, CN = Agility-CA

    ---
    No client certificate CA names sent
    Client Certificate Types: RSA sign, DSA sign, ECDSA sign
    Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
    Shared Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
    Peer signing digest: SHA256
    Peer signature type: RSA
    Server Temp Key: ECDH, P-384, 384 bits
    ---
    SSL handshake has read 2258 bytes and written 508 bytes
    Verification: OK
    ---
    New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Server public key is 2048 bit
    Secure Renegotiation IS supported
    No ALPN negotiated
    SSL-Session:
    Protocol : TLSv1.2
    Cipher : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 6033000040180B756EEC0B11A5038BAD924023BF458218D3DB6C19FB7D2CB44D
    Session-ID-ctx:
    Master-Key: 505036B518CAD6D26C6D54637FG23423432ADSABCDFCF6D1472A
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1676187102
    Timeout : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
    ---

    read:errno=104

    I then exported the certificate using the command below and installed it on the Sophos Firewall under System->Certificates->Certificates. I have the rootCA certificate installed in Certificate Authorities on Sophos.
    openssl s_client -connect servername.agility.vorpallogic.com.au:636 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > ad_ldap_server.pem

    After doing all this

    Configure -> Authentication -> Servers

    The active directory domain controller (the only one I have) still failes on (Validate Server Certificate) however connection passed when this is ticked off.

    DEBUG Feb 12 07:44:18.562168Z [access_server]: (test_authserver_connection): BIND_PROTOCOL:2
    DEBUG Feb 12 07:44:18.562171Z [access_server]: (test_authserver_connection): -----------------------------
    DEBUG Feb 12 07:44:18.562174Z [access_server]: (test_authserver_connection): CA_CERTIFICATE:y
    DEBUG Feb 12 07:44:18.562176Z [access_server]: (test_authserver_connection): -----------------------------
    ERROR Feb 12 07:44:18.572742Z [access_server]: adsauth_bind: bind failed: Can't contact LDAP server
    ERROR Feb 12 07:44:18.572752Z [access_server]: adsauth_bind: bind failed: TLS: hostname does not match CN in peer certificate
    ERROR Feb 12 07:44:18.572756Z [access_server]: adsauth_test_auth:'192.168.28.53:636': bind failed for user: 'AGILITY\administrator'
    DEBUG Feb 12 07:44:18.572796Z [access_server]: tlvserver_handle_request: response sent
    DEBUG Feb 12 07:44:18.572801Z [access_server]: (do_epoll): Waiting for event

    Looking here: www.sonicwall.com/.../

    And I have verified the CN is correct.

    However not enough information given in this log statement to investigate further.
    ERROR Feb 12 07:44:18.572752Z [access_server]: adsauth_bind: bind failed: TLS: hostname does not match CN in peer certificate

    As far as I can tell it does. Could this be a bug?

    Does SOPHOSXG expect certificates in a specific way?

    Not a single SSL error in the Domain Controllers Event log as well. 

    This was a great link: LDAP over SSL (LDAPS) Certificate - TechNet Articles - United States (English) - TechNet Wiki (microsoft.com)

  • "Please note that errno 104 is ECONNRESET for "Connection reset by peer". This means that either the server closed the connection maybe due to problems with the setup or that the server was not even started or that there is some firewall between client and server blocking access. So could you please check if there is firewall between the VM and the cluster?"

    Only active Firewall is the SOPHOS one trying to establish the connection. 

  • What is the common name under the default certificate ? [Path: Certificates > Certificate authorities > Default?] And the hostname ? [Path: Administration > Admin and user settings > Hostname]

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Global Support & Services 

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case


    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • Appreciate all your help Vivek,

    Rooky mistake on my part. 

    I thought "Server name:*" was the Common Name

    and

    Server IP / domain* was the IP address of the Active Directory Server I was authenticating to.

    What you should have:

    Server name:* <The name of your server>

    Server IP / domain* <FQDN> 

    Unfortunately, I didn't have the IP address as an alternative name in the certificate I see, if I had the IP as an alternative name it would have worked I would think.

    Big shout out and thank you to Ross for pointing this out.