fipUser certificate update by graphman

[Michael Mueller]

Dear Team.

We just updated a certificate of a fipUser with graphman.

This cert is used to identify and authenticate this user against an incoming mtls client cert.

Unfortunately, the authentication did not work after the graphman import.

Then we updated the user cert manually through Policy Manager and the authentication was working again.

Comparing the graphman exported cert before and after the manual cert update, reveals only a change in the checksum.

Is that an expected behavior?

Will graphman be able to update a user certificate, without going through the Policy Manager?

Or do we need to do special activities during the import to make the new cert working seamlessly ?

Gateway v11.0

graphman-client V1.0.00

Thanks and kind regards

...Michael 

[Raju Gurram]

@Michael Mueller I've tested with my local gateway and it seemed working for me. I will check with the exact test base as you mentioned. Meanwhile, could you please give me more details about your federated idp configuration. 

• are you trusting the signers with the federated idp?
• incase if the user cert is self-signed, are you trusting it with the federated idp? For which, you need to consider modifying the federated idp as well.

[Michael Mueller]

Hi Raju.

Perfect. Thanks for taking a look into this. Very much appreciated !

• The federated idp has not trusted certs configured.
• The certificate in scope is assigned to the fip-user.
• the same cert is stored in the gateways trusted store and flagged as a trust anchor.
• both certs (fipUser and TrustedCert) were updated at the same time(same JSON bundle)

As my initial thread question was based on observations from colleagues, I would need to do some re-tests on my own to provide further information and do some double checks.

Anyway, the main point for me, right now, is , that there is no principal issue with this scenario. Like, a gateway restart necessity.
Meaning: This scenario should work !

I will come back to you, as soon I have done further testing.

Thank you.

...Michael

[Michael Mueller]

Hi @Raju Gurram., dear Team

I am coming back to this old question.

Unfortunately we encountered again an issue with updating certificates of IDP users via graphman

The issue is related to, that mtls client cert authentication isn't working anymore afterwards, even though the cert data seems to be okay.

Here is our procedure:

1. export fipUser data from gateway using fipUserByName
2. explode exported data with --options.level 2
3. overwriting certificate pem datafile with new certificate
4. imploding data
5. importing data

This works from an update point of view.

However, we identified an issue, when the subject of the new cert is different to the old one.

In this scenario, the procedure from above works fine regarding the update, but it fails afterwards when used for authentication.

Obviously the subjectDn property of the user needs to match the certs subject to get a working authentication.

Unfortunately, when incorporating the new subjectDn value into the exploded data, the import fails with a constraint error on "fed_user.PRIMARY".

In fact I have no clue why this is happening, as I only want to update an existing record. The messages are looking like:

• 2026-05-06T13:06:29.296+0100 INFO 2485 com.l7tech.server.admin: FederatedUser #09ae1d81180eb501c9c5c77415b74f1b (omeg7153.omega.internal) created
• 2026-05-06T13:06:29.299+0100 INFO 2485 com.l7tech.server.admin: FederatedUser #09ae1d81180eb501c9c5c77415b74f1b (omeg7153.omega.internal) updated (updated)
• 2026-05-06T13:06:29.300+0100 WARNING 2485 org.hibernate.engine.jdbc.spi.SqlExceptionHelper: SQL Error: 1062, SQLState: 23000
• 2026-05-06T13:06:29.300+0100 SEVERE 2485 org.hibernate.engine.jdbc.spi.SqlExceptionHelper: Duplicate entry '\x09\xAE\x1D\x81\x18\x0E\xB5\x01\xC9\xC5\xC7t\x15\xB7O\x1B' for key 'fed_user.PRIMARY'
• 2026-05-06T13:06:29.301+0100 INFO 2485 com.l7tech.external.assertions.gatewaygraphql.server.resolver.mutation.BasicGraphQLMutationResolver: Error creating or updating USER entity, constraint violation - could not execute statement
• 2026-05-06T13:06:29.303+0100 WARNING 2485 com.l7tech.external.assertions.gatewaygraphql.server.ServerGatewayGraphQLAssertion: Rolling back the operation-level transaction

I can only assume, that the incoming graphman request lead to an insert into the fed_user table, because the lookup criteria is not the providerName and the username, but the subjectDN. As the subject has changed and is not existent yet, but the user-record goid was presented as well, a new record gets created with the same goid but different subjectDN. But sure this fails on commit, as it collides with the existing user record.

Hmm, is this by intent ?

Due to this behavior, the only chance we have right now, is to delete the existing user first, and then import the user with new certBase64 and subjectDn data.

Are my considerations correct, and is this "delete first" approach appropriate? Or do we have other options?

Thanks for comments.

Best regards

...Michael

-------------------------------------------

[Michael Mueller]

Dear Team, dear @Raju Gurram.

I found the reason, why the lookup for an existing user failed.

The json bundle data was missing the property value for "login". The value was just empty.

Setting up the user with name and login (same value) provides the ability to import a user with new subject and new certBase64 data seamlessly

Doing so, authentication is working afterwards, as expected.

No need to delete existing user beforehand !!

As so often, once you describe a problem, you get a better understanding of the issue, getting additional ideas, and sometimes finding solutions on your own.

Thank you anyway

Best regards

...Michael

-------------------------------------------

[Raju Gurram]

@Michael Mueller

Your reasoning is correct. I'm glad the problem was resolved.
FYI, federated users are identified for set-based mutations in this order.

• uses login field when specified.
• if not, uses subjectDn field when specified.
• if not, uses name field

It would definitely be a problematic if the intention is to updating one of these fields using set-based mutation. For the same reason, we would be introducing separate field methods for updates. 

You might expect entity-type specific field methods in future releases.

- updateFederatedUser

Until then, it's kind of feature gap for modifying the identity fields for the existing records.

-------------------------------------------

[Michael Mueller]

Hi @Raju Gurram.

Thank you for these insights. They help to understand the circumstances much better.

But isn't there a gap or mismatch?

The subjectDn value is a derived value from the certificate data (certBase64), in my understanding.
Shouldn't it be set to the corresponding certificate value always automatically?
Similar to what is done in the trustedCert context, to avoid mismatches between certBase64 data and derived subjectDn value?

Regards

...Michael

-------------------------------------------