Answers.Body: <p>[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.]</p>
  
  <p>This error generally indicates an issue with the SSL certificate bundle on your end and/or the mail server's end.</p>
  
  <p>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:</p>
  
  <ul>
  <li>a root certificate owned by a root CA;</li>
  <li>"signed" (cryptographically verified as legit) by someone who has a root certificate;</li>
  <li>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;</li>
  <li>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.</li>
  </ul>
  
  <p>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?"</p>
  
  <p>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) <a href="https://wiki.mozilla.org/CA:IncludedCAs" rel="nofollow noreferrer">process</a>.  E.g. <a href="https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport" rel="nofollow noreferrer">here's the list</a> Firefox currently uses.  This list changes all the time!</p>
  
  <p>So that leads to two more situations: </p>
  
  <ul>
  <li>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.</li>
  <li>The mail server's cert was signed by a legit intermediate cert, but is failing to tell your CiviCRM about it (incomplete "certificate chain").</li>
  </ul>
  
  <p>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!</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Chris gives much better answers on how to figure out which of these is true!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-12T01:56:29.757Z
Answers.LastActivityDate: 2017-01-12T01:56:29.757Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>I encountered the same email problems after upgrading to PHP 7.0.30 from 5.5.38. My client's server uses TLS.</p>
  
  <p>Go to the following website:
  <a href="http://www.checktls.com/" rel="nofollow noreferrer">http://www.checktls.com/</a></p>
  
  <p>and enter you email address and press the CheckTLS button and review the output. </p>
  
  <p>In my case, it highlighted that the mail server was using expired and self-signed certificates</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-03T14:40:42.133Z
