Skip to content

Add SSLVerifyClientEKU directive to control Extended Key Usage checks for client certificates.#632

Open
studersi wants to merge 1 commit intoapache:trunkfrom
studersi:feature/SSLVerifyClientEKU
Open

Add SSLVerifyClientEKU directive to control Extended Key Usage checks for client certificates.#632
studersi wants to merge 1 commit intoapache:trunkfrom
studersi:feature/SSLVerifyClientEKU

Conversation

@studersi
Copy link
Copy Markdown

Summary

This change introduces SSLVerifyClientEKU on|off in mod_ssl to make EKU purpose enforcement configurable for inbound client-certificate verification (SSLVerifyClient).

Default behavior remains unchanged (on): certificates failing EKU purpose validation (X509_V_ERR_INVALID_PURPOSE) are rejected. If explicitly set to off, only that specific error is ignored; all other verification checks still apply.

Why this is needed now

In practice, many mTLS deployments have relied on publicly/centrally issued certificates that include clientAuth EKU, and application/platform assumptions were built around that profile over time.

The ecosystem is now moving toward tighter issuance policies where many CAs will no longer issue certificates suitable for client authentication in the same way. As that rollout progresses, existing deployments can encounter sudden invalid purpose failures even when certificates are otherwise valid and trusted.

For many operators, migrating to a dedicated client-certificate PKI (or fully re-profiling identity issuance flows) is non-trivial and may require significant lead time across multiple teams/systems. This change provides a controlled compatibility mechanism to support a grace period while migration completes.

What the directive enables

  • Maintains strict/default behavior for everyone by default (on).
  • Provides explicit, opt-in compatibility mode (off) for environments in transition.
  • Limits relaxation to one condition only: X509_V_ERR_INVALID_PURPOSE on inbound client cert verification.
  • Keeps all other certificate validation checks intact (chain, signature, validity period, revocation, etc.).

Scope and safety boundaries

  • Applies only to SSLVerifyClient flows (incoming client certs).
  • Does not apply to SSLProxyVerify / outgoing backend server verification.
  • Backward compatible by default.

Operational intent

SSLVerifyClientEKU off is intended as a temporary transition aid, not a permanent policy state. Recommended usage is tightly scoped (specific vhost/location) with a clear decommission plan once proper client-cert PKI migration is complete.

@studersi
Copy link
Copy Markdown
Author

studersi commented Apr 12, 2026

Note that there is also #192, which goes in a similar direction but solves a different problem.

Cases where SSLProxyVerify optional_no_ca is used, will still break, once the client authentication EKU is removed from certificates. If optional_no_ca is used to ignore verification issues, it makes sense that error with respects to the certificate purpose are ignored as well.

The directive that is introduced in this pull request here can be used to keep all other checks in place with SSLProxyVerify require and only granularly disables the EKU checks until the migration to a more correct client certificate PKI has completed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant