BUG: missing CA certificate breaks outbound delivery to Microsoft-hosted domains

John · July 28, 2026, 8:15pm

Version: 10.6.37, official docker image.
Symptom: Delivery to Microsoft hosted domains fails and never leaves the queue.

2026-07-28 02:41:03 +0000 08 mail SMTP-OUT:00000031: Relay mail 044CD6: connecting to 52.101.194.5:25
2026-07-28 02:41:03 +0000 08 mail SMTP-OUT:00000031: Relay mail 044CD6: connected to 52.101.194.5:25
2026-07-28 02:41:03 +0000 02 mail SMTP-OUT:00000031: SSL alert remote 52.101.194.5:25, undefined:fatal:unknown CA
2026-07-28 02:41:03 +0000 02 mail SMTP-OUT:00000031: SSL error remote 52.101.194.5:25, SSL_connect:failed in error
2026-07-28 02:41:03 +0000 02 mail SMTP-OUT:00000031: 52.101.194.5:25 SSL_connect error: error:0A000086:SSL routines::certificate verify failed
2026-07-28 02:41:03 +0000 02 mail SMTP-OUT:00000031: Unable to perform STARTTLS
2026-07-28 02:41:03 +0000 08 mail SMTP-OUT:00000031: Disconnected from 52.101.194.5
2026-07-28 02:41:03 +0000 08 mail SMTP-OUT:00000031: Use 52.101.9.18 to relay mail 044CD6 for domain hotmail.com
2026-07-28 02:41:03 +0000 08 mail SMTP-OUT:00000032: Relay mail 044CD6: connecting to 52.101.9.18:25
2026-07-28 02:41:04 +0000 08 mail SMTP-OUT:00000032: Relay mail 044CD6: connected to 52.101.9.18:25
2026-07-28 02:41:04 +0000 02 mail SMTP-OUT:00000032: SSL alert remote 52.101.9.18:25, undefined:fatal:unknown CA
2026-07-28 02:41:04 +0000 02 mail SMTP-OUT:00000032: SSL error remote 52.101.9.18:25, SSL_connect:failed in error
2026-07-28 02:41:04 +0000 02 mail SMTP-OUT:00000032: 52.101.9.18:25 SSL_connect error: error:0A000086:SSL routines::certificate verify failed
2026-07-28 02:41:04 +0000 02 mail SMTP-OUT:00000032: Unable to perform STARTTLS
2026-07-28 02:41:04 +0000 08 mail SMTP-OUT:00000032: Disconnected from 52.101.9.18
2026-07-28 02:41:04 +0000 08 mail SMTP-OUT:00000032: Use 52.101.40.30 to relay mail 044CD6 for domain hotmail.com
2026-07-28 02:41:04 +0000 08 mail SMTP-OUT:00000033: Relay mail 044CD6: connecting to 52.101.40.30:25
2026-07-28 02:41:04 +0000 08 mail SMTP-OUT:00000033: Relay mail 044CD6: connected to 52.101.40.30:25
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000033: SSL error remote 52.101.40.30:25, SSL_connect:failed in SSLv3/TLS write client hello
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000033: SSL error remote 52.101.40.30:25, SSL_connect:failed in SSLv3/TLS write client hello
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000033: SSL alert remote 52.101.40.30:25, undefined:fatal:unknown CA
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000033: SSL error remote 52.101.40.30:25, SSL_connect:failed in error
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000033: 52.101.40.30:25 SSL_connect error: error:0A000086:SSL routines::certificate verify failed
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000033: 52.101.40.30:25 SSL_connect error (Connection timed out)
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000033: Unable to perform STARTTLS
2026-07-28 02:41:05 +0000 08 mail SMTP-OUT:00000033: Disconnected from 52.101.40.30
2026-07-28 02:41:05 +0000 08 mail SMTP-OUT:00000033: Use 52.101.194.16 to relay mail 044CD6 for domain hotmail.com
2026-07-28 02:41:05 +0000 08 mail SMTP-OUT:00000034: Relay mail 044CD6: connecting to 52.101.194.16:25
2026-07-28 02:41:05 +0000 08 mail SMTP-OUT:00000034: Relay mail 044CD6: connected to 52.101.194.16:25
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000034: SSL alert remote 52.101.194.16:25, undefined:fatal:unknown CA
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000034: SSL error remote 52.101.194.16:25, SSL_connect:failed in error
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000034: 52.101.194.16:25 SSL_connect error: error:0A000086:SSL routines::certificate verify failed
2026-07-28 02:41:05 +0000 02 mail SMTP-OUT:00000034: Unable to perform STARTTLS
2026-07-28 02:41:05 +0000 08 mail SMTP-OUT:00000034: Disconnected from 52.101.194.16
2026-07-28 02:41:05 +0000 08 mail SMTP-OUT:00000034: Relay mail 044CD6: no more relays for hotmail.com
2026-07-28 02:41:05 +0000 04 mail SMTP-OUT:00000034: Delivery attempt completed for mail 044CD6; 1 recipients remaining; reschedule for delivery
2026-07-28 02:41:05 +0000 08 mail SMTP-OUT:00000034: Set mail state to SEND FAILURE

