Hi,

Most likely what happened:

You tried to connect using the user-cert, and that failed? Then after that you added the user-cert (as .der file, others might not work) to the USERS_PKI/CA/certs?

Assuming yes to above, then then the cert is in 2 places. We would have stored it in the ‘rejected’ folder from the first connect attempt (the same works for the ApplicationInstanceCerts, but we do not yet have UI for user-certs). Then it would be in the ‘certs’ added by you. Thus, the cert is both trusted and rejected, and I decided at some point when we did some of the validation logic that in this case it is safer to assume it is rejected than trusted. Though, this whole concept should be redone as a “new certs” or something instead (and then everything not trusted is rejected i.e. that there would be no “rejected” folder per se). There is lots of historical legacy regarding the design.

Thus, basically all you should need to do, is to delete the user-cert from the rejected folder (or basically instead of copying the user-cert from elsewhere, you could have moved it from the rejected to the certs folder).

It is possible it was something else, but this would be the first thing to check.