← Back to team overview

mosquitto-users team mailing list archive

Re: SSL connection from Java client to mosquitto broker: "no certificate returned"

 

Dear Sharon,

> By the way, after tweaking kernel params, I was able to open 100K concurrent
> clients to one broker instance on a medium sized EC2 machine.  Good work,
> mosquitto!

That's great to hear! Thanks for letting me know.

> Now I am trying to set up a secured connection using SSL.  I want to
> authenticate the client using a client certificate.

...

> I figured that the CA certificate is used for the client to authenticate the
> server, while the client key and certificate are used for the server to
> authenticate the client.

Yes, exactly. If require_certificate is false it's the same principle
as used in web browsers. Clients trust servers that have had their
certificate signed by CAs that the client have the CA cert loaded. In
web browsers there are typically a big list of CA certificates loaded
of course, whereas there is no real need for that here (nothing to
stop it of course). If require_certificate is true, the same thing
happens in the opposite way as well - clients have to have
certificates signed by the CA that the server trusts.


> So I here is what I did on the Java side:

That all sounds plausible, but I've got no real experience of Java so
it's difficult to comment on the details I'm afraid.

> When I do the connect, I get the following error from mosquitto
>
> OpenSSL Error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no
> certificate returned

That's the same error I'd expect (and get through some testing) if the
client isn't sending a client certificate. Have you tested your client
certificate/key with mosquitto_sub?

This should work:

mosquitto_sub -t \$SYS/# -h <host> --cafile <file> --cert <file> --key <file>

And this should reproduce the above error:

mosquitto_sub -t \$SYS/# -h <host> --cafile <file>


>       SSLContext context = SSLContext.getInstance("SSLv3");

You should note that as it stands mosquitto only allows the use of the
TLSv1 protocol so the above should fail. It ought to fail earlier on
in the connection though, so I don't think it should contribute to
your error. I presume you've patched to use SSLv3 instead. It should
really be user configurable but as there isn't any need to be
backwards compatible I didn't think allowing older versions was
necessary.

Cheers,

Roger


Follow ups

References