Hi,

There is some ambiquity do you mean connection certificates (i.e. ApplicationInstanceCertificates) or user authentication certificates. Or both. ApplicationInstanceCertificates are used for connection i.e. OpenSecureChannel and both sides must trust eachother for the secure channel to be formed. User authentication certs are used in ActivateSession, similar to having a username+password (or think when using e.g. Git versioning).

The Simulation Server’s Certificates tab only shows connection certs, not user authentication certs (this was added much later). User certs must be handled via the filesystem, check in USER_HOME_DIRECTORY\.prosysopc\prosys-opc-ua-simulation-server\USERS_PKI (possibly you checked prosys-opc-ua-simulation-server\PKI only) . The Bad_IdentityTokenRejected would indicate that the cert was rejected, i.e. most likely it is not inside USERS_PKI\CA\certs (but it should be inside rejected folder next to the certs one). Ensure it is not in both certs and rejected folder.

Some terms in this topic in general can be used a bit loosely, but in short there is the public and private key parts of a keypair. Certificate is the public key part with additional info such as signatures and so on. The private key is completely separate from the certificate (but is needed to sign+encrypt data, which can be verified using the public key). The private key is never transmitted. For the certificate, i.e. public parts to my knowledge “do not contain any encryption”. The only encrypted part can be the private key. Or some storage formats do combine the 2 and that could maybe be encrypted, but we basically do not support those. The only properly tested way is the certiticate as a .der file and the private key as a .pem file.

Regarding loading a .pem + PKCS#8 we have at least one known not-yet-fixed issue that it doesn’t work for some encrypted format. It should be noted that previously it was assumed for .pem to “be a format of itself”. Anyway, if the .pem is opened in a text editor it should look something like this and then it should work:
—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,48A0F4AD3AE1975200E78CB7F8075BC2

GuyZQi…
for a password-protected key. For a non-password protected key it would look like:
—–BEGIN RSA PRIVATE KEY—–
MIIEvA…

most likely that is “PKCS#1” format.

Regarding your questions, there shouldn’t be any difference of supported key types regarding client or server.

User certs do not have “mutual authentication”, so for that I assume you mean connection certs. 2048 bit RSA keys work with all currently used security policies, those are also what our apps make. That is also the default in our samples and when not giving any size for the SDK. Note that in the future there can be also ECC keys, but we do not yet support them (but as far we know they aren’t used out there either yet).