OPC UA Client security configuration for production use|OPC UA Implementation: Stacks, Tools, and Samples|Forum|OPC Foundation

Avatar
Search
Forum Scope


Match



Forum Options



Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
OPC UA Client security configuration for production use
Avatar
Max Ivanov
New Member
Members
Forum Posts: 1
Member Since:
05/10/2021
sp_UserOfflineSmall Offline
1
05/10/2021 - 03:49
sp_Permalink sp_Print

Hello,

I’m wrapping my head around OPC UA and security topics specifically. 

So far I’ve checked resources in Online Reference:
https://reference.opcfoundatio…..s/Part2/8/
https://reference.opcfoundatio…..rt4/6.1.3/
https://reference.opcfoundatio…..Part4/7.2/

And this very helpful video from @Randy Armstrong:

Context

There’s a SAAS software that has an OPC UA client in it. Customers log in to the software and enter their OPC UA server details.
The application would then read and write values to the customers’ servers. Customers have no control over the client instance and the client has no control over the servers.

Initial (non-production) setup

So far this (test) configuration works fine:

– For an example Customer Server I use Kepware free server, it has a self-signed certificate.
– Customers enter following fields manually in the SAAS user interface: UA server URL, Security Policy, Message Security Mode, Server Certificate (PEM format), Username & Password.
– Client App uses customer-provided server certificate to verify the connection security. If there’s no match, connection is never established.
– Client App uses a self-signed client certificate that has to be trusted on the server after initial connection attempt.

Improvements for production

Please let me know if I get the following right and if there’s anything that I’m missing.

1. Let customers upload not only the server certificate but also the signing certificate. In latter case it will need to be placed in the “Issuers” trust store on the client. Rationale is for customers to not have to upload new server certificate each time it renews.

2. If customer’s server certificate is commercial CA-signed, they may not need to provide anything. The client (or the OS certificate store it uses?) may not know that CA though, so it sounds like it’s safer to always ask to upload the server certificate/CA certificate.

3. From what I understand commercial CA-signed certificates make sense for UA servers because server hostname is part of the certificate. If the client trusts the CA AND if the URL in the certificate matches the URL client connects to, the server is authenticated. Commercial CA-signed certificates do not make much sense for clients though, since there’s no identifier in the certificate that cannot be faked. Anyone can issue a certificate with that commercial CA and it would be trusted.

4. Thus it makes sense to create a SAAS-company owned CA and sign client certificates with that. Customers would be able to download the CA public key from the SAAS user interface. They would then install that public key in server’s “Issuers” folder. When time comes and client renews the certificate, no change would be required on the server.

5. What are the requirements to the CA and/or certificates issued by the client? Does it depend on the Security Mode (Basic256Sha256, Aes128_Sha256_RsaOaep, etc) selected by the customer when adding a server? Would appreciate some guidance or links for further research.

6. Improvement: when customer adds a new server, use discovery features provided by the server (if any) to narrow down options of security polcies and message security modes supported by the server.

 

Sorry that became a long post but I wanted to make sure my understanding is correct. Thank you!

Avatar
Randy Armstrong
Admin
Forum Posts: 1580
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
2
05/10/2021 - 22:37
sp_Permalink sp_Print sp_EditHistory

1) This is what always has to be done. If KepServer supports it you can also pass the CA chain as part of the secure channel handshake.

2)  A UA trust list is empty by default. It is not like a webserver that has a preconfigured list of commercial CAs. You will need to explicitly add each commercial CA as you do in 1). Commercial CAs also may not support CRLs which would mean it would not be possible to do revocation checks which makes them less secure.

3) For most industrial systems the hostname is not visible on Internet which could make it difficult to acquire a commercial CA signed certificate.

4) Enterprise CA should be default with commercial CAs limited to cloud based servers.

5) See https://opcfoundation.org/UA/Se…..c256Sha256

The page has all CA and Certificate requirements. Same for all SecurityPolicyUris

6) This should be your initial implementation. The discovery mechanism is there to automatically configure clients. The only human intervention needed is an admin to verify that certificates presented are legitimate and ensure they are not connecting to a phishing/rogue servers. Spending time developing a manual process would increase your overall development time.

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 22
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1446
Posts: 4891