OpenVPN: could not extract CN from X509 string

[tyrell]

Hey everyone,
i configured OpenVPN and with 2/3 Windows Clients with the OpenVPNConnect software its working (connecting, ip adress, routing)
The other windows client and die mac os client and one linux client get all this error on Client side:

VERIFY ERROR: could not extract CN from X509 subject string
2024-08-30 16:21:38 VERIFY ERROR: could not extract CN from X509 subject string ('C=DE, ST=xxxxx, L=xxxxxx, O=xxxxxx, OU=IT') -- note that the username length is limited to 64 characters

In OpenVPN Logs i get a TLS handshake failure.

I know there is no CN in that String.
Auth is obv. with LDAP. Really dont get where the difference is.
How do i add the CN to the subject string?

[doktornotor]

How do i add the CN to the subject string?

With no knowledge of how you created the certificates (clearly not using the certificate management on OPNsense), noone can provide an answer. Maybe review the docs here for some clues on certificate requirements:

https://openvpn.net/community-resources/setting-up-your-own-certificate-authority-ca/

CN is mandatory.

The only parameter which must be explicitly entered is the Common Name.

It also specifically mentions "Always use a unique common name for each client." - which some users apparently ignore.

[tyrell]

That helped! thanks a lot.

But im still in struggle with the cert export.
As i am authenticating with ldap which cert do export? does every client use the same cert?
Under my Instance i put 10.0.10.0/24 in "Server IPV4"
but it seems every client is trying to get the same IP (10.0.10.2).

[doktornotor]

Well, as already said - the upstream recommendation clearly is "Always use a unique common name for each client", meaning one certificate per client. Revoking one certificate seems like a whole lot less work that distributing new "common" certificate to XX users after the previous one had to be revoked due to one staff member leaving or certificate got compromised.

Also, this "Strict User/CN Matching" is not doable with all people having the same certificate.

[Patrick M. Hausen]

Revoking one certificate seems like a whole lot less work that distributing new "common" certificate to XX users after the previous one had to be revoked due to one staff member leaving or certificate got compromised.

We do not revoke the certificates when an employee leaves. We disable the AD account and the user is locked out of all services. The certs are strictly so TLS works at all.

Kind regards,
Patrick