You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Robbie Gemmell (Jira)" <ji...@apache.org> on 2021/07/23 09:59:00 UTC

[jira] [Commented] (ARTEMIS-3185) Various TLS tests fail on newer JDKs/environments

    [ https://issues.apache.org/jira/browse/ARTEMIS-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386125#comment-17386125 ] 

Robbie Gemmell commented on ARTEMIS-3185:
-----------------------------------------

Its fairly typical for such things to live beside the test using them or in the src/test/resources of the module the tests exist, the latter in particular if they are general files that most tests would only need to use an identical set for. I would guess the folks that used these 'mqtt crl' files for other tests in the integration tests module did so because of the latter and especially given the files particularly generic naming. I didnt add most of the uses of them but certainly could have some of them, as its really the obvious usage to go for. Most of these tests just need a very simple server keystore and a trust store with the CA cert that signed it (actually I've come to realise none of the other stores use a CA cert, besides those 'mqtt crl' ones, I would also change that to make the tests better/more-representative and also simplify the number of stores needed).

I dont think that it really makes more sense for the instructions of basic keystores+truststore to be embedded across different tests deep within the source tree, and need to be copied out of their javadoc and edited in order to run, and then for the resulting stores files to be created all alongside each other but in an entirely different maven module from those instructions (files under tests/unit-tests, instructions inside tests within tests/integration-tests).

Its so much simpler to update the keystore/truststore resources if they sit next to instructions that can simply be executed as a script to regenerate them. Theres no confusion about which commands were run or from where and updating the files takes a instant to run/source the existing script (modifying the script first if needed), less time than even finding and copying ones embedded in different tests elsewhere. Looking for all changes to the files and the commands that created them? Simple check of the diff of that sole location.

> Various TLS tests fail on newer JDKs/environments
> -------------------------------------------------
>
>                 Key: ARTEMIS-3185
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-3185
>             Project: ActiveMQ Artemis
>          Issue Type: Test
>          Components: Tests
>    Affects Versions: 2.17.0
>            Reporter: Robbie Gemmell
>            Priority: Major
>
> Various broker integration tests fail after I updated to Fedora 33, seemingly on all JDK versions but certainly with 8u275 and above, with the failing tests all being TLS related. For example, AMQPConnectSaslTest, JMSSaslExternalTest, JMSSaslExternalLDAPTest failed, though there are others.
> Specifically, the related keystore for those tests looks to be keystore1.jks under tests/integration-tests/src/test/resources (though possibly other files in there and related tests could be affected or need updated also). The key contained uses SHA1withRSA for the signature, which keytool notes is disabled and so that is presumably the problem:
> {noformat}
> $ keytool -keystore keystore1.jks -storepass changeit -list -v
> ...snipped...
> Signature algorithm name: SHA1withRSA (disabled)
> ...snipped...
> <keystore1> uses the SHA1withRSA signature algorithm which is considered a security risk and is disabled.
> {noformat}
> I'm not clear how the file was generated and dont see the CA key used to sign it and which matches up to the truststore.jks file (it uses SHA256withRSA sig and so should be fine if the key were updated in isolation). If someone who knows the process used could update the key that would be great.
> A suggestion I would make is to create a script that creates the files, both so it can be seen later what was done, and more easily repeated and/or updated when needed. E.g for example we do this with the [Qpid JMS tests resources|https://github.com/apache/qpid-jms/blob/0.57.0/qpid-jms-client/src/test/resources/README.txt], which I adapted for creating the ['broker-connections' TLS example|https://github.com/apache/activemq-artemis/blob/master/examples/features/broker-connection/amqp-sending-overssl/store-generation.txt] resources when I was updating that.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)