Ошибка установления связи SSL в Nginx (нет подходящего совместного использования ключа)
Чтобы краткость введения была короткой, я пытаюсь выяснить смысл и причину этой ошибки подтверждения 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 (CODE) для подключения к моя установка Nextcloud в моей системе Arch Linux. Оба работают на одном сервере, где nginx является прокси для Collabora. Мой сервер Nextcloud отлично работает, как и все другие сайты и сервисы, которые я предоставляю со всем, что работает через SSL. Однако после того, как у меня уже были проблемы с подключением CODE к моей установке Nextcloud, я, наконец, добился его отображения, хотя в нем говорится о проблемах с подключением к моим документам.
Для устранения неполадок следует отметить, что пакет Collabora напрямую основан на LibreOffice Online и многие части его кодовой базы совпадают. После нескольких часов поиска решений и устранения неполадок с различными настройками конфигурации как в 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;
Это позволит этому клиенту подключиться.