And another reply to self:
I just tried OpenSSL 3.0.0 for TC 8.5. When running with Java 1.7.0_80
and OpenSSL based connector, I get failures for:
[junit] Test org.apache.catalina.valves.rewrite.TestResolverSSL FAILED
[junit] Test org.apache.tomcat.util.net.TestClientCert FAILED
[junit] Test org.apache.tomcat.util.net.TestCustomSslTrustManager
FAILED
They all look more or less like:
Received fatal alert: internal_error
javax.net.ssl.SSLException: Received fatal alert: internal_error
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at
sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1979)
at
sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1086)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
So the java based client gets an alert when connection to a OpenSSL
3.0.0 based server. Probably not unexpected for old patch levels of Java
7. I might look for the alert later, but the script is now testing other
Java version, OpenSSL 3 and TC 8.5. Java 8 seems fine so far.
Best regards,
Rainer
Am 26.02.2022 um 05:39 schrieb Rainer Jung:
Forgot to mention: I do also test with Adoptium, Zulu and RedHat based
JDK builds. Latest patch levels, results have been stable for all
combination for a long time now, not only current latest patch levels.
Controlling which test classes are executed is possible via test.name
and test.exclude in the build.properties. Default value ist:
test.name=**/Test*.java
and test.exclude is empty. The possible syntax for the values comes from
the use in build.xml:
<fileset dir="test" includes="${test.name}" excludes="${test.exclude}">
Multiple values can be separated by commas. Examples (analogous for
test.exclude, not tested):
test.name=org/apache/coyote/http2/TestCancelledUpload.java,org/apache/coyote/http2/TestFlowControl.java
test.name=**/TestWebSocketFrameClientSSL.java,**/TestWsWebSocketContainer.java,**/util/net/
test.name=org/apache/tomcat/util/net/openssl/**
Some clases which are not actually unit test classes but match the
default test.name are always excluded:
<exclude name="**/Tester*.java" />
And (see build.xml):
<exclude name="org/apache/catalina/tribes/test/**" />
<exclude
name="org/apache/tomcat/util/net/openssl/ciphers/**"
unless="${test.openssl.exists}" />
<exclude name="**/*Performance.java"
if="${test.excludePerformance}" />
The ant junit batchtest element used in our build.xml IMHO only allows
test selection (include and exclude) by test class, not individual
methods. The "test" element would allow inclusion by method name but
would only run tests from a single class.
Best regards,
Rainer
Am 26.02.2022 um 05:22 schrieb Rainer Jung:
Hi Chris,
I don't get any unit test failures. I set in build.properties:
test.apr.loc=/path/to/tcnative/lib
test.openssl.path=/path/to/openssl/bin/openssl
Plus when testing with JSSE:
test.sslImplementation=org.apache.tomcat.util.net.jsse.JSSEImplementation
resp. OpenSSL:
test.sslImplementation=org.apache.tomcat.util.net.openssl.OpenSSLImplementation
I do test with all Java LTS releases plus 18 plus for TC 8.5.0 Java
1.7.0. All in combination with self-compiled OpenSSL 1.1.1 plus
tcnative and I did not get any such failures for quite some time
(probably more than a year). Have not tried OpenSSL 3.0.0 during the
last months though.
Wild guess: maybe test.openssl.path is missing in your setup and the
unit tests use the platform OpenSSL commandline binary in these tests,
but on the server (Tomcat) side a newer one which you used to compile
tcnative? Or platform OpenSSL misses some default OpenSSL ciphers? As
said: using test.openssl.path makes sure, both sides use the same
OpenSSL.
For the sake of completeness (not related to OpenSSL):
- testing with pre Java 11 needs the following lines in your own
build.properties file:
opens.javalang=-Dnop
opens.javaio=-Dnop
opens.sunrmi=-Dnop
opens.javautil=-Dnop
opens.javautilconcurrent=-Dnop
You can add them before building or also just before running the test.
They only apply to the unit test runs. The "nop" was chosen as any
system property name that is likely not actually being used. It should
remind one of a "no-operation".
- testing with Java 1.7.0 for TC 8.5 in addition needs older easymock
and objenesis versions. You would have to set
easymock.version=3.6
objenesis.version=2.6
plus appropriate checksum lines for the download check:
easymock.checksum.value=1e6943105a21a336a874140e82b1a406|276883daaf2230e6f1e07c78ad695d2a18c7170b
objenesis.checksum.value=5ffac3f51405ca9b2915970a224b3e8f|639033469776fd37c08358c6b92a4761feb2af4b
Best regards,
Rainer
Am 24.02.2022 um 21:23 schrieb Christopher Schultz:
All,
My cipher-suite tests usually fail due to missing support for either
certain OpenSSL ciphersuites or JSSE, depending upon the JVM used to
tun run the tests.
I checked the testing code, but I don't see any documented way to
customize what gets tested.
I seem to remember @isapir giving instructions for how to ignore
certain cipher suites in specific environments so that all the tests
would pass.
Is that officially documented anywhere?
Thanks,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
