More and more CAs are no longer issuing TLS certificates with EKU for client authentication. This means that customers can no longer use their existing “normal” TLS certificates for client authentication.
In practice, this means that systems can no longer authenticate themselves to other email servers—such as Exchange Online—using TLS client authentication certificates.
Customers with automatic certificate generation via NoSpamProxy – new solution
Both NoSpamProxy Cloud customers and NoSpamProxy Server customers who use automatic certificate generation for O365 via NoSpamProxy are not affected and do not need to take any action.
NoSpamProxy obtains its TLS client authentication certificates for O365 via Let’s Encrypt. Let’s Encrypt has provided a special profile for this transition phase that allows pure TLS client auth certificates to be requested.
Options for customers without automatic certificate generation via NoSpamProxy
All customers who do not obtain their O365 certificates automatically via NoSpamProxy or who rely on TLS client authentication in their own connectors should check which of the following options is suitable for them:
- Continue to use TLS client authentication with a certificate, provided that it is necessary and the server supports it;
- Switch to IP filtering.
- Find a CA that issues individual TLS client authentication certificates in addition to “normal” TLS server certificates and purchase these.
- Set up a private CA to issue the required certificates yourself.
Important note for Exchange Online customers
NoSpamProxy uses TLS client authentication by default for connecting to Exchange Online. If you use your own certificates, they must come from a trusted CA – otherwise Microsoft will not accept them.
You can use our automatic certificate generation or use a new certificate of your own without EKU.
Do you have questions or need support?
You will find a dedicated thread on this topic in the NoSpamProxy forum. Please use it for any queries or suggestions.
