Hi,

Please clarify do you mean by “user certifcate for authenication” 1. the connection certificates (Application Instance Certificates) or 2. user authorization certificates (that is one of the ways in ActivateSession, i.e. what would be set by UaClient.setUserIdentity)?

General:
Anyway, is is pretty much the same regradless of which one it was (or both). Currently in practice it is option 1 and/or 3. The problem with Option 2 would be that it would make someone else know your private key (the server would know the Client’s key and could fake being the Client Application), something of which should never happen. There might be a special scenario regrading GDS where that might be the only way, but normally that should not happen (and even there it would be the same entity controlling both client and server side per se).

GDS related:
In the future (or well in theory even now, though we do not have any specific support for it) you can also have a so called Global Discover Server (GDS). GDS sort of higher-level discovery server than a Local Discovery Server (LDS). You might e.g. have a GDS per a factory floor or something like that.

GDS can also handle the certificate provisioning and push them to an OPC UA Application (that has been coded to support a GDS). An application could also pull them instead. Thus the GDS would be a centralized place to manage certificates in case you have e.g. 1000 OPC UA Client/Servers on a factory floor. It would also maintain the trust lists etc. thus you would no longer move the certs in an individual application’s disk/configurations but instead configure them in the GDS.

There is both https://reference.opcfoundation.org/v104/GDS/docs/7.6.3/ StartSigningRequest + https://reference.opcfoundation.org/v104/GDS/docs/7.6.4/ StartNewKeyPairRequest. In StartSigningRequest I think (would have to check more closely once relevant though) the UA Application only knows the private key. In StartNewKeyPairRequest both the GDS + Application would know the private key. But the latter would only be used if a device is completely incapable of doing even the signing request (maybe some very tiny embedded device). Though in that case I think the owner of both client and server sides is the same entity so it probably wont matter that much. Though I would personally argue that if a device would be capable of validating certs I think it should also be able to create the signing request (though a source of a “secure random” source might be of an issue, though a µController might be able to use e.g. a floating input not connected to obtain some randomness, but based on some 1-minute googling apparently that is not a good source of entropy, e.g. a first result I got: https://www.pentestpartners.com/security-blog/want-entropy-dont-use-a-floating-adc-input/ so maybe for those cases it is a no-can-do scenario and GDS would have to provide it fully).