Is there any way to accept a .pem file which contains both using the SDK?

This constructor expects the certificate and private key as separate files. The .der file is used as the certificate file, and the .pem file should contain only the private key. Therefore, removing the BEGIN CERTIFICATE / END CERTIFICATE block from the PEM file is the correct workaround.

OPC UA itself does not mandate this local PEM file layout. Tools such as UaExpert may accept a PEM file containing both certificate and private key, but this SDK constructor expects the private key file separately.

I checked the code and it seems like the current implementation never bundles values from different WriterGroups into the same NetworkMessage while the documentation states otherwise. I cannot however currently tell why this is, it's possible that this is a bug that hasn't been tested. Regardless, either the docs or the implementation needs to be adjusted.

Thanks for the report, I'll create an issue on this.

basically the creation of a UserIdentity using a .der and .pem file works.

But now I have a specific case, where the .der and .pem file is provided by the EQ vendor to be able to connect to the OpcUA server and it seems that the .pem file can not be loaded correctly.

The code to create the user identy (with SDK version 4.10.2-62) is following:

UserIdentity userIdentity = new UserIdentity(new File("UserCert.der"), new File("UserCert.pem"), "pwd");

The exception is:

org.bouncycastle.util.encoders.DecoderException: unable to decode base64 string: invalid characters encountered in base64 data
at org.bouncycastle.util.encoders.Base64.decode(Unknown Source)
at com.prosysopc.ua.stack.transport.security.BcCryptoProvider.base64Decode(SourceFile:78)
at com.prosysopc.ua.stack.utils.CryptoUtil.base64Decode(SourceFile:122)
at com.prosysopc.ua.stack.transport.security.PrivKey.load(SourceFile:117)
at com.prosysopc.ua.stack.transport.security.PrivKey.load(SourceFile:191)
at com.prosysopc.ua.SecureIdentity.a(SourceFile:473)
at com.prosysopc.ua.SecureIdentity.(SourceFile:235)
at com.prosysopc.ua.UserIdentity.(SourceFile:123)

The .der file looks like this (I've removed th middle part for better readability)

UserCert.der

0‚Ê0‚² ®É¢r®Vá,^0å}C¸n:Oê0
*†H†÷
....
5²fØad˾ò»‡º ×–_

The .pem file contains a 'BEGIN/END CERTIFICATE' section and a 'BEGIN/END PRIVATE KEY' section like shown here:

-----BEGIN CERTIFICATE-----
MIIGyjCCBLKgAwIBAgIUD67JonKuVuEsHV4w5X1DuG46T+owDQYJKoZIhvcNAQEL
....
ZMu+8rsDh7oaANeWAV8=
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
MIIJQQIBADANBgkqhkiG9w0BAQEFAASCCSswggknAgEAAoICAQCcDX0o7ADB8gJb
....
bstj/beIj9MfXzAsgd84KMZCKK3m
-----END PRIVATE KEY-----

When I remove the 'BEGIN/END CERTIFICATE' section, the UserIdenty can be created.

So it seems that the .pem file shall contain only the 'BEGIN/END PRIVATE KEY' section, but not the CERTIFICATE, right?

Is there any specification that it should be like this?

Or is there any way to load the UserIdentity with a .der and .pem file which contains CERTIFICATE and PRIVATE KEY'

P.S. The UaExpert can load the UserIdentity using the .der and .pem (including CERTIFICATE and PRIVATE KEY) without problems.

Thank you for you help!

I have configured 2 DataSetWriters in a single WriterGroup (using the same publishingInterval). The UadpNetworkMessageContentMask does NOT contain the DataSetClassId (i.e. it is null). The DataSets only comprise 2 and 3 double values, respectively, which should fit well into the maxMessageSize of 4096 bytes.

What could be the reason for sending multiple networkmessages with one dataSet each instead of one networkMessage containing the dataSets from both dataSetWriters?

Some shortened log messages below. My expectation would be that a single networkmessage would transport both dataSets (dataSetWriterIds=[1,2]). Could this be related to the issue of the dataSet seqNos counting across all dataSetMessages? (see previous forum entry)

