#32051 – Cannot validate Google gmail certificates

Posted in ‘Akeeba Ticket System’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
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

Custom Fields

Joomla! version (in x.y.z format) 3.9.13
PHP version (in x.y.z format) 7.2.24
Akeeba Ticket System version (x.y.z format) 3.0.4
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



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



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Saturday, 28 December 2019 17:17 CST
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.
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!