Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1958 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

"Blocked due to using client certificate" error

JasP

Until recently we were using a self-signed certificate for SMTP email connections on our mail server. Yesterday we changed to a Letsencrypt certificate and started getting delivery failures to some but not all recipients.

When we looked at our mail server we were getting:

Wed 2021-07-28 13:23:16: SSL negotiation failed, error code 0x80090327
Wed 2021-07-28 13:23:16: An unknown error occurred while processing the certificate. (-2146893017)
Wed 2021-07-28 13:23:16: SMTP session terminated (Bytes in/out: 358/41)

When we looked at the SSL/TLS XG log for these connections we were seeing "Blocked due to using client certificate".

I can't find any reference to this error message. It is doubly strange that we had no issues with a self-signed certificate but failures with a proper certificate. This is at a customers site; we have the same setup and it has been running for a few months without the same issue. The only thing I have tried is to deselect 'Block invalid certificates' in General settings. I didn't expect it to make any difference and it didn't!

Can anybody explain this error and offer a solution?



This thread was automatically locked due to age.
  • 0

    "Blocked due to using client certificate" ... could show you the problem ...
    Possible the peer has incorrect content within the certificates and deactivating 'Block invalid certificates' may help.
    I would try it.
    Otherwise, you can capture the peer certificate and compare content.

  • 0 in reply to dirkkotte

    This isn't the peer certificate, it is changing our own (to be precise, the customers) certificate from a self-signed certificate to a Letsencrypt certificate that has caused this issue. It also only affects certain email recipients (always the same ones) most continue to work fine. The certificate itself appears fine but we did re-issue it just in case.

    We've been using the same setup ourselves for several months without any issues.

    Deactivating 'Block invalid certificates' made no difference.

    The XG is running SFOS 18.0.5 MR-5-Build586

  • 0

    I started seeing the same thing today out of the blue.  Like you, my SMTP server has a legitimate third party signed certificate, and like you, it only fails to certain domains (outlook.com, gmail.com, several others).  I had forgotten that I had left a DPI engine inspection rule enabled for my servers after I turned it off for everybody else due to all the other problems it causes.  Once I disabled it, everything started working perfectly again.  Like you, I could find no reference to the message anywhere.

    So frustrating when things just break out of nowhere.  

  • 0 in reply to Bill Roland

    So a Port25 exception rule within "SST/TLS inspection Rules" should help.

  • 0 in reply to dirkkotte

    What the. Is the use of using ssl/tls.if you have to put an exception in?
    ian

  • 0

    By default we use DPI inspection for everything and then add exemptions as required. As a 'quick fix' I removed inspection from all traffic for the mail server (it has very limited internet access anyway) and have now refined that to just port 25. It works fine, as I would expect.

    This still leaves lots of questions:
    What does this error message actually mean?
    Why did it work with a self-signed certificate but not a proper certificate?
    Why does the same configuration work on our own system without the need for an exemption?

    Would be nice to get some input from Sophos on this.

  • 0 in reply to JasP

    I am assuming right now, but i guess it is related on the Client authentication within the TLS. 

    See: https://textslashplain.com/2020/05/04/client-certificate-authentication/

    If you create a tcpdump of this port 25 communication, can you check the initial TLS Hello? Is there a client authentication request? 

    And which TLS decryption profile do you use? 

  • 0

    The error occurs for "certain email recipients" (not all) and the error message says "client certificate". The error is regarding the client, not server.


    Some authentication schemes allow for a client to identify themselves (authenticate) via an X.509 certificate. When that happens the XG cannot decrypt the traffic. Or more specifically, if the XG was the decrypt the traffic we must regenerate the client certificate and lie to the server - which the server will see as not the real certificate and authentication would fail.

    Therefore all cases where there is authentication via client certificate must hit a Do Not Decrypt rule.

    I suspect that this is what is causing the error. Clients are trying to authenticate using X.509 certificates, they hit a Decrypt rule, and the XG blocks because it cannot decrypt.

    The interesting issue is why did this start happening when you changed the server certificate. That I am not sure of.
    One possibility is that the server is now sending CertificateRequest as part of the TLS handshake when it did not before.
    One possibility is that when using the self-signed certificate the connection was not being decrypted for other reasons (such as invalid cipher) and switching to a better certificate allowed for decryption and new decryption errors.


    Were there any other changes on the email server aside from the certificate? Any TLS changes?
    For the clients that are failing, can you see whether they are configured to use client certificate authentication?

    To fix:
    If you want to use client certificate authentication that server must have a Do Not Decrypt rule.
    If you want to Decrypt you must make sure all clients/server is configured not to use certificate authentication.

  • 0 in reply to Michael Dunn

    You may well be correct with this Michael

    In terms of the changes, the only thing we changed was the certificate. The emails are sent from Security Gateway (spam, antivirus software). It may be that it is intelligent enough to know not to offer a self-signed certificate to identify itself (because it would obviously fail). I don't know if it does do client authentication and it isn't clear from the software, documentation or logs.

    What I can't find is why it works on our site and not on the customers. There must be a different setting, either within Sophos or Security Gateway but I can't find it.

    I would love to spend more time on this but I'm pretty swamped at the moment (hence the delay replying). Although I would like to totally nail down what is happening here, I am just going to have to settle for the fix (a Do Not Decrypt rule).

  • 0 in reply to JasP

    I use the same SMTP gateway as JasP, Security Gateway by MDaemon.  It's installed on an on-prem server and in my case there haven't been any updated versions installed in the past several months and I've used a legit third party SSL certificate for years, yet I saw the same thing happen at the same time he did.