2

To keep the introduction short I am trying to figure out the meaning and cause of this SSL handshake error in nginx. Specifically the part about the key share since searching the error has found no results.

SSL_do_handshake() failed (SSL: error:141F7065:SSL routines:final_key_share:no suitable key share) while SSL handshaking.

Let me explain my situation a little more: I'm trying to get Collabora Online Development Edition (CODE) to connect to my Nextcloud setup on my Arch Linux system. Both run on the same server with nginx being the proxy for Collabora. My Nextcloud server runs great and so do all other sites and services I provide with everything going through SSL. However, after already having trouble connecting CODE to my Nextcloud installation, I finally got it to show up though it states to have trouble connecting to my documents.

For troubleshooting it should be noted that Collabora's suite is directly based on LibreOffice Online and as such many parts of its codebase match up. After hours of searching for solutions and troubleshooting different configuration settings in both nginx and loolwsd, I found out that LibreOffice Online's Web Service Daemon has trouble connecting to the WOPI storage URI provided by Nextcloud.

Cannot get file info from WOPI storage uri [Nextcloud URL with privilege key].
Error: SSL Exception: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure | wsd/Storage.cpp:531

Connecting to the URL from cURL yields the correct payload meaning the Nextcloud server is working as intended.

nginx on the other end produces this error when handling the request.

SSL_do_handshake() failed (SSL: error:141F7065:SSL routines:final_key_share:no suitable key share) while SSL handshaking.

I previously thought that it might have something to do with the ciphers since it seems to me that loolwsd uses an outdated set of ciphers but that error message points in a different direction.

Both domains under nginx use the same SSL parameters.

# General SSL configuration.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384";
ssl_ecdh_curve secp384r1;
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

# DNS resolver configuration. Use Google DNS.
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

# Security headers.
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";

# Diffie-Hellman key. Generate using: openssl dhparam -out dhparam.pem 4096
ssl_dhparam /etc/ssl/certs/dhparam.pem;

The OpenSSL version used on the server is 1.1.1

My main question now is what does "no suitable key share" specifically mean and what is its cause?

Catlinman
  • 23
  • 5

1 Answers1

4

This error is specific to TLSv1.3 as implemented by OpenSSL 1.1.1, and means that no common key exchange mechanism was found between the client and the server. Most likely, the culprit is:

ssl_ecdh_curve secp384r1;

It limits available EC curves to secp384r1 only, while the client explicitly uses prime256v1.

Try commenting out ssl_ecdh_curve. The default is auto, which is a reasonable list of curves defined by the OpenSSL library.

Alternatively, if you want to be explicit, list both prime256v1 and secp384r1:

ssl_ecdh_curve secp384r1:prime256v1;

This will allow this client to connect.

Maxim Dounin
  • 3,466
  • 17
  • 22
  • 2
    Thanks a ton! This was in fact what was causing the issue. Saved my day :) – Catlinman Sep 21 '18 at 20:04
  • My nginx (1.14/ubuntu with Openssl 1.1.0) this config "ssl_ecdh_curve secp384r1;" was working good, but after Chrome upgrade (to 76.0.3809.100) website stop working. Commenting out this line bring website work again in Chrome. On other servers with older Nginx (and OpenSSL) there is no problem.. – Jack Aug 16 '19 at 16:17