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

Top Replies

  • +5 suggested

    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.

    Jump to answer
Parents
  • 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? 

    __________________________________________________________________________________________________________________

Reply Children
No Data