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

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

  • 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
  • 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.  

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


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

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


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

Children