Is anyone else seeing STARTTLS certificate failures to Exchange Online?

First inspect the certificate chain from the affected server rather than assuming the root cause. Try OpenSSL with SMTP STARTTLS enabled and certificate verification on, then check which issuer is missing or rejected. Compare results from more than one Microsoft endpoint and from a machine with a different CA bundle.

If the presented chain ends at DigiCert Global Root CA, the trust-store change may explain the timing. But a missing local root and a server presenting an unsuitable chain are different problems, so identify which one you have before changing production trust settings.

A few reports describe this as a DigiCert Global Root CA G1 trust issue. Some newer CA bundles may no longer trust that root, while the SMTP certificate chain being served appears to lead back to it. That is a plausible explanation, but it is worth verifying against the actual chain your host receives.

I would not turn off peer verification as a lasting fix. If the chain is confirmed, adding the specific root to a controlled trust store could be a temporary measure, subject to your security policy. Track the change and remove it once the server chain or supported trust path is corrected.

Check the machine’s CA package and the certificate chain before changing Laravel settings. If OpenSSL fails independently of the app, the issue is below the framework layer. Updating packages alone may not help if the required root is intentionally absent from the newer bundle.

If you do temporarily install a root certificate, obtain it from the certificate authority’s official source and verify it before trusting it. Avoid downloading a PEM from an arbitrary post, and do not disable certificate checks just to get mail moving.

One report found that the system CA bundle lacked the DigiCert Global Root CA and restored connectivity after adding it. That is a workaround, not proof that every affected host should trust the same certificate. Confirm the endpoint’s chain and your distro’s current trust behavior first.

Also check whether the failure is consistent across different MX endpoints. If only some endpoints fail, that points toward a server-side inconsistency rather than a single app configuration problem.

Even if re-trusting the old root gets the connection working, I’d treat it as a short-term exception with an owner and review date. A root certificate affects more than one connection when installed system-wide, so a scoped trust configuration may be preferable if your mail stack supports it.

There isn’t enough here to confirm Microsoft’s status or promise a specific repair timeline. Keep verification enabled, capture the OpenSSL output, and raise the chain details with your mail administrator or provider support.