Ok…here is an update…
I debugged this further and here is what I found:
If you look at Local Outgoing Session .java source code (around lines 473 where the features are being checked to see if EXTERNAL is being offered…) . This is where it breaks (alteast the symptom). The stream:features obtained at that point in the code does not have any features and hence does not execute the EXTERNAL SASL authentication.
I forced the software to execute External SASL by commenting to see what happens and everything works like a charm.
So I thought let me figure out where the stream is coming from.
I found a few more things:
- In SASLAuthentication.java where getSASLMechanisms is invoked it checks to see if the connection is secure before offering EXTERNAL as a SASL mechanism for s2s connections.
This follows the specification , and hence we dont see SASL being offered in the first pass before TLS is negotiated.
Once TLS is negotiated, the interaction should be to open a new stream and offere the features that are valid for that stream. I know the TLS negotiation succeeds, but my suscpicion is :
- Either the new stream with features is not being requested or if it is being requested the “is Secure” flag on the session is not set.
I dont have a good packet debugger to see the packets apart from wireshark …where once TLS is negotiated nothing is visible. So I am not able to pin-point where the exact issue is, but someone who is familiar with the code could probably find it in a jiffy and tell us what we are doing wrong…
This has been a great education going through a lot of debugging figuring out how s2s and c2s works…with certificates…especially.
Hopefully someone can help.