marcschier
commented
4 months ago Technically correct. However, due to a couple of mistakes we have some backcompat issues between 2.8, 2.9.0, 2.9.4 and 2.9.9. These are because the default application name and host name that is used to lookup the certificate to use in "own/certs" between version changes fail to find the certificate and then generate a new one. This was fixed in 2.9.9 which has the 2.8 behavior. There is now also a --cfa command line option to use the information from the first certificate found in the own/certs folder (that is valid) and then uses the application name, uri, hostname, subject name from that certificate. The idea is - you generate a certificate yourself, and the publisher is automatically configured - or - you use a previous version and the publisher uses the existing cert generated before even if the defaults change. So in essence - use 2.9.9 (latest) if you can. If you want to make it easy on yourself, use --cfa. Hope this makes sense.
As per the docs, if you don't supply a custom certificate, publisher will generate one on startup. This cert wil be used as client certificate when securely connecting to OPC UA server (and thus usually needs to be trusted on them).
I have now restarted publisher a couple of times and tested this against a kepserver, and I noticed its actually using the same certificate again (at least I dont need to re-trust the certificate) - even though I'm not persisting the certificate in a volume or sth. My understanding is that when the container is restarted, basically also a new certificate will be generated. Is it the case that the certificate is always generated exactly the same, and only the expiration date changes? That would mean I only have to trust a new certificate on the server-side when the day changes, and thus valid from and to dates change.