oscerd commented on code in PR #27824: URL: https://github.com/apache/camel/pull/27824#discussion_r4282243036
########## components/camel-milo/src/main/docs/milo-client-component.adoc: ########## @@ -204,10 +204,59 @@ The known security policy URIs and enum literals are can be seen here: https://g NOTE: In any case security policies are considered case sensitive. +When `allowedSecurityPolicies` is not set, the client accepts every security policy the server offers and uses the +endpoint with the highest security level reported by the server, which can be `None`. To make sure the connection is +secured, set `allowedSecurityPolicies` to the secured policies you expect the server to offer. + +=== Validating the server certificate + +When the selected endpoint uses a security policy other than `None`, the client validates the certificate of the +server when it opens the secure channel and the session. Configure the trusted certificates with one of these options: + +* `trustListDirectory`: a directory holding the trust list, in the layout used by Eclipse Milo. Put the certificate of +the server, or the certificate of the CA that issued it, in `trusted/certs`. Certificates of intermediate CAs that are +only used to build the chain go in `issuer/certs`, and certificate revocation lists in `trusted/crl` and `issuer/crl`. +The directories are created if they do not exist. +* `certificateValidator`: a custom `org.eclipse.milo.opcua.stack.core.security.CertificateValidator`. It is used +instead of `trustListDirectory` when both are set. Endpoints share a connection only when they use the same validator +instance. + +With `trustListDirectory`, the client refuses a server certificate that: + +* does not chain up to a certificate in `trusted/certs`, possibly through the certificates in `issuer/certs`, +* is outside its validity period, +* is revoked by a certificate revocation list in `trusted/crl` or `issuer/crl`. When the trust list has no revocation +list for an issuer, the revocation status of the certificates it issued is not checked, Review Comment: Good catch, thanks. That sentence was written before the tests showed that Milo 1.1.8 does not soft-fail. Applied your suggestion in 999fd741c56f. The `setTrustListDirectory` javadoc now states the same requirement (a CA-issued certificate needs a CRL of its CA; an empty one is enough). The catalog doc copy, the JSON and the DSL factories are regenerated, with a full reactor build on the branch rebased onto current main. _Claude Code on behalf of Andrea Cosentino_ ########## docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_24.adoc: ########## @@ -190,6 +190,29 @@ now read as a local date-time without a zone (`getDate()` returns a `LocalDateTi definition of an earlier message, if there was one. A calendar that defines a `TZID` an earlier message has defined differently is now read with its own definition. +=== camel-milo - the OPC UA client validates the server certificate + +When the endpoint it selects uses a security policy other than `None`, the `milo-client` and `milo-browse` components +now validate the certificate of the OPC UA server. Before, any server certificate was accepted, and no option allowed +to validate it. + +Configure the trusted certificates with the new `trustListDirectory` option: put the certificate of the server, or of +the CA that issued it, in the `trusted/certs` directory of the trust list. A server certificate that does not chain up +to a trusted certificate is written to `rejected/certs`, from where it can be moved to `trusted/certs` once it has been +checked. The trust list also refuses a server certificate outside its validity period, revoked by a revocation list of +the trust list, or whose application URI differs from the one of the server. A custom validator can be configured with +the new `certificateValidator` option instead. Review Comment: Applied in 999fd741c56f: the guide entry now says that a CA-issued server certificate is refused with `Bad_CertificateRevocationUnknown` without a revocation list of its CA, how to add one (an empty CRL is enough, in `trusted/crl` or `issuer/crl`), and that a custom `certificateValidator` is the alternative. _Claude Code on behalf of Andrea Cosentino_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
