Outgoing Mail Settings, CiviSMTP & PHP 5.6.x Problem

Question

After upgrading CiviCRM from 4.3.8 to 4.7.15 on Drupal 7, our outgoing mail is giving an error after sending a test email. I'm on a Debian server running PHP 5.6.x and we use CiviSMTP for our outgoing mail.

Error:

authentication failure [SMTP: STARTTLS failed (code: 220, response: Go ahead with TLS)]

Have we decided as a community what the recommended action is to address this issue? I.E. downgrade PHP to 5.5, or this CiviCRM core hack or apply this patch to packages/Net/SMTP.php (below), or something else?

CiviSMTP made an announcement to apply the following patch to disable TLS. There doesn't seem to be another option:

$this->_socket_options = $socket_options;

to

$this->_socket_options = array('ssl' => array('verify_peer'=>false,'verify_peer_name'=>false,'allow_self_signed'=>true));

I prefer not to downgrade PHP or hack core and to apply the least invasive fix possible.

Observations:

• This problem is on CiviSMTP (not affiliated with the CiviCRM dev community) and seems to be specific to anyone using that SMTP service.

Answer 1

The recommended and least invasive fix is to resolve the underlying SSL issues.

It was intentional that PHP5.6 tightened security here. If your hosting environment doesn't validate the SSL certificate you're communicating with, one of these things is probably true -

• The hosting environment has a misconfigured certificate chain. (Fix varies by hosting environment - for Debian, apt-get install ca-certificates - there's probably already a Stack Exchange answer for any other specific OS/environment a site is hosted on.)
• The remote service requires that you install a custom CA chain before their certificate validates. (Perhaps your SMTP provider uses a self-signed SSL certificate, or a cert from a certificate authority not installed on your hosting environment.)
• The remote service has a misconfigured/bad SSL certificate. (Ask remote service to fix SSL.)
• The connection between the two is being interfered with. (😱 )

Identify whether it's your hosting environment or the remote site's SSL which is failing, by testing multiple remote sites from multiple client environments. This SE answer shows how to test with openssl command from CLI and has links to web services for same.

Then resolve the SSL issues at whichever end they are occurring, until SSL validates and your CiviCRM is able to connect again.

This assumes that you can resolve the underlying SSL issues! If the remote site offers SSL without a valid chain, or uses a certificate which your server can't make sense of (ex: this libressl bug - as opposed to a valid CA you just don't have installed), then you just can't have SSL validation. 😦

Alternative solutions (not recommended)

Unless you're running CiviCRM for local development and with fake contact data,

• Don't disable PHP5.6's SSL validation by default. This is best avoided.
• Don't downgrade to PHP5.5. This combines disabling SSL validation with downgrading to an unsupported version of PHP, so it's worse!
• As of early 2017, OSX / CiviCRM / Gmail may also be affected by this homebrew issue or this libressl issue. (That's an unlikely combination to find in production though.)

Answer 2

[Don't upvote this - Chris' answer is far better! I wouldn't have written this had I seen his. I'm leaving it here for folks who need an (over-)simplified explanation of why this happens, so they can better implement Chris' solution.]

This error generally indicates an issue with the SSL certificate bundle on your end and/or the mail server's end.

Without getting deep into how SSL certificate authorities work (Wikipedia has a much better explanation than I can provide): There's a handful of "root" certificate authority (CA) companies. Symantec, GoDaddy, Comodo, also many governments/militaries. Every SSL certificate is either:

• a root certificate owned by a root CA;
• "signed" (cryptographically verified as legit) by someone who has a root certificate;
• signed by someone who's got a signed certificate themselves. In this case, you have a root cert, one or more intermediate certs, and the cert on (in this case) the mail server;
• A cert that can't trace its lineage back to a root cert. These are known as "self-signed" certs. Your data is encrypted - but you can't guarantee the person on the other end is who they claim.

The problem here is, "Who gets to call themselves a root cert? And how do we know that the intermediate certs have been signed by a root cert?"

The answer to "who is a root cert?" is determined by whatever software you're using. Every web browser includes all the root certs they recognize in their installer. Each web browser company has their own (intense) process. E.g. here's the list Firefox currently uses. This list changes all the time!

So that leads to two more situations:

• The mail server's cert can trace its lineage back to a newer root CA, but one that your older software can't recognize because it didn't ship with the newer root cert.
• The mail server's cert was signed by a legit intermediate cert, but is failing to tell your CiviCRM about it (incomplete "certificate chain").

Your web server has a stack of root certs installed - PHP uses the ones provided by OpenSSL. Chances are, you update OpenSSL a lot less frequently than your web browser!

So most likely, your web situation is the fifth one - your openSSL is too old. If you're running Linux, update to the latest version of your distribution.

It's also possible that your situation is the sixth one - in which case you need to tell the mail administrator to fix their certificate chain.

Chris gives much better answers on how to figure out which of these is true!

Answer 3

I encountered the same email problems after upgrading to PHP 7.0.30 from 5.5.38. My client's server uses TLS.

Go to the following website: http://www.checktls.com/

and enter you email address and press the CheckTLS button and review the output.

In my case, it highlighted that the mail server was using expired and self-signed certificates