Security settings management using the SecuredApplication|OPC UA Standard|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
Security settings management using the SecuredApplication
Avatar
Reinhold Dix
Member
Members
Forum Posts: 4
Member Since:
06/04/2020
sp_UserOfflineSmall Offline
1
07/07/2020 - 01:04
sp_Permalink sp_Print

According to Part 4, 6.1.3 UA applications have two lists of trusted certificates: one for applications, and one for certificate authorities.

How would you handle these two lists with the SecuredApplication having only one single TrustedCertificateStore 'containing the Certificates of applications or Certificate Authorities (CAs) which can be trusted' (s. Part 6, Annex E.2 SecuredApplication)?

Avatar
Randy Armstrong
Admin
Forum Posts: 1445
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
2
07/07/2020 - 04:34
sp_Permalink sp_Print

The text was not clear and has been updated for 1.05

https://apps.opcfoundation.org.....hp?id=4666

Applications shall never communicate with another application that they do not trust. An Application decides if another application is trusted by checking whether the Application Instance Certificate for the other application is trusted. A Certificate is only trusted if its chain can be validated. Applications shall rely on lists of Certificates provided by the Administrator to determine trust. There are two separate lists: a list of trusted Certificates and a list of issuer Certificates (i.e. CAs). The list of trusted Certificates may contain a Certificate issued to another Application or it may be a Certificate belonging to a CA. The list of issuer Certificates contains CA Certificates needed for chain validation that are not in the list of trusted Certificates.

When building a chain each Certificate in the chain shall be validated back to a CA with a self-signed Certificate (a.k.a. a root CA). If any validation error occurs then the trust check fails. Some validation errors are non-critical which means they can be suppressed by a user of an Application with the appropriate privileges. Suppressed validation errors are always reported via auditing (i.e. an appropriate Audit event is raised).

Determining trust requires access to all Certificates in the chain. These Certificates may be stored locally or they may be provided with the application Certificate. Processing fails with Bad_SecurityChecksFailed if an element in the chain cannot be found. A Certificate is trusted if the Certificate or at least one of the Certificates in the chain are in the list of trusted Certificates for the Application and the chain is valid.

Avatar
Reinhold Dix
Member
Members
Forum Posts: 4
Member Since:
06/04/2020
sp_UserOfflineSmall Offline
3
07/08/2020 - 02:02
sp_Permalink sp_Print

Many thanks, Randy!

Basically, the text in part 4 was clear, but wrong...

Please consider that

1. The modified text declares 'The list of trusted Certificates may contain a Certificate issued to another Application or it may be a Certificate belonging to a CA.', however the trust list may contain also sef-signed certificates.

2. In addition to part 4, section 8.1.4.2 Developers Certificate management of part 2 should also be fixed.

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