When creating a federated user with a certificate, after adding the certificate and clicking "OK", it saves the certificate to the client_cert table in the database.
But hasn't attached it to the user record yet (fed_user table).
However, if a user already existed with a certificate of the same DN (same or different expiration/serial/issuer/etc)... there are now two in the client_cert table.
If you try to save the user, you are given a warning "The users login, email, or X.509 Subject DN conflict with an existing user."
and the properties window remains open and you must cancel to close it.
However, the user has saved, the certificate has saved, and by all appearances you have created the user you intended to create.
You can then open and modify the user normally, and it saves fine.
Except, that user cannot be logged into using the certificate identified in the users record. Apparently because the fed_user.subject_dn column is empty.
It is unclear in the documentation that two users cannot use certificates that have the same subject dn.
And because the UI will allow the creation of two users with certificates that have the same subject dn,
it is virtually impossible to identify why the client's new certificate is failing to authenticate the user.
It is very common to need to have both and old, and new client certificates loaded to allow client systems a transition period during cert replacements.
It appears in the UI that you can do this, but functionally things don't actually work and no logging as to why the second account is failing to authenticate is provided.
CA API gateway 11.1
Creating a new FIP user and importing a new certificate (new thumb-print, issuer, expiry, etc) but with the same Subject_DN of an existing FIP user and encounter the error
"The users login, email or X.509 Subject DN conflict with an existing user", this results in the fed_user table containing the new user but with a empty subject_dn column value.
Note: At this time the client_cert table contains both X.509 certificates.
Thus when an application establishes a TLS handshake/connection and presents client certificate associated with this new FIP user to the GW for AuthN against a FIP it fails.
Code change in process to fix the incorrect Certificate Import UI behavior.
DE631130