The ::certificate verify failed is Axigen acting as TLS client and refusing the Microsoft certificate, not MS rejecting the Axigen cert. Their inbound mail exchanger doesn’t request a client certificate.

The cause is that /axigen/cacert_default.pem appears to have been built after Mozilla removed the DigiCert G1 roots in April 2026. Microsoft’s certificates still chain through DigiCert SHA2 Secure Server CA to DigiCert Global Root CA, so no path can be built. Note the G2 through G5, but no G1.

root@mail:/# grep -i digicert /axigen/cacert_default.pem
DigiCert Assured ID Root G2
DigiCert Assured ID Root G3
DigiCert Global Root G2
DigiCert Global Root G3
DigiCert Trusted Root G4
DigiCert TLS ECC P384 Root G5
DigiCert TLS RSA4096 Root G5

I fixed it by manually downloading the DigiCert G1 and adding it to the file, but this will be overwritten on next upgrade, so it really needs to be fixed.

Razvan · July 29, 2026, 4:29pm

Hello John,

Please know that starting with Axigen version 10.5.65, 10.6.35 and 10.7 the default CA certificate bundle shipped with Axigen no longer includes certain older root certificates that Mozilla and Google Chrome have removed from their trust stores. Some remote mail servers, notably Microsoft 365 / Exchange Online (*.protection.outlook.com), are still presenting certificate chains that rely on one of these now-removed roots. As a result, outbound SMTP-OUT connections to these destinations fail certificate verification, while delivery to other providers is unaffected.

Axigen follows current Mozilla/Chrome trust-store standards for the default bundle, so this root will not be re-added by default. To restore delivery, you can point Axigen at a custom CA bundle of your choice by following the below steps:

Obtain a CA bundle file that contains the certificate needed for the affected destination. This can be:
- A full CA bundle from curl.se that predates the removal, e.g. https://curl.se/ca/cacert-2026-03-19.pem, or
- Any other complete CA bundle of your choice (e.g. your OS’s own CA file), as long as it contains all the roots you need, not just the single missing one.
Copy the file into the Axigen base directory:
- Linux: /opt/axigen
- Docker: /axigen
- Windows: C:\Program Files\Axigen Mail Server
Set ownership/permissions so the Axigen service account can read it:
- Linux: chown axigen:axigen /opt/axigen/.pem
- Docker: chown axigen:axigen /axigen/.pem
- Windows: ensure the account running the Axigen service has read access to the file (via file Properties > Security).
Edit the Axigen configuration file axigen.cfg and set:
```
caBundlePath = "<filename>.pem"
```
Save the file and restart the Axigen service.

After restarting, re-test delivery to the affected destination to confirm certificate verification now succeeds.

Thank you.

Best regards,
Razvan

John · July 29, 2026, 5:49pm

Thanks for the reply and the recipe.

I confess I’m a little surprised at the stance: this is a VERY large number of mail domains impacted. It’s an out of the box, permanent delivery failure to about 17% of all domains, those hosted by Microsoft.

John · July 29, 2026, 6:59pm

I think an orthogonal issue is that treating a verification failure on opportunistic SMTP TLS as fatal is a bit of an outlier. Surely Axigen should fall back to unauthenticated TLS or even plaintext delivery by default?

Is the fact that it’s not falling back in my case a configuration artefact, or default behaviour? My smtpOutgoing has no TLS override and enableSmtpRouting = no

Postfix’s TLS README states “With opportunistic TLS, mail delivery continues even if the server certificate is untrusted or bears the wrong name. When the TLS handshake fails for an opportunistic TLS session, rather than give up on mail delivery, the Postfix SMTP client retries the transaction with TLS disabled.”