Support for 10000-21 and IDevId

[miikka-mikkonen]

Hello,

I have a question related to UaGDS and devices implementing 10000-21 for onboarding of devices.

I (we) are currently in the process of implementing support for GDS Push in our OPC UA server (embedded device). Our plan is to load an IDevId certificate in production signed by our own CA so that our customers can validate the authenticity of our device.

While testing this with UaGDS we get error for BadCertificateHostNameInvalid:
https://imgur.com/dZiK5uG:


This is because the IDevID certificate does not include subjectAltName field for iPAddress, as this cannot be known at the time of manufacturing. We also don't want to generate a self signed certificate with this data as that defeats the purpose of having the IDevId in the first place.

I tried disabling this check in the UaGDS settings (and disabled all other checks as well), but I could not get it to work with this setting. In particular: General.DisableError.CertificateHostNameInvalid is set to true.
https://imgur.com/AMW9Tk9:


If we add the used iPAddress to the IDevId certificate ourselves, then the connection can be established.

From OPC UA 10000-21 chapter 7.2:

Registrars shall not accept Devices they do not trust. The steps to determine trust are:
1) Read all DeviceIdentity Certificates from the Device;
2) Locate a Ticket that has a ProductInstanceUri that matches one or more DeviceIdentity Certificates;
3) Validate the Ticket if it has not already been validated (see 6.4);
4) Select and Validate DeviceIdentity Certificate that matches the Ticket;
5) Establish a secure connection to the Device using the selected DeviceIdentity Certificate.
6) Issue a DCA Application Instance Certificate to the Device that indicates that it has been authenticated.

So my assumption is that IDevId certificate is ok to use, the GDS should accept this certificate, and then the device will add all required fields to the CSR, so that after that the new certificate is a valid Application Instance Certificate according to 10000-6. This also includes for example setting the uniformResourceIdentifier in subjectAltName from "ProductInstanceUri" to "ApplicationUri".

[Support Team]

Hi,

The connect error comes from the UaGDS service that tries to executed the push sequence.
What you tried to configure is the settings of the UaGDS Configuration Tool, but not the UaGDS itself. It is currently not possible to suppress the hostname check in the UaGDS service.

UaGDS is not prepared to use mechanisms from OPC UA Part 21 for device onboarding.

The secure onboarding described in Part 21 requires more information than just the IDev certificate. It would be necessary to get a ticket from a trusted entity that provides a list of expected devices that should be automatically onboarded by the GDS. Also the issuer of the IDev certificate must be trusted by the GDS. This would allow the GDS to make the verification based on this information and to skip other standard security checks.

The key thing is that an administrative entity tells the UaGDS that a device should be added. This could be done through a ticket or by providing the certificate of the application which could be the IDev certificate.

The second option with the certificate is something that we have on the ToDo list already since there are other scenarios where this is needed. To suppress security checks like the hostname check is something we consider to add to requirements list. The full support for Part 21 is more work.

For now, you will need correct hostname (or IP) in the certificate, to make the UaGDS succeed when checking for correctnes.

[miikka-mikkonen]

Hi and Happy New Year!

I have been further studying, testing and asking OPC foundation clarifications on the standards. They agree that there is a gap, that devices supporting Part 21 have an issue with GDSs that don't support it (this exact issue), as it is optional to support suppressing hostname etc. checks in Application Instance Certificates. To be clear, we are not looking into everything in Part 21 (ticketing system etc.), but mainly picking features we think are most relevant (mainly IDevId certificates that are signed by our own root CA).

I hope that the following quote from Part 21 will get added to Part 12 as a mandatory feature for GDSs:

The process of verifying a Certificate is described completely in OPC 10000-4, however, checks that are specific to Application Instance Certificates do not apply (e.g. the HostName and ApplicationUri checks).

For now, we got a suggestion to add a default hostname to our IDevId certificate. I have been able to establish a connection using UaExpert and been able to validate that it is happy with our IDevId certificate (warns about ApplicationUri but that is expected). With UaExpert I can also establish a connection using the hostname as the Endpoint Url.

However, when using UaGDS, I cannot get a connection established.

When using the hostname as the Endpoint Url, I can see that our device appears in the "Select Server" window, but when trying to establish a connection, nothing happens (validated from Wireshark). Just some mDNS queries, to which our device replies.

The Test connect result is "Bad", and the Last Action Status is "PUSH certificate and trust list failed at Discovery with local status Bad".

I enabled all trace logs but was not able to find any logs that would help me.

If I use the IP address as the Endpoint URL, I get "Invalid hostname" error as before. After adding the IP Address to our IDevId certificate (not something we can really do but for test purposes), then everything works as expected.

The second option with the certificate is something that we have on the ToDo list already since there are other scenarios where this is needed. To suppress security checks like the hostname check is something we consider to add to requirements list

Do you have any time table when this suppressing could be implemented? This would be our preference (even if we get everything with hostname to work correctly).

We would also be willing to test any alpha/beta build you have if you would find that helpful, getting UaGDS compatible with our device is a high priority for us.

[Support Team]

Hi,
happy new year!

We understand your usecase being device with "pre-filled" CA-certificate during production, at times where the hostname/IP of such particular device is unknown. This needs to be clarified and alligned with OPCF onboarding process. Whatever marker is in the pre-filled certificate (if not hostname/IP) some admin must be able to identify uniquely in order to approve during registration process with the GDS (e.g. have serialnumber in certificate, or have one-time ticket information) to verify this step during the onboarding process.

As of now our UaGDS assumes that devides create their own transport certificates themselves (e.g. at first startup or by administration/engineering), therefore the UaGDS will check for host/IP for identification of that device (at time of registration the device will have host/IP, but in your case it does not match with the certificate), and thereafter UaGDS will sign with own CA after being requested (CSR) to do so.

[miikka-mikkonen]

Does UaGDS support mDNS and connecting to devices using the hostname as the endpoint URL?

Our device uses mDNS, the endpoint URL is "opc.tcp://<hostname>.local.:4840", and I have the hostname in DNSNames in SAN extensions (with and without the final dot and the for test purposes, should only need the hostname.local.) in our IDevId certificate. The endpoint scan works fine and I can establish a connection without any errors or warning with OPC UA clients like UaExpert (that also validate the certificate).

The UaGDS configuration tool can also find the device, resolve the IP and find the supported policies.

But when I try to test the connection with UaGDS, nothing happens. I just get "Bad" or "BadTimeout", I still have some figuring out why the error code changes, but no matter what I do there is never any Wireshark communication to the device.

When trying a connection to the device using the endpoint with IP address, I get "BadCertificateHostNameInvalid", because there is no IPAddress in the SAN extension (even though the DNSName is present). So in this case having only a DNSName in the certficate does not work, when adding the IPAddress to certificate, it works.

I am using Windows 11, have OPC UA Local Discovery Server and OPCF Bonjour Service (tested also with Apple Bonjour Service) running. I also tried to add the hostname and IP directly to windows hosts file, so there is no need for a lookup at all but that doesn't work either with UaGDS (but other tools like UaExpert just skip DNS lookup and just use the IP directly).