I wasn't implying we should... I was just working on something similar and want sure if you were aware of the option.
Chris Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> ________________________________ From: Łukasz Dywicki <l...@code-house.org> Sent: Wednesday, October 30, 2024 7:11:28 PM To: dev@plc4x.apache.org <dev@plc4x.apache.org> Subject: Re: Self signed certificates It makes a sense to simplify certificate work, but to be fair, anyone who wants to deploy UA stuff in production should be aware of certificate work. We already have option to setup client keystore with private key, since this week we also have tutorial showing how to do it using universal desktop tool, so it should simplify process. I am afraid of situations where we do too much implicitly. With little of help we do with ad-hoc certificate it was already a surprise. Yet we do same thing as UA Expert, a well recognized tool out there. I do not have a strong opinion on how to address this kind of issues in future. Preferably, I would leave that open, and see if we get more people surprised by how UA certificates work. Best, Łukasz On 30.10.2024 13:03, Christofer Dutz wrote: > So for my other usecase, I'm building things that if I start the software and > the cert file is missing, it generates one and stored it in that location. A > user can however put his own cert in that location, it gets picked up and no > cert is generated. Pegasus that helps? In the profinet drivers we also access > files in standard, but configurable locations. > > Chris > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Łukasz Dywicki <l...@code-house.org> > Sent: Wednesday, October 30, 2024 11:39:58 AM > To: dev@plc4x.apache.org <dev@plc4x.apache.org> > Subject: Re: Self signed certificates > > We do have this functionality. Thing is - the self signed cert is > generated each time when user does not provide it and connection is > made. [1] > Most of OPC UA servers will retain attempted client certificates in > "rejected" directory, but even if you move it to trusted, the next > connection made by plc4x will ship another certificate. So the only one > way is to store client certificate on our end and keep using it. > Doing it on behalf of user (storing cert somewhere) is doable, but opens > us in another set of troubles like expiry of the certificate. > > Best, > Łukasz > > [1] > https://github.com/apache/plc4x/blob/v0.12.0/plc4j/drivers/opcua/src/main/java/org/apache/plc4x/java/opcua/context/OpcuaDriverContext.java#L83 > > > On 30.10.2024 09:25, Christofer Dutz wrote: >> Hi all, >> >> I followed the trouble in the OPC-UA driver with the certificates … in a >> different part of my work I’m dealing with a similar problem. >> As I know that creating a self-signed certificate, even with your >> documentation, will still probably scare 80% of OT-folks out there, possibly >> what I have been working on would also be interesting for us here? >> In my experiment I’m using the bouncy-castle libs to auto generate >> self-signed certificates in pure java. >> So how about adding such a feature to the opc-ua driver? >> A feature that auto-generates a certificate that fits for communicating with >> the remote PLC, if none is provided. >> >> Chris >> > >
