[
https://issues.apache.org/jira/browse/NIFI-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jul Tomten updated NIFI-8713:
-----------------------------
Description:
ConsumeJMS and PublichJMS SSL/TLS - error message PKIX path building failed
In the current design the keystore password is stored in plain text. It should
be stored in sensitive property. se commenta now!
!image-2021-06-16-21-40-53-349.png!
getJMSQueue putJMSQueue works fine with the same jks file and SSL context
service.
invokeHTTP works fine with the same context service.
I have a root ca that issues the server certificates without intermediate ca.
In the trust store jks there is only one certificate so it's a very simple
setup.
Is there any extra requirements on the jks trsutstore when using ConsumeJMS or
PublishJMS compared to getJMSQueue putJMSQueue ?
The trust store type in the SSL context service seems to not matter if it is
set to JKS or PKCS12 .
ConsumeJMS or PublishJMS fails both with JKS and PKCS12
getJMSQueue putJMSQueue works with JKS and PKCS12.
java keytool lists my trust store as keystore type PKCS12 provider SUN.
I have tested with a keystore of type JKS but it fails with the same error
message.
activemq-all-5.15.9.jar is used with ConsumeJMS or PublishJMS
getJMSQueue putJMSQueue uses ActiveMQ driver shipped with NiFi
The activemq-all-5.15.9.jar has been tested in sap po whrere it works fine.
Tested using the JMS* properties on the processor instead of the connection
factory service JMS context servive but still the same error message.
I guess the ConsumeJMS or PublishJMS doesn't use the specified ssl context
service but maybe fall back to using jdk cacerts file?
Tested putting the root ca cert in cacerts file and in the file pointed to by
nifi.security.truststore but it is still the same error message.
was:
ConsumeJMS and PublichJMS doesn't work over SSL/TLS - error message PKIX path
building failed
!image-2021-06-16-21-40-53-349.png!
getJMSQueue putJMSQueue works fine with the same jks file and SSL context
service.
invokeHTTP works fine with the same context service.
I have a root ca that issues the server certificates without intermediate ca.
In the trust store jks there is only one certificate so it's a very simple
setup.
Is there any extra requirements on the jks trsutstore when using ConsumeJMS or
PublishJMS compared to getJMSQueue putJMSQueue ?
The trust store type in the SSL context service seems to not matter if it is
set to JKS or PKCS12 .
ConsumeJMS or PublishJMS fails both with JKS and PKCS12
getJMSQueue putJMSQueue works with JKS and PKCS12.
java keytool lists my trust store as keystore type PKCS12 provider SUN.
I have tested with a keystore of type JKS but it fails with the same error
message.
activemq-all-5.15.9.jar is used with ConsumeJMS or PublishJMS
getJMSQueue putJMSQueue uses ActiveMQ driver shipped with NiFi
The activemq-all-5.15.9.jar has been tested in sap po whrere it works fine.
Tested using the JMS* properties on the processor instead of the connection
factory service JMS context servive but still the same error message.
I guess the ConsumeJMS or PublishJMS doesn't use the specified ssl context
service but maybe fall back to using jdk cacerts file?
Tested putting the root ca cert in cacerts file and in the file pointed to by
nifi.security.truststore but it is still the same error message.
> ConsumeJMS and PublishJMS SSL/TLS PKIX path building failed
> ------------------------------------------------------------
>
> Key: NIFI-8713
> URL: https://issues.apache.org/jira/browse/NIFI-8713
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Affects Versions: 1.13.2
> Environment: redhat
> java sap machine 1.11
> activemq-all-5.15.9.jar
> Reporter: Jul Tomten
> Priority: Major
> Labels: ConsumeJMS, PKIX, SSL, TLS, building, failed, path
> Attachments: image-2021-06-16-21-40-53-349.png,
> image-2021-06-17-12-07-32-920.png
>
>
> ConsumeJMS and PublichJMS SSL/TLS - error message PKIX path building failed
>
> In the current design the keystore password is stored in plain text. It
> should be stored in sensitive property. se commenta now!
>
>
> !image-2021-06-16-21-40-53-349.png!
>
> getJMSQueue putJMSQueue works fine with the same jks file and SSL context
> service.
> invokeHTTP works fine with the same context service.
> I have a root ca that issues the server certificates without intermediate ca.
> In the trust store jks there is only one certificate so it's a very simple
> setup.
> Is there any extra requirements on the jks trsutstore when using ConsumeJMS
> or PublishJMS compared to getJMSQueue putJMSQueue ?
>
> The trust store type in the SSL context service seems to not matter if it is
> set to JKS or PKCS12 .
> ConsumeJMS or PublishJMS fails both with JKS and PKCS12
> getJMSQueue putJMSQueue works with JKS and PKCS12.
>
> java keytool lists my trust store as keystore type PKCS12 provider SUN.
> I have tested with a keystore of type JKS but it fails with the same error
> message.
>
> activemq-all-5.15.9.jar is used with ConsumeJMS or PublishJMS
> getJMSQueue putJMSQueue uses ActiveMQ driver shipped with NiFi
>
> The activemq-all-5.15.9.jar has been tested in sap po whrere it works fine.
>
> Tested using the JMS* properties on the processor instead of the connection
> factory service JMS context servive but still the same error message.
> I guess the ConsumeJMS or PublishJMS doesn't use the specified ssl context
> service but maybe fall back to using jdk cacerts file?
> Tested putting the root ca cert in cacerts file and in the file pointed to
> by nifi.security.truststore but it is still the same error message.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
