You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Erwin Dondorp (Jira)" <ji...@apache.org> on 2021/04/20 00:44:00 UTC
[jira] [Updated] (ARTEMIS-3258) downstream federation with ssl does
not use the given truststore
[ https://issues.apache.org/jira/browse/ARTEMIS-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erwin Dondorp updated ARTEMIS-3258:
-----------------------------------
Description:
When using a downsteam federation, 2 connections are made:
* The first one uses the <static-connectors>/<connector-ref>. This one succeeds. The value is {{tcp://B:61617?sslEnabled=true;trustStorePath=filename-on-A;trustStorePassword=xyz}}.
* The second one must be made by the remote broker and uses the <upstream-connector-ref>. This one fails when using SSL. The url value is {{tcp://A:61617?sslEnabled=true;trustStorePath=filename-on-B;trustStorePassword=xyz}}. This one fails, as can be seen in the logs of B. it shows error "AMQ214016: Failed to create netty connection: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target".
we cannot use the default trust-stores, so we provide references to our own. these truststores and the other ssl configuration items properly work for cluster-connections, client-connections and upstream-federation-connections. we use self-signed certificates for development and test environments.
my theory is that the {{trustStorePath}} parameter is somehow ignored and the default truststore is then used (or none). this then causes validation of the certificate to fail as shown by the error message.
was:
When using a downsteam federation, 2 connections are made:
* The first one uses the <static-connectors>/<connector-ref>. This one succeeds. The value is {{tcp://B:61617/?sslEnabled=true;trustStorePath=filename-on-A;trustStorePassword=xyz}}.
* The second one must be made by the remote broker and uses the <upstream-connector-ref>. This one fails when using SSL. The url value is {{tcp://A:61617/?sslEnabled=true;trustStorePath=filename-on-B;trustStorePassword=xyz}}. This one fails, as can be seen in the logs of B. it shows error "AMQ214016: Failed to create netty connection: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target".
we cannot use the default trust-stores, so we provide references to our own. these truststores and the other ssl configuration items properly work for cluster-connections, client-connections and upstream-federation-connections. we use self-signed certificates for development and test environments.
my theory is that the {{trustStorePath}} parameter is somehow ignored and the default truststore is then used (or none). this then causes validation of the certificate to fail as shown by the error message.
> downstream federation with ssl does not use the given truststore
> ----------------------------------------------------------------
>
> Key: ARTEMIS-3258
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3258
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Federation
> Affects Versions: 2.17.0
> Reporter: Erwin Dondorp
> Priority: Critical
>
> When using a downsteam federation, 2 connections are made:
> * The first one uses the <static-connectors>/<connector-ref>. This one succeeds. The value is {{tcp://B:61617?sslEnabled=true;trustStorePath=filename-on-A;trustStorePassword=xyz}}.
> * The second one must be made by the remote broker and uses the <upstream-connector-ref>. This one fails when using SSL. The url value is {{tcp://A:61617?sslEnabled=true;trustStorePath=filename-on-B;trustStorePassword=xyz}}. This one fails, as can be seen in the logs of B. it shows error "AMQ214016: Failed to create netty connection: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target".
> we cannot use the default trust-stores, so we provide references to our own. these truststores and the other ssl configuration items properly work for cluster-connections, client-connections and upstream-federation-connections. we use self-signed certificates for development and test environments.
> my theory is that the {{trustStorePath}} parameter is somehow ignored and the default truststore is then used (or none). this then causes validation of the certificate to fail as shown by the error message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)