[
https://issues.apache.org/jira/browse/CAMEL-26113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132821#comment-18132821
]
Serdar Gökay commented on CAMEL-26113:
--------------------------------------
Looked at how Milo handles this before proposing a mechanism in camel-milo.
*Milo 1.1.8 (current)*: the client never re-runs discovery on reconnect.
{{SessionFsmFactory}} and {{OpcTcpClientTransport}} reuse the
{{EndpointDescription}} of the client config. With a security policy other than
{{None}}, {{createSession}} fails with {{Bad_SecurityChecksFailed}} when the
server certificate differs from the one of the pinned endpoint, and the client
retries that forever. With policy {{None}} nothing is compared, so those
connections are not affected.
*Milo 1.2.0 brings the mechanism*:
[eclipse-milo/milo#1949|https://github.com/eclipse-milo/milo/pull/1949]
"Recover clients after server certificate rotation", included in 1.2.0-RC1. An
{{EndpointResolver}} re-runs discovery and endpoint selection after a secure
channel handshake failure on a secured endpoint, one resolution at a time
within a cooldown. The replacement certificate must still pass the configured
validator. The endpoint URL, server URI, transport profile, security policy,
security mode and user token policies are pinned: only the server certificate
may differ. {{OpcUaClient.create(OpcUaClientConfig)}}, which camel-milo uses,
installs no resolver; it has to be set with
{{OpcUaClientConfigBuilder.setEndpointResolver(...)}}.
*Proposed scope*:
- No discovery or rebuild loop of its own in camel-milo; it would duplicate
Milo.
- With the upgrade to Milo 1.2.0 (a ticket of its own: 1.2.0 has API breaks
that touch camel-milo, {{setCertificateIdentity}} replaces
{{setKeyPair}}/{{setCertificate}}/{{setCertificateChain}}, Browse throws on a
Bad result, {{disconnectAsync}} waits up to 5 s for the session to close),
camel-milo sets an {{EndpointResolver}} that reuses its own endpoint selection
({{allowedSecurityPolicies}}, {{overrideHost}}/{{overridePort}}). That closes
the certificate case of this ticket.
- A changed endpoint stays a configuration change, recovered by a route or
context restart, as the component page and the 4.24 upgrade guide already say.
Milo pins the endpoint by design, and I would not go further than Milo here.
I can take this together with the Milo 1.2.0 upgrade once the final release is
out.
> camel-milo - the client does not rebuild its connection after the server
> changes its endpoint or certificate while it is unreachable
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26113
> URL: https://issues.apache.org/jira/browse/CAMEL-26113
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
> Affects Versions: 4.24.0
> Reporter: Serdar Gökay
> Priority: Minor
>
> Follow-up of CAMEL-25912, documented there in the component page and in the
> 4.24 upgrade guide.
> The client recovers a lost session itself, with the endpoint and the server
> certificate it found when it connected. A server that renews its certificate
> or changes its endpoints while it cannot be reached is therefore not reached
> again by that recovery; the client reaches it only when Camel rebuilds the
> connection, for example when the Camel context restarts. Consumer-only
> connections behave this way since CAMEL-25691 and CAMEL-25692 (4.24.0). Since
> CAMEL-25912 a failed producer request no longer rebuilds the connection
> either, so this now applies to every connection.
> A possible mechanism: when the reconnect of the client keeps failing, or
> fails with a certificate or endpoint error, run endpoint discovery again and
> rebuild the connection through the existing reconnect path of the manager. To
> decide: when the rebuild happens, and how it is reported.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
