Akeeba Ticket System

Wednesday, 27 November 2019 13:12 CST

weeblr

Hi

This is something that I experienced with ATS 2.4.X for the last couple of months. I had hoped upgrading to 3.0.4 would fix the problem but not so.

We use a gmail account for "reply by email" feature. It currently only works (and for the last couple of months roughly - as been working for years) if I disable "Validate certificates". Here are the settings:

End of october (with ATS 2.4) I debugged the PHP to trace back the problem to ATS not being able to validate the gmail certificate which led me to disable validation.

Any insight as to where to look?

Best regards

Thursday, 28 November 2019 00:51 CST

nicholas

OK, this is complicated and you will need to bear with me. The problem is that somewhere in your server's compile chain you're either missing the OpenSSL Certification Authorities cache or it's out of date.

ATS uses PHP's IMAP extension to talk to email servers. The PHP IMAP extension is either statically linked against libc-client.a or dynamically linked against libc-client.so. libc-client is compiled against OpenSSL. Therefore all SSL features end up being handled by OpenSSL.

When OpenSSL starts an encrypted connection it eventually retrieves the remote party's certificate and certificate chain and needs to validate it. It does so against its Certification Authorities cache. This can be either a single file (think cacert.pem) or a directory, the latter being the default on CentOS / RHEL.

If you are not sure where that is you can run var_dump(openssl_get_cert_locations()) in a PHP script on your server to find out. If these locations are empty, do not actually exist on your server or they contain outdated certificates the certificate validation will fail.

I am not entirely sure if the OpenSSL runtime configuration in php.ini affects where IMAP will look for its CA cache but you can try. On all my dev servers I have set openssl.cafile to a local path (/opt/cacert/cacert.pem) which contains the cacert.pem file from cURL. I'm also using up-to-date macOS, Windows and Ubuntu Server installations which do have updated root CA caches so I'm not sure which of the two factors is what makes things work for me.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Thursday, 28 November 2019 01:43 CST

weeblr

Hi

Yes, I'm familiar with all that but I'm surprised the CA config is not right for PHP. I'll do some more digging there today.

Best regards

Thursday, 28 November 2019 02:11 CST

weeblr

Hi

The thing is, cert configuration seems ok. From a shell (inside the PHP container) I can connect to imap.google.com:

openssl s_client -showcerts -connect imap.gmail.com:993

wokrs fine and is verified.
PHP itself is properly set to use certs in the correct directory. Output of var_dump(openssl_get_cert_locations()):

array(8) {
  ["default_cert_file"]=>
  string(21) "/usr/lib/ssl/cert.pem"
  ["default_cert_file_env"]=>
  string(13) "SSL_CERT_FILE"
  ["default_cert_dir"]=>
  string(18) "/usr/lib/ssl/certs"
  ["default_cert_dir_env"]=>
  string(12) "SSL_CERT_DIR"
  ["default_private_dir"]=>
  string(20) "/usr/lib/ssl/private"
  ["default_default_cert_area"]=>
  string(12) "/usr/lib/ssl"
  ["ini_cafile"]=>
  string(0) ""
  ["ini_capath"]=>
  string(0) ""
}

default_cert_dir is set to /usr/lib/ssl/certs which is where all certs are. SSL_CERT_DIR is empty, it cannot interfere. ini_cafile and ini_capath are not set but the default_cert_dir should be used.

Must have to do with how PHP imap extension was compiled I guess.

Best regards

Thursday, 28 November 2019 03:10 CST

weeblr

Hi again

Just FYI, as I suspected, this is not a certificate configuration issue but a "bug" in PHP Imap extension. The actual error returned by Google server is:

Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid"

The PHP Imap extension does not support SNI (as the underlying libc version does not either) so that cannot work under the particular combination of php and libc.

Tracked in https://bugs.php.net/bug.php?id=77108 but closed as non-fixable.

Will keep certificates check disabled until I have a PHP version that works.

Best regards

Thursday, 28 November 2019 04:39 CST

weeblr

Hi

For completeness sake, it appears the underlying addition to libc-client2007e has been done at least in Ubuntu. However, it's been patched in Debian (Buster, which I use to builld containers) only recently (august 2019, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041) and so this may not have been propagated yet to Debian distribution.

Best regards

Thursday, 28 November 2019 07:11 CST

nicholas

That does make sense. Thank you for the detailed info.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 28 December 2019 17:17 CST

System Task

system

This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Edited by on 2019-12-28 17:17 CST

Support