X9 certificates for mTLS: what they are, how to order one and how to use it
An X9 certificate is not for putting a padlock on your website. It is for the opposite: so a server knows who the client calling it is. This article covers what that PKI is, how to order one and how to use it.
If what you want is to know whether the Chrome change affects you, start with Chrome stops trusting client authentication certificates and come back afterwards.
What the X9 PKI is
ASC X9 is the accredited standards committee for financial services in the United States — the body that defines, among other things, the messaging formats banks use between themselves. Its PKI is a certificate hierarchy belonging to the financial sector, with its own root, built so institutions can identify each other.
DigiCert operates that PKI and issues the certificates under it.
No browser trusts that root, and that is deliberate
This is the first thing to understand, because it is where people go wrong.
The X9 root is not in the trust stores of Chrome, Firefox, Safari or Edge. Install an X9 certificate on a public website and the browser rejects it with a not-secure warning. That is not a defect: the certificate is not made for browsers.
Trust here works the other way round from the public web. On a website, your browser trusts the server because a public authority signed it. In a closed PKI, both sides agree in advance which root they trust and install it on their systems. That is why it works between institutions that already have a relationship, and does not work with an anonymous visitor.
What it is used for
For mTLS: mutual TLS, where the client also presents a certificate and the server verifies it before letting it in.
The typical case is an API between financial institutions. The server does not only want the connection encrypted: it wants to know that the caller is that bank and not another one, and to know it before looking at any application credentials. A client certificate settles that at the transport layer, with no tokens to leak and no passwords to rotate.
DTCC — the United States securities depository — is the example with dates: it asked participants to migrate to X9 certificates, with the test environment (UAT) on 30 November 2026 and production on 31 December 2026. If you work with them, that is your calendar.
How to order one
You need three things:
- A CSR. Generated like any other: a private key of 2048 bits or more and a request carrying your organisation's details. The private key never leaves your server.
- Your organisation details, exactly. Legal name, address and country as registered. Validation checks against the official register, and a different abbreviation delays issuance.
- The names it will carry. The certificate is issued for one or more identifiers; if you need more than one, they are added as SANs with the order.
We handle these orders with assistance: you buy, send us the CSR and the details, and we carry the validation through with the authority.
How to use it
On the client side — the caller — you install the private key and the full chain we hand you, and configure your HTTP client to present them. In curl that is --cert and --key; in Java they load into a keystore; in Python requests takes the tuple cert=(crt, key).
On the server side — the receiver — you have to require the certificate and say which root to trust. In nginx:
ssl_client_certificate /path/x9-chain.pem;
ssl_verify_client on;
ssl_verify_depth 3;
In Apache:
SSLCACertificateFile /path/x9-chain.pem
SSLVerifyClient require
SSLVerifyDepth 3
And then, in your application, read the certificate subject to know who came in: nginx exposes it in $ssl_client_s_dn and Apache in SSL_CLIENT_S_DN.
Common questions
Can I use it for the website too? No. You need a separate public TLS certificate for the server; they are two certificates with two purposes.
Does the server certificate I already have authenticate clients? Until 15 March 2027, in some cases yes. After that, no: Chrome stops accepting client authentication on public certificates, which is why this migration exists.
How long does it last? One year.
How many names does it cover? One, plus whatever additional SANs you order.
What if my counterparty does not have the X9 root installed? They will not be able to verify you. Installing the root on the verifying side is part of the arrangement, and is normally required by whoever operates the service.
Next step
Look at the DigiCert X9 Client Authentication (mTLS) page, where the warranty, the terms and the additional-domains option are. If you do not know how many names you need or which counterparty you will be talking to, write to us before buying.
