[omniORB] Fallback from SSL to TCP on CA failure?

[Peter Klotz]

Hello

I have a client/server SSL setup with deliberately misconfigured 
certificates.

Options -ORBclientTransportRule and -ORBserverTransportRule are '* 
ssl,tcp' for client and server.

The server has a TCP and an SSL listen port who are both published in 
its IOR. omniNames just uses a TCP listen port.

The server implements two servants who each have a trivial ping() method.

Calling A::ping() results in a client side TRANSIENT_ConnectFailed 
exception. No fallback from SSL to TCP is performed.

Calling B::ping() works by performing a fallback to TCP (according to 
tcpdump).

Following is the trace level 40 output which we redirected to our 
logging framework.

Call of A::ping() which fails:

2009-10-03 23:38:03.506458 V omniORB          pid: 27194 tid: 1120360768
     omniORB: Scan for idle connections done (1254605883,504876000).
2009-10-03 23:38:05.445609 V omniORB          pid: 27194 tid: 1118259520
     omniORB: openSSL error detected in sslEndpoint::accept.
     Reason: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert 
unknown ca
2009-10-03 23:38:05.495830 V omniORB          pid: 27194 tid: 1118259520
     omniORB: SocketCollection idle. Sleeping.
2009-10-03 23:38:08.507753 V omniORB          pid: 27194 tid: 1120360768
     omniORB: Scan for idle connections (1254605888,506495000)

Call of B::ping() which succeeds:

2009-10-03 23:40:28.576844 V omniORB          pid: 27194 tid: 1120360768
     omniORB: Scan for idle connections (1254606028,575725000)
2009-10-03 23:40:28.576946 V omniORB          pid: 27194 tid: 1120360768
     omniORB: Scan for idle connections done (1254606028,575725000).
2009-10-03 23:40:30.484465 V omniORB          pid: 27194 tid: 1118259520
     omniORB: openSSL error detected in sslEndpoint::accept.
     Reason: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert 
unknown ca
2009-10-03 23:40:30.485112 V omniORB          pid: 27194 tid: 1116158272
     omniORB: Server accepted connection from giop:tcp:10.18.1.19:60232
2009-10-03 23:40:30.485268 V omniORB          pid: 27194 tid: 1102518592
     omniORB: AsyncInvoker: thread id = 57 has started. Total threads = 4
2009-10-03 23:40:30.485272 V omniORB          pid: 27194 tid: 1102518592
     omniORB: giopWorker task execute.
2009-10-03 23:40:30.485274 V omniORB          pid: 27194 tid: 1102518592
     omniORB: Accepted connection from giop:tcp:10.18.1.19:60232 because 
of this rule: "* ssl,tcp"
2009-10-03 23:40:30.485451 V omniORB          pid: 27194 tid: 1102518592
     omniORB: inputMessage: from giop:tcp:10.18.1.19:60232 38 bytes



How can the behavior be different depending on calling A::ping() or 
B::ping()?

Is it the desired behavior that omniORB (4.1.4) performs a fallback from 
SSL to TCP if the CA check fails?

I assumed that client and server agree on a transport that both support 
according to the published IOR and once started their communication are 
unable to fallback to anything else.

Any help is highly appreciated.

Regards, Peter.