Client gets SSL handshake failed on connect attempt

[Bananaphone]

I just set up a new Prosody server and am not able to connect with clients because of an SSL handshake error. Here's my setup

Ubuntu 13.04 server
Prosody 0.9.1 (installed through the quantal repo)

I have an IP, and a A record DNS pointing to it. I used prosodyctl to create a self signed certificate with common name matching, it was deposited into var/lib. I hooked the key and cert into the virtualhost config. When I look at the prosody server logs I see

Oct 04 20:04:10 socket    debug    ssl handshake error: no shared cipher

I tried both Pidgin and Jitsi, got the same error.

error log contains nothing, I verified through the telnet console that the virtualhost is activated.

I'm out of ideas, has anybody else experienced this?

[Matthew Wild]

Hi,

On 5 October 2013 04:15, Bananaphone <erik.e...@gmail.com> wrote:
> I have an IP, and a A record DNS pointing to it. I used prosodyctl to create
> a self signed certificate with common name matching, it was deposited into
> var/lib. I hooked the key and cert into the virtualhost config. When I look
> at the prosody server logs I see
>
> Oct 04 20:04:10 socket debug ssl handshake error: no shared cipher
>
> I tried both Pidgin and Jitsi, got the same error.
>
> error log contains nothing, I verified through the telnet console that the
> virtualhost is activated.

I'm afraid in these cases we're at the mercy of the the SSL library
(OpenSSL) to inform us of what's wrong - and as you can see, it's not
always very helpful.

I've seen this one before however - it can happen when your configured
certificate or key are not in the correct format. Double-check that
you copied the right files into place (.key and .crt), and that the
paths are correct in the config, and that the files are readable
(though the latter usually gives a noisy error).

If none of this works, please run tcpdump on the client or server
while you attempt to connect: sudo tcpdump -i any -s0 -w
no-shared-cipher.pcap port 5222

Send us no-shared-cipher.pcap, you can email it directly to
devel...@prosody.im if you want.

Regards,
Matthew

[Bananaphone]

Well, I slept on it and the next morning I tried a few more things. I got it working. I guess I uncommented the global ssl config, which was still referencing the "fake" ssl crt and key files, which of course do not exist. I switched them to match the new files created, and it worked. For some reason I thought that if I defined a site-specific ssl configuration that the global one (wrong or not) was unimportant. That was an incorrect assumption :-)

Thanks nevertheless, setup of an XMPP server still took less time than expected thanks to Prosody.

[Matthew Wild]

On 5 October 2013 17:54, Bananaphone <erik.e...@gmail.com> wrote:
> Well, I slept on it and the next morning I tried a few more things. I got it
> working. I guess I uncommented the global ssl config, which was still
> referencing the "fake" ssl crt and key files, which of course do not exist.
> I switched them to match the new files created, and it worked. For some
> reason I thought that if I defined a site-specific ssl configuration that
> the global one (wrong or not) was unimportant. That was an incorrect
> assumption :-)

Assumption correct actually (or supposed to be, unless there is a
bug). Perhaps you have legacy_ssl_ports set? Then the client might try
to connect through that, which does require a global 'ssl' option to
be set.

> Thanks nevertheless, setup of an XMPP server still took less time than
> expected thanks to Prosody.

Glad to hear it!

Regards,
Matthew