How to authenticate using UserTokenTypeCertificate?

[tommys]

Hello,
I've a working UA-OPCUA-server supporting all kinds of security policies and message security modes, all using the UserPw authentication method, and different users have different roles. Well, that's all cool and nice :-)

Now, I'd also like to add support for the UserTokenTypeCertificate authentication method, therefore calling: serverConfig.setEnableCertificate(true); as the first trivial step. In principle, that's it - or...?

I'd like to accept user certificates that have been signed by a trusted intermediate CA, which I guess will work fine out of the box.
What about self-signed user certificates? Will those certificates always be considered valid if the private key is correctly used (valid signature), which gives a false sense of security, since anyone can create such certificates, is that really the case? If so, how can I prohibit that? I guess I have misunderstood something...

Next important thing is how I assign a specific role for the authenticated user? Sure, I can assign all UserTokenTypeCertificate-authenticated users to a default ReadOnly role for example, but that does not feel like a very good way of doing things. I think I must have missed something here. A hack(?) could maybe be to add the username to an extension of the X.509v3 certificate and override Session::activate to read out username from certificate and map it to its role according to the user and role database?

I've looked in the samples but have not been able to find anything showcasing how this should be done. And from the documentation it is not clear to me what needs to be done. Any guidance would be much appreciated!

/Tommy

[Support Team]

Hi,

the user-certificate is a secondary login option, hence somewhat "replaces" both the user-and-pwd, whereas you need an identifyer (instead of user-name), and you need to trust the public key of self-signed individual, or the CA to trust all the people signed by this CA (instead of PWD validation). Our SDK has separate PKI stores for users and applications.

I guess I have misunderstood something...

Yes, the self signed public key must be (validated by some admin and) trusted in the server's User-PKI-Store, same procedure as with application certificates. The private key will never be handed out.

The OPC Specification does not say anything on what to be used for "identification" of individual person inside a user-certificate, you could use (as already proposed) e.g. the Comon Name (CN=John) and put user-name inside the certificate content. You would read out such content and check this user-name against the user/role assignement. Other option would be the Sha of the certificate to be used as unique identifier for this one individual person, independent of any content.

In any case, the "identifyer" of the individual person must be mapped on the role (name or Sha makes no difference), this is server specific logic, hence could be implemented either way. You could also use the Sha, map it on a name, and continue using the name/role assignement as-is with the user/pwd authentication, this would give "John" a secondary login option.

[tommys]

Thank you for the prompt answer! Now I know I'm on the right path so I continue with this approach. Thx :-)

[Support Team]

Hi,

there is lot of magic already done by the SDK, includin the x509 user authentication in the context fo role based security. However, to understand the principle, there is some good information in the OPC UA Specification (part 18).

Hint: Using x509Subject as "identifyer" for the user is the best option you have, because when re-newing certificate the x509Subject (content) remains identical. This is fundamentally different when using the thumbprint of the certificate, because that will change when re-newing, hence would require to update all the role mapping assignment in all servers that have used this identiy.

[tommys]

Ok, I think I see what you mean.

So, instead of trying to "hook" into the system looking for a user name in a certificate subject and adding that user's role to the session, I can get this to work automatically.

And for that to automatically work I need to configure, not only the simple and straightforward username-role-mapping, but also the X509Subject criteria with the identity "CN="useroftheclient"/O="TheOrganization"/OU="TheUnit"/DC="whatever"/L="Location"/S="VG"/C="SE"". I then add this IdentityMappingRule to a RoleTypeOperation, which in turn is added to the RoleConfig's list of RoleTypeOperations.

And when that user is connecting and is authenticated (using the Certificate method), its role will be found and assigned automatically. That's nice. Thank you for the hint :-)

/Tommy

[tommys]

I have problem to get this to work. Maybe it is just a simple certificate thing...

I've generated a self-signed user certificate and use UaExpert to connect my UA OPCUA server using the Certificate authentication method. Of course, the server have a copy of that certificate in its pkiuser/trusted/certs directory.

Despite it being a self-signed certificate, the pkiProvider.ValidateCertificate in the serverManager::validateCertificate method, returns with an error: 0x801B0000 and the validationCode: 3, indicating that it is "unable to get certificate CRL", which I think is really not relevant for self-signed certificates. Or?

Do you happen to have an example of a valid OPCUA User Certificate that can be used to ensure that everything else works and it is just my certificate that is invalid.

For reference, here are my simple steps to generate the user cert:

Code: Select all

# Generate the private key:
openssl genrsa -out user.key 2048

# Generate the certificate signing request (CSR) with the extension information:
openssl req -new -key user.key -out user.csr -config user-cert-v3ext.cnf

# Now self-sign the certificate:
openssl x509 -req -in user.csr -signkey user.key -outform der -out user.der -days 365 -extensions v3_ca -extfile user-cert-v3ext.cnf

# Content of my user-cert-v3ext.cnf
[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
x509_extensions = v3_ca

[dn]
C = SE
ST = VG
L = Gbg
O = Company
OU = Unit
CN = Username

[v3_ca]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = phoenix
IP.1 = 192.168.3.42

[Support Team]

Hi,

same as with application instance certificates, the user certificate can use the full PKI, hence being signed by a CA (or a chain of intermediates and a CA), the validation method is exactly same as for the application certificates. It is just a different store, and you may look for different content within the certificate.

However, every CA signed certificate must be accompanied with the corresponding CRL, the revocation list of that CA (and for all intermediates if any), in order to be validated corrrectly. Same validation same rules for "user" and for "application" certificates.