info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
AssemblyLineFC - SSL Handshake errors
80 views
Skip to first unread message
Karl Prinelle
Jun 22, 2021, 2:00:13 PM6/22/21
to
Hi,
Just wondering if anyone knows which certs are being used by the AssemblyLineFC? I'm connecting from one instance of TDI to another. Each instance has it's own admin and server certs (not the shipped ones). We have good reasons to do this.
I've assumed it's using the admin cert to connect across so have exchanged the admin cert between the two instances (imported into the admin keystore), but still I get an SSL handshake error on the caller. Both admin certs have the same keychains which exist in the respective stores.
CTGDIS266E Error in InitConnectors. Exception occurred: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
javax.net.ssl.SSLHandshakeException: java.net.SocketException: Broken pipe (Write failed)
If I use tdisrvctl to try to manually start the AL on the target and use the admin keystore (-T and - K) from the caller then on the target instance I do get this message;
[com.ibm.di.api] - CTGDKD311I Remote session created for user: xxxxxxx
which indicates something has connected. When I'm doing this I'm not seeing an SSL error, but it's also not launching the AL. That makes me curious about which certs the AssemblyLineFC is selecting for the connection.
I've also added the calling user (registry.txt) to the registry.txt of the target instance as admin & regenerated registry.enc.
If the keystores are identical then there is no issue starting workload in a remote instance - we have 3 other internal instances working nicely. The issue is only when I'm trying to start workload in an instance that has a different admin cert it seems.
I'm wondering if somewhere it's using the server cert from an instance perhaps. I'm not sure that really stacks up though.
Just wondering if anyone knows which certs are being used by the AssemblyLineFC? I'm connecting from one instance of TDI to another. Each instance has it's own admin and server certs (not the shipped ones). We have good reasons to do this.
I've assumed it's using the admin cert to connect across so have exchanged the admin cert between the two instances (imported into the admin keystore), but still I get an SSL handshake error on the caller. Both admin certs have the same keychains which exist in the respective stores.
CTGDIS266E Error in InitConnectors. Exception occurred: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
javax.net.ssl.SSLHandshakeException: java.net.SocketException: Broken pipe (Write failed)
If I use tdisrvctl to try to manually start the AL on the target and use the admin keystore (-T and - K) from the caller then on the target instance I do get this message;
[com.ibm.di.api] - CTGDKD311I Remote session created for user: xxxxxxx
which indicates something has connected. When I'm doing this I'm not seeing an SSL error, but it's also not launching the AL. That makes me curious about which certs the AssemblyLineFC is selecting for the connection.
I've also added the calling user (registry.txt) to the registry.txt of the target instance as admin & regenerated registry.enc.
If the keystores are identical then there is no issue starting workload in a remote instance - we have 3 other internal instances working nicely. The issue is only when I'm trying to start workload in an instance that has a different admin cert it seems.
I'm wondering if somewhere it's using the server cert from an instance perhaps. I'm not sure that really stacks up though.
Karl Prinelle
Jun 23, 2021, 12:56:35 PM6/23/21
to
The issue is our certificates lacked the extended key usage extension for client authentication. They have server authentication, but both appear to be needed (according to the SSL trace).
Renewing certs should sort that out. For reference the usage extensions that are needed are;
1.3.6.1.5.5.7.3.2 The certificate can be used for Client Authentication only
1.3.6.1.5.5.7.3.1 The certificate can be used for Server Authentication only
Eddie Hartman
Jun 24, 2021, 2:08:47 PM6/24/21
to
Thanks for sharing, Karl!
0 new messages