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.


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;


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


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

3 Answers 3


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,

  • Thanks for the info! Now I am wondering if it's related to this issue I'm having: drupal.stackexchange.com/questions/219847/…
    – Christia
    Jan 12, 2017 at 3:45
  • That doesn't sound related, no. However, since your other question gives details on the hosting environment, the command to install/update CA on that server is apt-get install ca-certificates. (If you relate the remote site you're unable to connect to here, it's possible to verify whether their SSL is valid.) Jan 12, 2017 at 3:50
  • 1
    Yeah, I'd echo the suggestion there that URLs are not correctly canonical. This answer mentions a few places that you can check - settings.php$base_url, civicrm.settings.phpCIVICRM_UF_BASEURL, and your Apache config (.htaccess and /etc/apache2/*.conf) should all agree on the full canonical URL (with caveat that syntax varies for each!) Jan 12, 2017 at 3:57
  • 1
    openssl s_client -starttls smtp -connect civismtp.uas.coop:20095 tells me you're right there - the certificate presented as of today is self-signed and won't work out of the box with PHP5.6. CiviSMTP could resolve this (simplest method, by obtaining a recognised cert) in order to work without core hack or downgrade of PHP. Jan 12, 2017 at 22:42
  • 2
    My sympathies. It is frustrating to hear that any CiviCRM user might have to disable the encryption of email traffic for any reason, especially those controlled by their provider. Security should not be an optional extra for the activist community. Contacts' personal data is personal, private and sensitive, and deserves fair consideration. Please remember to remove that patch as soon as you can :) Feb 2, 2017 at 20:32

[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!


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.