Intermittent external SMTP connections returning local Exim certificate (CSF-related?)

John Golden

• May 05, 2026 07:56

We are experiencing an intermittent issue on a cPanel/WHM (134.0.23, AlmaLinux 8.10, Exim, CSF) server where Drupal websites send emails via external SMTP (Gmail and Microsoft 365). These are two completely separate cPanel users and hosting accounts, both using fully external mail services.

The issue occurs randomly and affects both environments in the same way. Email sending fails with: stream_socket_enable_crypto(): Peer certificate CN=myserver.com did not match expected CN=smtp.gmail.com

This indicates that instead of the remote SMTP server, our own server’s Exim is responding, as if the outbound connection is being redirected locally. Connectivity and DNS resolution appear normal, and direct tests (nc, openssl) usually reach the correct remote hosts.

Restarting CSF (csf -r) immediately resolves the issue for both domains, but it reappears after about a week. Domains using local mail delivery are not affected.

WHM “Restrict outgoing SMTP (SMTP Tweak)” is enabled, while in CSF both SMTP_BLOCK and SMTP_REDIRECT are disabled, and SMTP_ALLOWUSER includes the relevant users and nobody.

This strongly suggests that outbound SMTP connections are intermittently being redirected or handled locally, possibly due to firewall/conntrack state or CSF interaction.

Has anyone encountered similar behavior where external SMTP connections occasionally loop back to the local Exim and return the server’s own certificate?

• 

  cPRex Jurassic Moderator

  • May 05, 2026 15:50

  Hey there!  I can't say I've seen anything similar - it might be best to create a ticket when the system is in the broken state so it can be observed then.

  0
• 

  Ioannis Liatis

  • May 05, 2026 19:21

  I confirm i have seen the same issue and it is resolved with CSF restart.
  I would like to open a ticket but it is difficult for me to leave the server in broken state as client need it up.
  
  Thank you,

  0
• 

  John Golden

  • May 06, 2026 06:23

  Thanks for the feedback.
  We understand that opening a ticket in a broken state would be ideal, however in our case this is difficult because the affected systems are production environments and email delivery is business-critical, so we cannot leave them in a non-working state for an extended period. All other services on the server are operating normally without any issues.
  Given that CSF restart consistently resolves the issue, it seems very likely related to firewall/connection tracking state rather than application-level configuration. Is there any recommended way to safely capture relevant debug information (logs, connection tracking state, firewall rules, etc.) at the moment the issue occurs, without requiring the system to remain in a broken state for long?
  Any guidance on what exactly to collect or monitor would be greatly appreciated.

  0
• 

  cPRex Jurassic Moderator

  • May 06, 2026 16:14

  I'm wondering if the issue is caused by having the SMTP Tweak option enabled in WHM as well as CSF is causing confusion?  Could you turn that option off in WHM and see if that improves the behavior?

  We did ensure a few fixed around this area in version 16.17-1 as outlined here:

  https://docs.cpanel.net/changelogs/configserver-security-firewall-csf-change-log/

  so if you have the WHM option off AND that latest version, it would be best to create a ticket.

  0
• 

  Ioannis Liatis

  • May 10, 2026 08:03

  Hello,
  I deal with this issue on 2 server.
  SMTP Tweak was ON on both. CSF Version is latest. I have disabled SMTP Tweak  and i am monitoring.

  Thank you

  0
• 

  cPRex Jurassic Moderator

  • May 11, 2026 14:08

  Sounds good - let me know if that's all it takes!

  0
• 

  John Golden

  • May 15, 2026 06:32

  Thank you, this seems to have pointed us in the right direction.

  After disabling the WHM “SMTP Tweak” option, external SMTP delivery started working correctly again for the affected Drupal sites, and the certificate mismatch issue disappeared.

  However, this is a shared hosting environment with many different customer websites (Drupal, WordPress, etc.), so for security reasons we do not want to leave SMTP Tweak permanently disabled. We cannot guarantee that every hosted website is always fully up to date and secure, so the extra SMTP protection is important for us.

  We understand that disabling SMTP Tweak may currently be the only workaround, but if you know any better long-term solution, we would really appreciate the suggestion.

  0

Please sign in to leave a comment.