What steps will reproduce the problem? 1. Configure ssl with a typo ssl = { key = "/usr/local/etc/letsencrypt/live/federation.definitelyreal.coffee/privkey.pem"; oertificate = "/usr/local/etc/letsencrypt/live/federation.definitelyreal.coffee/fullchain.pem"; } OR 1b. Install an mismatched privkey.pem 2. Try to connect What is the expected output? What do you see instead? Prosody complains loudly if permissions disallow it reading a private key, like this: ``` certmanager error SSL/TLS: Failed to load '/usr/local/etc/letsencrypt/live/federation.definitelyreal.coffee/privkey.pem': Check that the permissions allow Prosody to read this file. (for localhost) localhost:tls error Unable to initialize TLS: error loading private key (Permission denied) certmanager error SSL/TLS: Failed to load '/usr/local/etc/letsencrypt/live/federation.definitelyreal.coffee/privkey.pem': Previous error (see logs), or other system error. (for localhost) localhost:tls error Unable to initialize TLS: error loading private key (system lib) ``` Since I *don't* see that, I expect SSL is working. But if the private key is accidentally undefined or unusable, prosody's certmanager module simply never gives any output at all. The first notice given that something is wrong is when you receive "SSL Handshake Failed" or some variant of that from your client, and these messages from prosody: ``` socket debug server.lua: accepted new client connection from 192.197.121.179:17183 to 5222 c2s8041b3c80 info Client connected c2s8041b3c80 debug Client sent opening <stream:stream> to federation.definitelyreal.coffee c2s8041b3c80 debug Sent reply <stream:stream> to client c2s8041b3c80 debug Received[c2s_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> socket debug server.lua: we need to do tls, but delaying until send buffer empty c2s8041b3c80 debug TLS negotiation started for c2s_unauthed... socket debug server.lua: attempting to start tls on tcp{client}: 0x8041b4028 socket debug server.lua: ssl handshake error: no shared cipher c2s8041b3c80 info Client disconnected: ssl handshake failed c2s8041b3c80 debug Destroying session for (unknown) ((unknown)@federation.definitelyreal.coffee): ssl handshake failed socket debug server.lua: closed client handler and removed socket from list ``` When it fails, that "no shared cipher" is the most misleading thing. The problem has nothing to do with the choice of ciphers. It's more like a SSL session couldn't be started even to get so far as to negotiate ciphers. What version of the product are you using? On what operating system? Pidgin 2.11.0 on FreeBSD 10.3, prosody 0.9.10 on FreeBSD 10.1. Please provide any additional information below. It would be much better if prosody verified every ssl {} config section at init time by making sure it can use the privkey with the cert to actually create an SSL session, and if that fails for any reason, quit. The error message when a privkey is unreadable makes me think that *all* SSL problems have been checked for at init, but that isn't true.

The error "no shared cipher" comes from OpenSSL. The set of supported ciphers are empty, because all of them require that the key be present. There are ciphers that don't require a key, but these are disabled by default and not commonly used. In theory it is also possible to have more than one key, for example if you have both RSA and EC certificates enabled. A change was landed in LuaSec to verify that a matching certificate and key are set: https://github.com/brunoos/luasec/pull/17 I think this should be in LuaSec 0.6 and should help with this.

Oh, typo in "certificate = " ? That was fixed in https://hg.prosody.im/0.10/rev/576488cffc3a

• owner Zash
• tags Milestone-0.10 Status-Fixed