security-sensitive auth-bypass / identity-binding flaw

Description of problem:

This appears to be a security-sensitive authentication / identity-binding flaw in `certificate+pam` authentication when `cert-user-oid=SAN(rfc822name)` is configured and the client certificate has no `rfc822Name` SAN value.

In this case, the TLS client certificate is accepted (trusted CA, valid client cert), but the certificate-to-username binding may not be enforced if `cert_user_name` is empty and the client provides a username in the HTTP auth request. The server then proceeds with PAM (AD/TOTP) for the user-supplied username.

This is not a full mTLS bypass (a valid client certificate + private key is still required), but it appears to be an identity-binding bypass between the client certificate and the username.

I can provide full reproduction steps, sanitized logs, and a minimal patch privately.

Please share a private security contact/channel (or convert this to a confidential report if preferred).

Version of ocserv used:

ocserv/noble,now 1.2.4-1build2 amd64

Client used:

Cisco AnyConnect Windows 5.1.2.42

Distributor of ocserv

Ubuntu

How reproducible:

Reproducible: always, in our environment

Describe the steps to reproduce the issue:

Steps to reproduce
\

  1. Configure ocserv with `certificate+pam` authentication and:\
  • `cert-user-oid = SAN(rfc822name)`\
  • PAM/AD+TOTP enabled\
  1. Use a client certificate that is:\
  • signed by a trusted CA\
  • valid for client auth\
  • missing `SAN:rfc822Name` (or no such SAN entry)\
  1. Connect to ocserv using that valid client certificate\
  2. In the auth request, provide a valid username (e.g. `user@example.com`) and continue PAM/TOTP flow\
  3. Observe that ocserv proceeds with PAM auth for the provided username instead of rejecting due

Actual results:

- TLS client certificate verification succeeds\

  • `cert_user_name` extraction from `SAN(rfc822name)` is empty / unavailable\
  • ocserv still initializes `certificate+pam` for the username provided by the client request\
  • PAM prompts for OTP for the user-supplied username

Expected results:

If `cert-user-oid` is configured and the certificate-derived username cannot be extracted (empty/missing `SAN(rfc822name)`), authentication should be rejected **before** PAM is invoked.

The certificate-to-username binding should be enforced consistently, including when the client supplies a username in the auth request.

---
\

Code path / rationale (for maintainers)\


This appears related to `check_cert_user_group_status()` in `src/sec-mod-auth.c`:
\

  • There is a reject path for empty certificate username only when `acct_info.username` is empty.\
  • In the branch where `acct_info.username` is already set (from client request), the mismatch check is gated by `e->cert_user_name[0]`.\
  • If `e->cert_user_name` is empty, the `strcmp(...)` mismatch check is skipped and auth flow continues.

    I can provide an exact code pointer and a minimal patch privately.

    ---
    \

Impact\


A user with any trusted client certificate (and corresponding private key) may be able to authenticate as another user if they also know valid credentials/OTP** for that user, because the cert-to-username binding is not enforced when the configured cert username field is empty.

Again: this is not a full bypass of client certificate verification itself; it is a bypass of the expected identity binding between certificate identity and supplied username.