On Tue, December 22, 2020 12:46, Viktor Dukhovni wrote:
> On Tue, Dec 22, 2020 at 09:24:27AM -0500, James B. Byrne wrote:
>
>> > It clearly supports STARTTLS, since it is actually performing the TLS
>> > handshake, and abandons it after receiving certificates it is not happy
>> > with.
>>
>> Which confuses me, because I can use java to successfully negotiate a
>> certificate exchange with Postfix using the same keystore that the
>> application
>> is using.
>
> Perhaps you're confusing the Java keystore with the Java trust store,
> they are separate entities. Java is a programming language, not a
> single application. Each Java program gets to do its own thing.
> Yes, they often share some common libraries and file formats, ...
In this case, from what I can see in the application configuration files, the
keystore and the truststore are the same file:
<!-- ============================================================= -->
<!-- SSL ContextFactory configuration -->
<!-- ============================================================= -->
. . .
<Set name="KeyStorePath"><Property name="jetty.base" default="." />/<Property
name="jetty.sslContext.keyStorePath" deprecated="jetty.keystore"
default="etc/keystore"/></Set>
. . .
<Set name="TrustStorePath"><Property name="jetty.base" default="."
/>/<Property name="jetty.sslContext.trustStorePath"
deprecated="jetty.truststore" default="etc/keystore"/></Set>
. . .
>
> Well, you're running tests with completely different Java client
> applications and likely in fact different configuration settings. All
> that's in common is that both are Java, which is something, but not
> much...
Granted, but short of writing my own mail agent in Java, a language that I have
next to no experience with, I have to use the tools that I can find and which
are simple enough for me to use. SSLPoke is just using the Java SSL libraaries
to exercise connectivity, and for a very long time that was the issue. I am
now past that stage.
>
> Note that certificates don't pass "keystore" validation, they pass
> "trust store" validation. Java keystores are for your own private
> key and cert (akin to PKCS12 containers, or a PEM with key + cert
> chain), while trust stores are akin to a cert bundle with lots of
> CA certs.
As shown above, in this case the application configured to use the same file as
both keystore and truststore. In fact, in the SSLPoke tests I was only passing
the truststore arguments. But if I do use both key and truststore arguments
then I get the same result:
JAVA_VERSION="12" java \
-Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore
\
-Djavax.net.ssl.keyStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore
\
-Djavax.net.ssl.trustStorePassword=testing \
-Djavax.net.ssl.keyStorePassword=testing \
SSLPoke 192.168.216.32 465
Successfully connected
>
>> I know that the service is different on both ports, but the
>> certificate acceptability should be the same. And it is the client
>> that is causing the problem.
>
> You could hypothetically have different certificate settings for
> the different ports in master.cf, but if you don't then indeed
> the server side TLS behaviour is likely the same across the board.
>
I do not. And, I believe we are past the phase where the truststore
verification is the issue. I may be wrong but the evidence from SSLPoke and
KeyStore Explorer tells against verification failing.
I am suspicious of the SSLv3 / TLSv1.3 contratemps shown in the Postfix log
files. But I have no idea how that would make a certificate unacceptable to
the client. Unless it could not read it?
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
Unencrypted messages have no legal claim to privacy
Do NOT open attachments nor follow links sent by e-Mail
James B. Byrne mailto:byrn...@harte-lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
