Topic: EL 8.4 with php-imap doesn't support SNI with TL1.3

On EL8 (specifically: Centos or AlmaLinux), since the update to 8.4, php-imap 7.3.28 doesn't want to connect to imap.gmail.com:993. It shows the following error when connecting:

# php -d display_errors=1 -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password") or die(imap_last_error());'
Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid

As far as I can see, this is because of an combination of openssl 1.1.1 enabling TLS1.3 in some cases and php-imap not supporting SNI. This is most clearly described here, but is reported elsewhere as well: https://help.heroku.com/ZW1V2D46/why-ca … map-server

The page I'm referring to notest that this issue should be fixed from 7.3.8 upwards, but if I take a look at the php release notes, I can't find anything related to SNI concerning that version.
Could it be that this is a private Heroku patch, or dit I miss something in the release notes?
Is this something you (Remi) are willing to add? It seems SNI is an important function to keep working on all TLS-versions, including TLS1.3.

Re: EL 8.4 with php-imap doesn't support SNI with TL1.3

1/ imap is really a piece of shit

The extension rely on a dead library (no update for >10years), and the reason why not in the distro (impossible to support)

Nobody serious should continue to use it, and should switch to a better alternative (some pure PHP libraries exists, e.g. laminas-mail)

2/ Could it be that this is a private Heroku patch, or dit I miss something in the release notes?

Yes, please try without, especially as nobody have report any issue for now

3/ Is this something you (Remi) are willing to add? It seems SNI is an important function to keep working on all TLS-versions, including TLS1.3.

Sorry but no, openssl is really a too much critical piece of the distro to play with it.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: EL 8.4 with php-imap doesn't support SNI with TL1.3

1. Didn't know the underlying library is that old and unsupported. Some of the 3rd party applications we use need this, though, so our hands ar bound.
2. That's too bad. Was hoping that it was a php patch.
3. If I understood correctly, the issue is in php-imap not implementing a SNI-call (using openssl for that call). So no patch for openssl is needed, php-imap needs a patch so that it actually uses SNI with connections that support TLS 1.3. So that shouldn't have that big of an impact. But I might be wrong...

Re: EL 8.4 with php-imap doesn't support SNI with TL1.3

> php-imap needs a patch

Which path, I don't see any

And if a patch exists, it should be submitted to PHP project first to be officially reviewed and included

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: EL 8.4 with php-imap doesn't support SNI with TL1.3

Yes, you're right. I searched a bit further and found the following 'overview' page: https://bugs.launchpad.net/ubuntu/+sour … ug/1834340
This has links to issues at openssl, and a proposed patch for php-imap as well. The latter you can find at the debian-link in the above page (I can only add 1 link).

But the more I read about this, the messier it seems te be.
I've suggested at the application developers to implement a new IMAP-library to replace php-imap. Until then, I think we will need to disable the certificate check for imap.google.com-servers as they intentionally send an untrusted certificate to imap clients that don't support/use SNI.