BACKGROUND

In April, the CA/Browser Forum voted to progressively reduce SSL/TLS certificate validity periods according to this schedule:

• Current: Maximum 398 days
• March 15, 2026: Maximum 200 days (~6-7 months)
• March 15, 2027: Maximum 100 days (~3 months)
• From March 15, 2029: Maximum 47 days (~1.5 months)

THE PROBLEM

My company uses HTTPS to exchange electronic Business-to-Business (B2B) transactions with over a hundred trading partners. No browsers are involved - these are purely system-to-system integrations. Is it possible to get long-validity SSL certificates for system-to-system integrations?

The main problem is our B2B server SSL certificate does double duty:

1. It authenticates our SSL server to clients
2. It authenticates us onto partner B2B servers ("X.509 client certificate authentication")

So our SSL certificate has these two 'Extended Key Usage' fields set:

• TLS WWW Server Authentication (OID.1.3.6.1.5.5.7.3.1)
• TLS WWW Client Authentication (OID.1.3.6.1.5.5.7.3.2)

This means when we renew our SSL certificate, we must provide the renewed certificate ahead of time to B2B partners who we authenticate to using X.509 client authentication. Our renewed SSL certificate is then manually imported and configured to authenticate our account on their system. Every partner B2B system is different. So far, there's no automation available for updating client certificates on third party systems -- either from the ACME protocol or another tool.

The shortening certificate lifespans will create insurmountable operational burdens for us and some of our partners. We'll be reconfiguring client certificate authentication on external systems almost continually. Things will break!

I understand CA/Browser Forum restrictions are meant to target browser-trusted server certificates. Since our certificates are used exclusively for server-to-server communication (no browsers involved), can we obtain longer-lived (1+ year validity) certificates for B2B integration?

Can we get SSL certificates specifically marked "not for browser use" that would be exempt from the new CA/Browser Forum limitations?

If not, X.509 client certificate authentication will eventually die.

EDIT: CLARIFICATIONS

A lot of comments ask why client certificates must be imported and mapped to specific user accounts. Why not just "trust" the CAs that issued the cert? This is because client certs are used for authentication - they must distinguish one client from another and grant the client appropriate priveleges. To do this, the server imports the client certificate beforehand and maps that certificate to a user account on the server.

This is different to the 'normal' purpose of SSL server certificates (which merely assures a generic client that they have reached the right server).

Here's a concrete example: 'SAP Ariba' is a B2B Value Added Network (a B2B transaction intermediary). It uses client certificate authentication to identify itself to an SSL server. SAP Ariba's combined server+client certificates are [available here] https://support.ariba.com/item/view/192337).

The screenshot below is from a common B2B server application called 'webMethods'. Here, webMethods has imported the SAP Ariba's client cert (CN=service.ariba.com) and mapped it to a specific 'Certificate User' account for SAP Ariba. That account has the authority to carry out authorized actions on the server (e.g., submit a purchase order on behalf of a SAP Ariba customers)

[ webMethods MWS menu: 'Applications > Administration > System-Wide > User Management > Certificates > Certificate Details' ]

I hope this conveys why each client cert must be imported and mapped to a specific user account on the server -- this is so a client cert cannot (say) submit an order or invoice on behalf of someone else.

Note, my server implementation (IBM webMethods Integration Server) requires the client certificate pre-loaded and associated with a user account for client authentication to successfully complete. There's no option to 'map' only a subject CN or DN string to a user account. If a TLS connection presents a client certificate that is not preloaded, the TLS handshake completes but the client cannot be authenticated against a specific user account on our server.

So the server does NOT simply trust a client certificate presented at runtime that is signed by a trusted CA and has an appropriate 'Subject CN' (an alternative X.509 client authentication implementation approach suggested by comments below).

Instead, when the client submits a signed nonce (a random number) to the server as part of client certificate authentication, the server verifies whether a previously stored certificate can validate the signature. If yes, this is cryptographic proof the client's private key was used to sign the nonce (and hence crytographic proof of identity). I suppose the requirement to have the client certificate previously stored on the server enhances security. Otherwise a fraudster could gain access simply by fooling a CA into issuing him a new client cert (a CA could 'reset your password' in a matter of speaking :-)

I do agree with my software vendor's apparent security rationale (the stored certificate approach) because it eliminates the "weakest link" problem inherent in public CA ecosystems. With a purely CA-based validation approach, an attacker need only compromise one of hundreds of trusted Certificate Authorities to obtain a fraudulent client certificate that grants system access. Unlike server certificates, which require additional infrastructure attacks (DNS hijacking, server deployment), a fraudulent client certificate provides immediate authenticated access to systems.

I suspect the stored certificate approach may be widespread in other client cert authentication implementations. Say, I authorised SAP Ariba to trust my company's client certificate based on its CN string alone (not providing the actual cert). A fraudster has to fool just one of many hundreds of CAs. They can then merrily submit fake invoices to Ariba with different remittance instructions and my company could be on the hook for them.

WIDER IMPACT

The only solution I'm seeing so far in this thread is to switch client cert authentication from public to private PKI (that is, start issuing and using self-signed certificates). That will work but will be a disaster. Tens of thousands of organisations (probably more) use X.509 client cert authentication to secure trillions (maybe more) dollars of transactions per year. All these organisations would need to deliberate about the security implications of self-signed certificates and start issuing and using them. That is the precise problem that public CAs/public PKI was meant to solve, isn't it?

Instead, the move to private PKI won't happen. Most organisations will simply downgrade to lesser forms of authentication (HTTPS Basic Authentication - good old passwords). X.509 client certificate authentication will eventually die. That is a lose-lose situation.

Here's a rough graphic of how shrinking cert lifetime impacts the setup of client certificate authentication. Imagine N parties renewing SSL certs from their respective CAs (black links). These actions are capable of being automated. Now imagine 'm' is a subset of the 'N' parties who wish to do client certificate authentication with each other. There are m(m-1) certificate auth setup actions (red links). Above, I've explained how cert renewals require repitition of these actions. By 2029, an organisation must perform 1 cert renewal every 47 days (black link). This can be automated. But to keep client certificate authentication working, it MUST perform 2*m client certs update actions (receive m certs and send m certs) every 47 days. These client cert update actions are currently not capable of being automated - there is NO automation to push client certificates to third party systems - no ACME protocol, nothing! (I'd be delighted to be wrong! :-/ )

It looks like a carve-out is needed for "I know what I'm doing" organisations to use 1-year certificates for client certificate authentication. Is there somewhere I can raise this with the CA/Browser Forum or some association of CA registrars?