Is it possible that those are a result of your changes?

Wojciech Kapcia wrote:

Is it possible that those are a result of your changes?

I thought about that too, that's why I later tried with vanilla Tigase directly from the release branch. You can reproduce it very easily with a basic configuration like the one I've posted and using client certificates signed by a self-signed CA (I've been using CACert.org generated certificates - trusted.pem is a chain of the root CA and the class3 CA - but I guess it wouldn't change much). getPeerCertificates() will throw an exception in Oracle JDK 8 (sorry I forgot to mention the runtime version).

Anyway, my modifications at this point are very small (you've merge almost all of my patches). I'm attaching the diff between my master branch and your release branch.

If you need other information or know any other means to debug this in any way I'm glad to help.

Wait Wojciech, were you talking to me or to Andrzej?

It was more for Andrzej :-)

After looking into code I do not think that my latest changes introduced this change in behavior.

As I checked in 7.0.2 we used empty implementation of TrustManager which allowed any client certificate while in 7.1.0-SNAPSHOT (@release@ branch) we added better checking of validity of client certificates - this was done in task #2938 (commits commit:5999db46 and commit:ae041463). This change might be responsible for stronger checking of certificate validity, which may cause exceptions - I would suggest to look into cause of this exception as most likely there is some issue with certificate validity.

%bmalkow - could you check this as you introduced change with stronger certificate checking?

I checked SASL EXTERNAL with jaxmpp. Works as expected.

I used init.properties:

config-type = --gen-config-def
--virt-hosts = coffeebean.local
--user-db=mysql
--user-db-uri=jdbc:mysql://127.0.0.1:3306/tigasedb?user=tigase_username&password=tigase_password&useUnicode=true&characterEncoding=UTF-8&autoCreateUser=true
--admins = alice@coffeebean.local
--cluster-mode = true
--sm-plugins = +message-archive-xep-0136,+jabber:iq:auth,+urn:ietf:params:xml:ns:xmpp-sasl,+urn:ietf:params:xml:ns:xmpp-bind,+urn:ietf:params:xml:ns:xmpp-session,+jabber:iq:register,+jabber:iq:roster,+presence,+jabber:iq:privacy,+jabber:iq:version,+http://jabber.org/protocol/stats,+starttls,+msgoffline,+vcard-temp,+http://jabber.org/protocol/commands,+jabber:iq:private,+urn:xmpp:ping,+basic-filter,+domain-filter,+pep,-zlib
--debug = io,net,pubsub


c2s/clientCertCA=/Users/bmalkow/tmp/CA_dla_wojtka/certs/root_ca.pem
sess-man/plugins-conf/callbackhandler-EXTERNAL=tigase.auth.impl.CertBasedCallbackHandler

c2s/connections/5223/socket=ssl
--c2s-ports=5222,5223
--hardened-mode=true

I used code from git/master (commit:63cab1f645bde66146fb8d24976e0a019ddebfff)

I've been using the release branch, but comparing it with master differences don't seem to have impact on any SSL-related code (by the way, should I use master instead in general?)

I will do some more extensive tests (with more Android versions) and let you know.

Guys I'm an idiot. I don't know what is wrong with me.

I was doing tests with self signed certificates which of course were not accepted by Tigase default trust manager.

By the way, I can't see any way to override that behaviour. Can I use self signed client certificates with Tigase instead of patching it?

Thanks and sorry for the mess.

Daniele Ricci wrote:

I don't know what is wrong with me.

We can't help you with it. We are software developers.

I was doing tests with self signed certificates which of course were not accepted by Tigase default trust manager.

By the way, I can't see any way to override that behaviour. Can I use self signed client certificates with Tigase instead of patching it?

I'm not sure what you have in mind. What exactly certificate i what scenario?

To use SASL EXTERNAL you have to small CA: root CA certificate is in file root_ca.pem and client login to server with certificate signed by root CA. You not need to patch anything.

But if you're talking about jaxmpp library, then yes: you have write own TrustManager to accept servers self-signed SSL certificate.

Thanks and sorry for the mess.

naaah… happens… :-D

Bartosz Malkowski wrote:

I'm not sure what you have in mind. What exactly certificate i what scenario?

To use SASL EXTERNAL you have to small CA: root CA certificate is in file root_ca.pem and client login to server with certificate signed by root CA. You not need to patch anything.

But if you're talking about jaxmpp library, then yes: you have write own TrustManager to accept servers self-signed SSL certificate.

I use a dedicated CallbackHandler that doesn't take into account the xmppAddr identifier, but instead relies on a custom X.509 extension, but of course Tigase checks for the standards, and what it finds is:

1. certificate is self-signed (ClientTrustManagerFactory)

2. no JIDs are found in certificate (DefaultMechanismSelector.isJIDInCertificate)

Therefore, EXTERNAL doesn't show up and client can't offer it.

What I can and should do on my side is including a xmppAddr identifier in my client certificates, which will solve point 2, but self-signed certs still need a patch to Tigase.

What I meant here is: if I write something to inject a custom ClientTrustManagerFactory or a parameter to allow self-signed certificates to authenticate, would you accept it? For now I just wrote a hard-coded solution for myself, but I can improve it to make it available to anyone.

Thanks

tigase-server 7.2 no need special code to inject custom ClientTrustManagerFactory, however small changes have to be done to allow use custom factory.

I'm sorry I see you assigned the issue to me, do you need something from me?

If everything in this crumbled from old age thread is clear, you can just close it :)

Well I get that my patch to make the server accept self-signed client certificates is still needed right?

Anyway I don't think I can close the issue with my account permissions.

Unless there are other problems I believe this issue can be closed.