RPOP does not send TLS SNI

Support General Configuration
1

Hello,

RPOP stopped working for me for gmail, because gmail requires TLS SNI to be present, otherwise you get no certificate from them and thus no sync happens.

Can we get RPOP service to start sending out SNI? changing settings to TLS from SSL results in a timeout, presumably because it expects STARTTLS, but gmail only supports direct TLS for POP3

2

Hello Marek,

Could you please confirm your Axigen version and on which OS is running?

BR,
Ioan

3

Hello,

|Current Server version: |10.5.17|
Debian 11, no docker

4

Hello Marek,

Please use the following workaround to overpass the fact that Gmail is sending a self-signed SSL cert when the SNI information is missing or not in sync with the expected hostname (pop.gmail.com):

In the service configuration file (/etc/default/axigen for your case) add a new line, for example at the end of the file, with the following content:

export AXI_RPOP_OPT_X_TLS_IGNORE_CERT=yes

After this change please restart your Axigen service.

Please let us know if the above workaround is producing the expected result.

HTH,
Ioan

PS: Starting with Axigen version 10.5.12 we have switched to OpenSSL 3.0 (more details here) and we have a high level of certainty that the reported issue is a consequence of SSL certificate validation with the CA bundle from /opt/axigen/cacert_default.pem

5

Thank you very much for that, the workaround is working.
However I think we can both agree this is not a permanent solution and should be adressed.

Also, I am not very keen on Axigen using its own CA database instead of the system one.
In my opinion the system CA should be prioritized. Can that be changed with a variable as well?

6

Hi Marek,

Axigen is looking for the trusted CA certificates defined in the Axigen configuration file under the caBundlePath parameter, which by default is set to “” (none), which is the default CA bundle file located into /opt/axigen/cacert_default.pem.

Since after every Axigen update, the cacert_default.pem is being overwritten (in case you edit this file directly), the correct way for you to set up your own CA bundle file is by:

  1. Create a copy of the /opt/axigen/cacert_default.pem
  2. Add your internal CA at the end of the file
  3. Stop Axigen
  4. Edit the Axigen configuration file, and specify the path for your CA bundle
caBundlePath = "/opt/axigen/your_bundle.pem"
  1. Start Axigen

In this way, the change will be consistent with every Axigen update.

Thank you,
Valentin

1 Like
7

Hello Marek,

As Valentin said above you could anytime change caBundlePath directly in axigen.cfg (needs service restart) or via CLI (in server context: set caBundlePath path-to-your-specific-ca-bundle - needs version 10.5.17+).

So, if you like to switch to your system CA database you may use that one, like:

  • DEB: /etc/ssl/certs/ca-certificates.crt
  • RPM: /etc/pki/tls/certs/ca-bundle.crt or /etc/ssl/certs/ca-bundle.crt

Note: above ones are anyway used as “fallbacks” when the file mentioned in caBundlePath is not accessible or rejected by OpenSSL (like having wrong content).

Example for what is logged into mail log when all available sources for the CA database are failing (for testing purposes):

ERROR: Root CA bundle path provided in config, but /var/opt/axigen/cacert_default_local.pem could not be opened: error:04800064:PEM routines::bad base64 decode
ERROR: Default root CA bundle file /opt/axigen/cacert_default.pem could not be opened: error:04800064:PEM routines::bad base64 decode
ERROR: System root CA bundle file /etc/ssl/certs/ca-certificates.crt could not be opened: error:04800064:PEM routines::bad base64 decode
WARNING: No root CA bundle file could be opened; setting empty root CA store. Certificate validation may fail.

HTH,
Ioan