Learn how the change to TLS certificates impacts Wise webhook mTLS configurations.
An industry-wide change to how TLS certificates are issued will impact the current mTLS configuration that Wise uses to deliver webhooks to partners whose integrations rely on publicly trusted Certificate Authority (CA) issued client certificates.
Nothing changes in the immediate term. There is no impact to live traffic today, but the change requires a joint decision between Wise and affected partners ahead of the deadline.
This guide explains what's changing, who is impacted, and what you need to do to remain compatible.
- Mid Jan 2027: Production cutover (allowing a buffer for actions to be taken ahead of certificate expiry)
- 1 March 2027: Deadline when publicly trusted CAs will stop issuing TLS certificates containing the Client Authentication EKU
After the deadline, publicly trusted CAs including DigiCert will no longer issue certificates that can be used for mTLS client authentication.
Following a decision by the Chrome Root Program, publicly trusted Certificate Authorities including DigiCert (which issues the certificate Wise currently presents on webhook mTLS connections) will be prohibited from issuing TLS certificates containing the Client Authentication EKU from 1 March 2027.
The clientAuth EKU is what allows Wise's certificate to be used to authenticate Wise as the client in webhook mTLS connections to partner gateways. Without it, the TLS handshake between Wise and your gateway would fail.
This affects only outbound webhooks from Wise to partner gateways, where Wise acts as the mTLS client.
You are impacted if your integration meets both of the following:
- Receives webhooks from Wise over an mTLS-protected endpoint.
- Your trust store validates Wise's client certificate against a publicly trusted CA (for example, DigiCert).
If your integration already uses the Wise Private CA for webhook mTLS, you are unaffected by this change.
Each option requires a change on your side, so Wise would like to understand which of these are compatible with your security policy before recommending one.
DigiCert has introduced X9, a PKI designed for financial institutions that will continue to support client authentication after March 2027. This is the closest to the current arrangement and remains DigiCert-operated (but under a different certificate policy).
This allows Wise's certificates to continue being issued and managed by a globally trusted entity.
Wise will start supporting X9 from 15 Feb 2027 onwards in the lead up to the March 2027 deadline. We expect it to work with minimal changes to key algorithm or format once new certificates are issued.
Partners choosing this option should note:
- Because X9 sits outside the public browser trust store, you would need to explicitly install the X9 root into your gateway's trust store.
Wise operates its own private Certificate Authority for webhook mTLS, which is unaffected by this change.
- Default configuration for the majority of Wise Platform partners
- Available today
If you do not currently use this option but would like to, you need to install the Wise root and intermediate certificates into your trust store.
Review your certificate and trust policies to confirm which of the two options above are compatible.
Confirm whether your gateway currently validates against:
- The DigiCert root
- An intermediate CA or
- The leaf certificate itself
This is relevant for two further changes:
- Wise's DigiCert account is migrating from the US to the EU (which changes the intermediate but not the root).
- Maximum lifetimes for publicly trusted TLS server certificates are reducing industry-wide to 100 days in 2027 and approximately 47 days by 2029. This applies to publicly trusted TLS server certificates only. X9 client certificate validity periods are governed by DigiCert's X9 policy.
Validating against the root means both of these are transparent to you; validating against the intermediate or leaf requires changes on your side. Note that the shorter rotation cadence may still introduce operational disruption if your renewal process is not automated.
If you have multiple partnerships or environments with Wise, confirm that all will use the same mechanism and instructions.
Before production cutover:
- Install the agreed root (and intermediate, if applicable) in your sandbox trust store.
- Confirm the mTLS handshake succeeds with the new certificate.
- Confirm webhook delivery is unaffected end-to-end.
No. This change affects only outbound webhooks from Wise to your gateway, where Wise acts as the mTLS client.
No, the Wise Private CA is unaffected by this change.
Webhook delivery over mTLS will fail once the current DigiCert-issued certificate expires or can no longer be renewed with the clientAuth EKU. Starting the conversation early is intended to avoid this scenario.
Contact your Customer Success Manager if you have questions about operational queries. Otherwise, reach out to api@wise.com for technical queries.