Body
Overview
Some applications, particularly in research computing, grid computing, and mutual TLS (mTLS) environments, require certificates containing the TLS Web Client Authentication Extended Key Usage (EKU).
Historically, many publicly trusted TLS certificates included both:
- TLS Web Server Authentication
- TLS Web Client Authentication
Certificates issued through Purdue's InCommon Certificate Service do not include the Client Authentication EKU as of 11/05/2026.
Why Is This Changing?
This is an industry-wide change and is not specific to Purdue, InCommon, or CertiNext.
Public Certificate Authorities are moving away from issuing publicly trusted TLS certificates that contain the Client Authentication EKU. The CA/Browser Forum has approved changes that effectively phase out this practice, with a compliance deadline of March 2027.
Several major Certificate Authorities have already removed Client Authentication EKUs from their public TLS certificate offerings or announced plans to do so, including:
DigiCert remains one of the few major providers that currently offers certificate options containing the Client Authentication EKU and has published guidance regarding its transition plans and long-term alternatives.
InCommon and CertiNext
Purdue obtains publicly trusted certificates through the InCommon Certificate Service using the CertiNext platform.
CertiNext is expected to support multiple Certificate Authorities and continue expanding its available CA options over time. However, at the time of publication:
- SSL.com is the only newly announced CA option.
- SSL.com does not offer public TLS certificates containing the Client Authentication EKU.
- Additional Certificate Authorities are expected to be added to CertiNext in the future, but they have not yet been announced.
Because the broader certificate industry is moving away from Client Authentication EKUs, departments should not assume that future CertiNext CA additions will provide a long-term solution for this requirement.
Can I Still Obtain a Certificate with the Client Authentication EKU?
Possibly.
While Purdue's InCommon certificate offerings do not currently provide certificates with the Client Authentication EKU, some external providers and accredited IGTF Certificate Authorities may still offer them.
For example, DigiCert currently offers certificate options that include the Client Authentication EKU and has published information regarding future changes to those offerings. Removing the client authentication EKU from public TLS certificates
Organizations choosing this route should view it as a temporary solution and begin planning for alternatives well before the March 2027 deadline.
Purdue Recommendation
If your application requires the Client Authentication EKU, Purdue recommends planning a migration as soon as practical rather than waiting until support becomes unavailable.
Potential options include:
- Self-signed certificates within a managed trust environment.
- Locally issued certificates trusted by participating systems.
- Another accredited IGTF Certificate Authority that supports your requirements.
- A provider such as DigiCert while developing a long-term migration strategy.
Waiting until 2027 may result in certificate renewal, availability, or compatibility challenges.
Recommended Long-Term Practice
For systems that require both server authentication and client authentication, the recommended approach is to use separate certificates for each purpose.
Specifically:
- Use publicly trusted certificates for server authentication.
- Use locally managed CA-signed or self-signed certificates for client authentication.
Using dedicated client certificates aligns with the direction of the public certificate industry and avoids dependence on public CAs for client authentication use cases.
Benefits include:
- Greater flexibility in configuring Extended Key Usages (EKUs).
- Easy inclusion of the TLS Web Client Authentication EKU where needed.
- Independence from public CA policy changes.
- Reduced risk of future certificate renewal or compatibility issues.
- Clear separation between server identity and client identity.
Organizations currently using a single publicly trusted certificate for both server and client authentication should begin planning to separate those functions well before the March 2027 deadline.
Frequently Asked Questions
Can Purdue issue a certificate with the Client Authentication EKU?
No. The current certificate profiles available through Purdue's InCommon Certificate Service do not include the Client Authentication EKU.
Can Purdue add the Client Authentication EKU to an existing certificate?
No. Extended Key Usages are defined by the issuing Certificate Authority and certificate profile and cannot be modified after issuance.
Will future CertiNext Certificate Authorities provide the Client Authentication EKU?
Possibly. Additional CAs are expected to be added to CertiNext, and some providers may continue offering Client Authentication EKUs during the transition period.
However, because the industry is moving away from publicly trusted certificates for client authentication, Purdue recommends planning for alternatives rather than relying on future CA additions.
Does this affect normal HTTPS websites?
No. Standard HTTPS deployments require only the TLS Web Server Authentication EKU and are generally unaffected.
Additional Resources