Answers.LastActivityDate: 2017-10-03T14:40:42.133Z
Answers.UserDisplayName: Codedogs
Answers.Body: <p>The recommended and least invasive fix is to <strong>resolve the underlying SSL issues</strong>. </p>
  
  <p>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 -</p>
  
  <ul>
  <li>The hosting environment has a misconfigured certificate chain. (Fix varies by hosting environment - for Debian, <code>apt-get install ca-certificates</code> - there's probably already a Stack Exchange answer for any other specific OS/environment a site is hosted on.) </li>
  <li>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.)</li>
  <li>The remote service has a misconfigured/bad SSL certificate. (Ask remote service to fix SSL.)</li>
  <li>The connection between the two is being interfered with. ( )</li>
  </ul>
  
  <p>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. <a href="https://serverfault.com/questions/131627/how-to-inspect-remote-smtp-servers-tls-certificate">This SE answer shows how to test with <code>openssl</code> command from CLI</a> and has links to web services for same.</p>
  
  <p>Then resolve the SSL issues at whichever end they are occurring, until SSL validates and your CiviCRM is able to connect again.</p>
  
  <p>This assumes that you <em>can</em> 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: <a href="https://github.com/libressl-portable/portable/issues/80" rel="nofollow noreferrer">this libressl bug</a> - as opposed to a valid CA you just don't have installed), then you just can't have SSL validation. </p>
  
  <h3>Alternative solutions (not recommended)</h3>
  
  <p>Unless you're running CiviCRM for local development and with fake contact data,</p>
  
  <ul>
  <li>Don't disable <a href="http://php.net/manual/en/migration56.openssl.php" rel="nofollow noreferrer">PHP5.6's SSL validation</a> by default. <a href="https://stackoverflow.com/questions/13740933/security-consequences-of-disabling-curlopt-ssl-verifyhost-libcurl-openssl">This is best avoided</a>.</li>
  <li>Don't downgrade to PHP5.5. This combines disabling SSL validation with <a href="http://php.net/manual/en/migration56.openssl.php" rel="nofollow noreferrer">downgrading to an unsupported version of PHP</a>, so it's worse!</li>
  <li>As of early 2017, OSX / CiviCRM / Gmail may also be affected by <a href="https://github.com/Homebrew/legacy-homebrew/issues/38491" rel="nofollow noreferrer">this homebrew issue</a> or <a href="https://github.com/libressl-portable/portable/issues/80" rel="nofollow noreferrer">this libressl issue</a>. (That's an unlikely combination to find in production though.)</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-12T03:45:47.963Z
Answers.Text: Thanks for the info! Now I am wondering if it's related to this issue I'm having: http://drupal.stackexchange.com/questions/219847/users-cant-log-in-sometimes
Answers.UserDisplayName: Christia
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-12T03:50:07.100Z
Answers.Text: 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.)
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-12T03:57:00.400Z
Answers.Text: Yeah, I'd echo the suggestion there that URLs are not correctly canonical. [This answer](http://civicrm.stackexchange.com/questions/6790/network-error-due-to-cross-origin-request-blocked/6824#6824) mentions a few places that you can check - `settings.php` ➡ `$base_url`, `civicrm.settings.php` ➡ `CIVICRM_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!)
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-12T22:42:26.630Z
Answers.Text: `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.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-13T18:38:01.393Z
Answers.Text: I heard back from CiviSMTP and they informed me that they are planning to upgrade their certificates in February and think that this might solve the problem.
Answers.UserDisplayName: Christia
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-02T17:50:28.487Z
Answers.Text: In the meantime, I applied this fix: https://forum.civicrm.org/index.php?topic=37194.0
Answers.UserDisplayName: Christia
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-02T20:32:54.363Z
Answers.Text: 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 :)
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-12T01:35:14.570Z
Answers.LastActivityDate: 2017-01-12T23:23:25.390Z
Answers.LastEditDate: 2017-05-23T12:38:59.763Z
Answers.UserDisplayName: Chris Burgess
Body: <p>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.</p>
  
  <p><strong>Error:</strong></p>
  
  <pre><code>authentication failure [SMTP: STARTTLS failed (code: 220, response: Go ahead with TLS)]
  </code></pre>
  
  <p>Have we decided as a community what the recommended action is to address this issue? I.E. <a href="https://civicrm.stackexchange.com/questions/9467/outbound-mail-fails-after-upgrading-to-4-7-1?rq=1">downgrade PHP to 5.5</a>, or <a href="https://civicrm.stackexchange.com/questions/10964/smtp-connection-failing-problem?noredirect=1&amp;lq=1">this CiviCRM core hack</a> or <a href="https://forum.civicrm.org/index.php?topic=37194.0" rel="nofollow noreferrer">apply this patch</a> to <code>packages/Net/SMTP.php</code> (below), or something else?</p>
  
  <p>CiviSMTP made an announcement to apply the following patch to disable TLS. There doesn't seem to be another option:</p>
  
  <pre><code>$this-&gt;_socket_options = $socket_options;
  </code></pre>
  
  <p>to </p>
  
  <pre><code>$this-&gt;_socket_options = array('ssl' =&gt; array('verify_peer'=&gt;false,'verify_peer_name'=&gt;false,'allow_self_signed'=&gt;true));
  </code></pre>
  
  <p>I prefer not to downgrade PHP or hack core and to apply the least invasive fix possible.</p>
  
  <p><strong>Observations:</strong></p>
  
  <ul>
  <li>This problem is on CiviSMTP (not affiliated with the CiviCRM dev community) and seems to be specific to anyone using that SMTP service.</li>
  </ul>
  
Tags: <civimail><drupal><upgrade><smtp>
Title: Outgoing Mail Settings, CiviSMTP & PHP 5.6.x Problem
ThreadText: # Outgoing Mail Settings, CiviSMTP & PHP 5.6.x Problem
  
  (Asked by: username_0 on 2017-01-11)
  
  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.
  
  **Tags:** civimail, drupal, upgrade, smtp
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_3 on 2017-01-12. Score: 11 | Accepted answer
  
  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](https://serverfault.com/questions/131627/how-to-inspect-remote-smtp-servers-tls-certificate) 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](https://github.com/libressl-portable/portable/issues/80) - 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](http://php.net/manual/en/migration56.openssl.php) by default. [This is best avoided](https://stackoverflow.com/questions/13740933/security-consequences-of-disabling-curlopt-ssl-verifyhost-libcurl-openssl).
  * Don't downgrade to PHP5.5. This combines disabling SSL validation with [downgrading to an unsupported version of PHP](http://php.net/manual/en/migration56.openssl.php), so it's worse!
  * As of early 2017, OSX / CiviCRM / Gmail may also be affected by [this homebrew issue](https://github.com/Homebrew/legacy-homebrew/issues/38491) or [this libressl issue](https://github.com/libressl-portable/portable/issues/80). (That's an unlikely combination to find in production though.)
  
  > **Comments:**
  > **username_0**: Thanks for the info! Now I am wondering if it's related to this issue I'm having: http://drupal.stackexchange.com/questions/219847/users-cant-log-in-sometimes  
  > **username_3**: 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.)  
  > **username_3**: Yeah, I'd echo the suggestion there that URLs are not correctly canonical. [This answer](http://civicrm.stackexchange.com/questions/6790/network-error-due-to-cross-origin-request-blocked/6824#6824) mentions a few places that you can check - `settings.php` ➡ `$base_url`, `civicrm.settings.php` ➡ `CIVICRM_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!)  
  > **username_3**: `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.  
  > **username_0**: I heard back from CiviSMTP and they informed me that they are planning to upgrade their certificates in February and think that this might solve the problem.  
  > **username_0**: In the meantime, I applied this fix: https://forum.civicrm.org/index.php?topic=37194.0  
  > **username_3**: 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 :)  
  
  ---
  
  ### Answer by username_1 on 2017-01-12. Score: 1
  
  [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](https://wiki.mozilla.org/CA:IncludedCAs). E.g. [here's the list](https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport) 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 by username_2 on 2017-10-03. Score: 0
  
  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
  
  
  ---
  
  