Connection to Ignition via OPC UA

Ignition
1

Hi - I am trying to establish a connection between SAP DMC and Ignition via OPC UA and failing upon uploading a certificate under “Security” section of the gateway. The upload is always successful but unfortunately, the certificate never gets added to the list of “Trusted or Quarantined Certificates”. Is there someone within the Ignition community who has any experience with such a concern or has ever developed a connection to Ignition over OPC UA?

2

A support engineer responded on the ticket you opened requesting the necessary information to continue troubleshooting.

3

The Common Name of the certificate you provided is encoded in a strange format that Java doesn’t seem to decode properly… (looking at the ASN.1 shows it as a ‘BMP String’) according to an older RFC, rather than a newer one that specifies UTF-8, and Java is expecting UTF-8.

Instead of “ABB_US_SF_Ignition_OPCUA_OpcUa_Client” it ends up being read as “\00A\00B\00B\00_\00U\00S\00_\00S\00F\00_\00I\00g\00n\00i\00t\00i\00o\00n\00_\00O\00P\00C\00U\00A\00_\00O\00p\00c\00U\00a\00_\00C\00l\00i\00e\00n\00t”, which ends up getting used in the filename and it fails because it doesn’t make for a valid filename, even after sanitization.

As a workaround you can put the certificate on the filesystem directly in the $IGNITION/data/opcua/client/security/pki/trusted/certs folder.

4

This helps! Certificate is now successfully added to the “Trusted Certificates”. I will revert back once the connection between the two systems is established.

5

I'm not sure if you have any way to funnel feedback to the right person, but after some RFC spelunking and talking to another UA WG member we've pretty much confirmed that this certificate from the ABB server is technically not compliant, because all certificates issued after Dec 31 2003 MUST encode distinguished names as ASN.1 UTF8String [0]

The DirectoryString type is defined as a choice of PrintableString,
TeletexString, BMPString, UTF8String, and UniversalString. The
UTF8String encoding [RFC 2279] is the preferred encoding, and all
certificates issued after December 31, 2003 MUST use the UTF8String
encoding of DirectoryString (except as noted below). Until that
date, conforming CAs MUST choose from the following options when
creating a distinguished name, including their own:

  (a)  if the character set is sufficient, the string MAY be
  represented as a PrintableString;

  (b)  failing (a), if the BMPString character set is sufficient the
  string MAY be represented as a BMPString; and

  (c)  failing (a) and (b), the string MUST be represented as a
  UTF8String.  If (a) or (b) is satisfied, the CA MAY still choose
  to represent the string as a UTF8String.

Exceptions to the December 31, 2003 UTF8 encoding requirements are as
follows:

  (a)  CAs MAY issue "name rollover" certificates to support an
  orderly migration to UTF8String encoding.  Such certificates would
  include the CA's UTF8String encoded name as issuer and and the old
  name encoding as subject, or vice-versa.

  (b)  As stated in section 4.1.2.6, the subject field MUST be
  populated with a non-empty distinguished name matching the
  contents of the issuer field in all certificates issued by the
  subject CA regardless of encoding.

So basically... this server is generating certificates in a technically incorrect manner, and maybe you can bubble this up to someone that can fix it.

[0] RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

3 Likes