Чтобы сделать введение кратким, я пытаюсь понять смысл и причину этой ошибки подтверждения SSL в nginx. В частности, о доле ключа, поскольку поиск ошибки не дал результатов.
SSL_do_handshake() failed (SSL: error:141F7065:SSL routines:final_key_share:no suitable key share) while SSL handshaking.
Позвольте мне объяснить мою ситуацию немного подробнее: я пытаюсь понять Collabora Online Development Edition (КОД) подключиться к моему Nextcloud установка в моей системе Arch Linux. Оба работают на одном сервере, где nginx является прокси для Collabora. Мой сервер Nextcloud отлично работает, как и все другие сайты и сервисы, которые я предоставляю со всем, что работает через SSL. Однако после того, как у меня уже были проблемы с подключением CODE к моей установке Nextcloud, я, наконец, получил его, хотя в нем говорится, что у меня проблемы с подключением к моим документам.
Для устранения неполадок следует отметить, что пакет Collabora напрямую основан на LibreOffice в Интернете и поэтому многие части его кодовой базы совпадают. После нескольких часов поиска решений и устранения неполадок с различными настройками конфигурации как в nginx, так и в loolwsd я обнаружил, что LibreOffice Online Демон веб-службы имеет проблемы с подключением к URI хранилища WOPI, предоставленному 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
Подключение к URL-адресу из cURL дает правильную полезную нагрузку, что означает, что сервер Nextcloud работает должным образом.
nginx на другом конце выдает эту ошибку при обработке запроса.
SSL_do_handshake() failed (SSL: error:141F7065:SSL routines:final_key_share:no suitable key share) while SSL handshaking.
Ранее я думал, что это может иметь какое-то отношение к шифрам, поскольку мне кажется, что loolwsd использует устаревший набор шифров но это сообщение об ошибке указывает в другом направлении.
Оба домена под nginx используют одинаковые параметры SSL.
# 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;
На сервере используется версия OpenSSL 1.1.1.
Мой главный вопрос сейчас: что конкретно означает «нет подходящего ключевого ресурса» и какова его причина?
Эта ошибка характерна для TLSv1.3, реализованного в OpenSSL 1.1.1, и означает, что не было обнаружено общего механизма обмена ключами между клиентом и сервером. Скорее всего, виной всему:
ssl_ecdh_curve secp384r1;
Он ограничивает доступные кривые EC только secp384r1, в то время как клиент явно использует prime256v1.
Попробуйте прокомментировать ssl_ecdh_curve. В дефолт является auto, который представляет собой разумный список кривых, определенных библиотекой OpenSSL.
В качестве альтернативы, если вы хотите быть явным, укажите оба prime256v1 и secp384r1:
ssl_ecdh_curve secp384r1:prime256v1;
Это позволит этому клиенту подключиться.