Use of opc.https is not recommended in products developed with our SDK. We recommend using opc.tcp endpoints instead. Support for opc.https is deprecated, so new integrations should not rely on it.

You seem to be correct. Looking at the code, the DataSetReader implementation currently holds only one lastDataSetSequenceNumber, which is used when producing that warning log. Consequently, if multiple DataSetWriters are received by the same DataSetReader, the implementation does not distinguish the source of the sequence number.

Based on this, the sequence number validation should likely be tracked at least per DataSetWriter, even when the DataSetReader is the same.

I’ll create an issue for this. Thanks for the report.

I have a UDP publisher publishing 2 DataSets in 2 different DataSetWriterGroups at different publishingIntervals (1000ms and 2000ms).

The subscriber uses a single DataSetReader/group without preconfigured writer/publisher/.. ids to receive all possible messages on that multicast socket.

When logging the subscriber side, the SDK warns about old sequenceNumbers, comparing the sequenceNumbers from both received DataSetWriters. It is my understanding from the Standard Part 14, 7.2.4.5.4 DataSetMessage header, that the SequenceNumber is related to the DataSet and not to a publisher. Is the SDK sequence number evaluation possibly incorrect here?

One PubSubSystem with multiple connections appears to support adding connections on the fly without stopping existing ones. Multiple PubSubSystems are not required just to avoid interruption when adding another multicast subscriber, based on the implementation. Additionally the docs show that the configuration updates are applied live meaning start/stop shouldnt be required when adding connections:

https://documentation.prosysop.....bFunction-

Of course, multiple PubSubSystems could provide better Application-level isolation (e.g. if you want separate life cycles/listeners for each connection) but based on your question, a single one should be suitable.

thanks for your reply.
We need to add connections (subscribers on additional multicast addresses) on the fly, while the subscriber/s on the first connection is/are already active. It is my understanding that the PubSubSystem configuration is, once created, mostly immutable. Adding a second connection would probably mean to stop the first PubSubSystem, update the configuration (or even create a new one if an update is not possible) and then start the new configuration with the added connection. Having multiple PubSubSystems would avoid that interruption.

My educated guess is that a singular PubSubSystem is the cleaner option since that supports your stated requirement of handling multiple connections. Do you have more requirements left unstated in the message? If you have something specific to point out, I could try to take a look and see if I can something more specific related to that.

P.S.
If you wish to wait, you'll likely get a more nuanced and direct answer once relevant people return from vacation 🙂

Are there any benefits of one over the other option apart from the possibility to start/stop each individually or together?

The updated SDK is now able to transmit the desired meta-data. As a quick trial I sent the EngineeringUnits as an EUInformation structure and it is easily retrievable from the metadata.

Thank you very much for providing the SDK update so quickly.

Have an enjoyable holiday time.
-HU

Now in the Publisher in com.prosysopc.ua.samples.pubsub.SamplePubSubConfiguration.addPublishedVariableDataSet(Builder, UaNodeId) you can add e.g.
variableConfBuilder.putMetaDataPropertyMap(UaQualifiedName.standard("Test"), "TestValue");
Tested via in Subscriber side in com.prosysopc.ua.pubsub.PubSubSystem.addEventListener if you print the event/metadata.

Note that the SDK doesn't support 'metadata versioning' and it is only created when the PubSubSystem starts. Thus only constant values work. Depending how things go, maybe at some point there could be some "selector" configuration similar to how EventFilter works in opc.tcp events that would select sub-node values from a node being published (and maybe even monitor those ..), but that is possible future exploration.

Also, use namespaces for the UaQualifiedName(s) that are known for both sides. We sort of did a bit of a mistake in the design that both sides are assumed to know the types, but for a generic Subscriber it would instead need a separate "type realm" for each PublisherId+WriterId combination. The DataSetMetaData inherits from DataTypeSchemaHeader (from which also UABinaryFileDataType inherits) that is intended to list types used by the Publisher (though, in a case where the data would get pushed to a node on the server, then it must also follow that the server must know the type, or there wouldn't be much sense as far as I can think of use-cases).