12/06/2021
I am developing an OPC UA server that will use anonymous and username/password authentication. I was surprised that when I made a connection to the server, I had to manually move the clients certificate into the ‘trusted’ folder before it could connect. I have discovered the AutoAcceptUntrustedCertificates feature which seems to solve my problem, but I am trying to understand the rationale behind this comment in the sample server:
———————————
<!– WARNING: The following setting (to automatically accept untrusted certificates) should
be used for easy debugging purposes ONLY and turned off for production deployments! –>
<AutoAcceptUntrustedCertificates>false</AutoAcceptUntrustedCertificates>
———————————
If a client is connecting to my server, why is it important for the server to also validate their certificate? To me this seems analogous to a HTTPS server. It is not necessary for every web browser to have a certificate in order to establish trust, the onus is on the user to verify the servers certificate. It would be extremely inconvenient if every time you communicated with a new HTTPS website, the website owner had to add your browser certificate to their ‘trusted’ folder.
I am concerned by disabling AutoAcceptUntrustedCertificates, the workflow for a client connecting to my server is going to be needlessly complicated. But equally I don’t want to enable this feature if there are genuine security problems introduced by it.
Thanks
05/30/2017
In industrial automation the systems are tested and locked down. i.e. you can have a cell with a few PLCs and an HMI panel and only the HMI panel is allowed to talk to the PLCs. Specially, you do not want an operator to download a UA app on their phone or laptop and connecting directly to the PLCs and using the legitimate user credentials they have. Client certificate authentication is the feature that makes those types of restrictions possible.
That said, there are applications that legitimately need to allow any client to connect and can choose to accept all certificates, however, these applications may grant more restricted permissions to clients that are not trusted. IOW, the server is still aware of the untrusted state and uses that information to decide what the client can do.
For any large UA system you will need a GDS/CertificateManager that centrally manages TrustLists and Certificates because manually configuring every node is not practical.
05/30/2017
OK I think I can see your point. If somebody wanted to perform malicious actions, they could do this stood at the HMI, but they risk being seen. Whereas if they could perform those malicious actions remotely from an unauthorized client, they might be able to get away with it
It is more than that. The HMI software could limit the actions that are available but a generic test client downloaded from the internet could allow many more things to be done. It also does not have to be malicious – employees trying to do their jobs by working around s/w limitations can cause a lot of damage.
02/24/2014
There are also capacity concerns. Many OPC servers are in embedded devices withy limited resources. They will only support certain number of sessions etc. And you really want these sessions be used by client devices that the system was designed to have, and not by additional “random” devices, because that would prevent the right ones from connecting, and disrupt the operation of the system.
User authentication is orthogonal to this, because for such concerns, it is irrelevant who is the user of the device.
12/06/2021
Randy Armstrong said
OK I think I can see your point. If somebody wanted to perform malicious actions, they could do this stood at the HMI, but they risk being seen. Whereas if they could perform those malicious actions remotely from an unauthorized client, they might be able to get away with it
It is more than that. The HMI software could limit the actions that are available but a generic test client downloaded from the internet could allow many more things to be done. It also does not have to be malicious – employees trying to do their jobs by working around s/w limitations can cause a lot of damage.
My plan was to very carefully design the node space and permissions/roles so that they have no more rights over OPC UA than they would have through the HMI. It would also be a hard requirement that no more damage can be done than they could also do through the HMI. The administrator of the device would also be able to select on a per-user basis which users have permission to connect over OPC UA – and by default probably none of them would have this right. So with these things in mind and circling back to the original question, do you still see authentication of client certificates valuable in this scenario?
05/30/2017
do you still see authentication of client certificates valuable in this scenario?
Implementing client authentication is mandatory if you want to be compliant with UA. It is possible that your use case could justify turning it off in some cases but the capability still needs to be there.
Your concerns about managing the trust list on the server can be addressed by implementing the Part 12 push interface:
https://reference.opcfoundatio…../docs/7.3/
This is technically optional, however, a device that does not support it will be very hard to use.
12/06/2021
Hi Randy
Please could you clarify whether the two-way application certificate authentication should also be performed when using SecurityPolicy=None?
Should the server authenticate the clients application certificate?
Should the client authenticate the servers application certificate?
Thanks
1 Guest(s)