Ошибка SSL протокола CloudFlare - на XP и в старых мобильных

[Zacker2]

Windows XP и старые мобильные выдают ошибку подключения: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
В случаи с компами, проблема решается при установке Фирефокса.
Opera и Chrom выдают - ошибка обрыва соединения ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Вот такие настройки в CF.


Подскажите пожалуйста, может кто-то сталкивался, что поможет вылечить проблему.

 

[mrLom]

Так достаточно в nginx конфиге для домена добавить строку вида:

add_header Public-Key-Pins 'pin-sha256="rftygurefvgyuhnbgfiuhbfghjknhnfhkjnhtgjklnthn="; pin-sha256="gyugrt9huy45gtr8uioy4gtu9ijopt45geuhrthu45tgu8oijt35geriokp="; max-age=31536000';

Обе переменные пинов можно получить из полученной подписи сертификата от провайдера подписанта, при необходимости нужно создавать с промежуточным сертификатом:

openssl x509 -in 1_полученный_сертификат_bundle.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
openssl rsa -in 1_полученный_сертификат_bundle.crt -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64

Собственно вот схема действующего конфига, который позволит сделать ваш сертификат класса А+

ssl  on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
#используем только перечисленные алгоритмы
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';

Далее в этот суп нужно добавить:

#Когда клиент подключается по HTTPS, то он осуществляет проверку сертификата на отзыв. Делается это двумя путями – через список отозванных сертификатов (Certificate Revocation List) или же по протоколу Online Certificate Status Protocol (OCSP). Проблема с CRL заключается в том, что с каждым днем список может разрастаться, и загрузка данного списка может занимать все больше и больше времени. OSCP протокол же наоборот, получает информацию только по заданному сертификату и позволяет ее хранить некоторое время в кэше. Добавим эту возможность для Nginx, она доступна начиная с версии 1.3.7#
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
#тут проверка закончилась#
add_header Strict-Transport-Security max-age=31536000 always;
add_header Public-Key-Pins 'pin-sha256="rftygurefvgyuhnbgfiuhbfghjknhnfhkjnhtgjklnthn="; pin-sha256="gyugrt9huy45gtr8uioy4gtu9ijopt45geuhrthu45tgu8oijt35geriokp="; max-age=31536000';

#Добавление подобных заголовков заставят браузер посетителя принудительно использовать HTTPS вместо HTTP и если сайт полностью размещен в HTTPS, но имеет ряд ссылок на HTTP, например на картинки, то данные заголовки обяжут браузер загружать изображение по безопасному протоколу.
add_header X-Content-Type-Options nosniff;
# этот параметр необходимо использовать с особой осторожностью, т.к. X-Frame-Options разрешает или запрещает отображение страницы, если она открыта во фрейме. Позволяет защитить ваши страницы от некоторого рода атак: https://learn.javascript.ru/clickjacking
add_header X-Frame-Options DENY;
add_header X-XSS-Protection "1; mode=block";
#

add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report";
ssl_certificate  /etc/nginx/ssl/1_полученный_сертификат_bundle.crt;
ssl_certificate_key  /etc/nginx/ssl/сертификат-decrypt.key;
ssl_dhparam  /etc/nginx/ssl/dhparam.pem;
ssl_trusted_certificate /etc/nginx/ssl/root.crt;
ssl_session_cache  shared:SSL:10m;
ssl_session_timeout  10m;

Алгоритм Диффи-Хеллмана обеспечит обмен ключами для защиты сессии, при его помощи вырабатывается общий секрет для шифрования сообщений. Для повышения надежности генерации секретов следует самостоятельно сгенерировать параметры для работы алгоритма Диффи-Хеллмана dhparam.pem и получаем так:

openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096

Может генериться от пары минут, до 10-15 минут, в зависимости от мощности вашего компьютера. Лично я генерю его за минуту на домашнем компе, в провайдере на VDS доходило до 20 минут.

Как то так

 

[wpt]

Привет Lom! Рад тебя видеть и в "администрировании серверов"
Не подскажешь на тему SNI, в частности интересует как избавиться от "This site works only in browsers with SNI support."
В вэб окружении несколько сайтов на одном ip. Сертификаты установлены. Однако в некоторых браузерах выдается ошибка ssl.
Из гугла понял что в этих браузерах за одним ip можно закрепить только один сертификат.
ps - еще я предполагаю что из-за этого как раз и выскакивает ошибка работы с сокетами при проверки системы.

 

[Stesh]

как избавиться от "This site works only in browsers with SNI support."

1. Разнести сертификаты на разные ip
2. Использовать SAN-сертификат (он же мультидоменный), выданный на все домены, которые висят на этом ip.

 

[wpt]

1. Разнести сертификаты на разные ip
2. Использовать SAN-сертификат (он же мультидоменный), выданный на все домены, которые висят на этом ip.

Мультидоменный сертификат бесплатным не бывает?

 

[Kub]

Бывают мультидоменные бесплатные. На Для просмотра ссылки Войди или Зарегистрируйся можно такие получить. Только максимальное количество доменов я не смог определить. Где пишут на 5 доменов, где до 100 доменов в одном сертификате.
Еще у китайцев на Для просмотра ссылки Войди или Зарегистрируйся можно было получить сертификат до 20 доменов, но они временно приостановили раздачу с 29 сентября.

 

[mrLom]

На сколько мне известно CloudFlare выдает мультисерсификат, на доменное имя и на свои сервера. И тут скорее больше проблема не сертификата, а настройки сервера. Сертификат, он тупо сертификат, а вот методы обмена позволяет создавать исключительно сервер.
На один IP можно сконфигурировать выдачу разных сертификатов, благо nginx позволяет подключать разные сертификаты.

Почитать о методах, потестировать рейтинги настройки своего и чужих серверов можно тут:
Для просмотра ссылки Войди или Зарегистрируйся ← яша вот позволяет себе делать насройки сервера с рейтингом класса B
Вам же нужно, если вы хотите что бы «избавиться от "This site works only in browsers with SNI support."» — нужно достичь настройки сервера до уровня рейтинга класса А+

Данная тема не однократно поднималась на Хабре, да и на других специализированных гик ресурсах.
К слову, если вы сегодня добились настройки уровня А+, не факт, что через пару месяцев вы в нем удержитесь. После публикации так называемых null-day уязвимостей по ssl некоторые методы шифрования очень резко деградируют и больше не считаются безопасными, как и использование подобных методов. Для взлома можно принудительно применить уязвимый метод.
Вам просто необходимо мониторить данную тему. А так же найти золотую середину, кого вы рады видеть у себя в пользователях, а кого нет.
Методы используемые в Яше и Гугле служат ярким примером оптимальной настройки безопасности шифрования. Следуйте их примеру.

Именно по их примеру не стоит гоняться за удовлетворением всех категорий пользователей, которые пользуются небезопасными браузерами. Особенно если это связано с безопасностью вашего же сервера. Я вот, например, исключаю подобные веб-браузеры из своего окружения и гори оно нафиг «А+», если подобный пользователь не может зайти из своего любимого древнего Андроид планшета текстового редактора или из очень древней мозиллы!
Может быть именно им, простите, задротам, стоит начать задумываться, а почему это их не пускает на 99% процентов ресурсов. В помойку планшет!

 

[wpt]

У меня сейчас сертификаты от стартссл и от китайцев. Насколько я помню, добавлять в сертификат можно было только поддомены..

 

[mrLom]

У меня сейчас сертификаты от стартссл и от китайцев. Насколько я помню, добавлять в сертификат можно было только поддомены..

Название темы все же: Ошибка SSL протокола CloudFlare - на XP и в старых мобильных — и решение — понизить уровень безопасности сервера.

У вас же несколько другие исходные данные

В вэб окружении несколько сайтов на одном ip. Сертификаты установлены. Однако в некоторых браузерах выдается ошибка ssl.

В nginx необходимо вручную перепрописать конфигурации к сертификатам.
На сколько я помню, в конфигах ssl доменов есть ссылки на конфигурацию ssl.conf сертификата. По умолчанию, один и тот же конфиг применяется во всех доменах. Самоподписной.
Необходимо раскопировать под каждый домен данный конфиг и прописать там сертификаты, подписи, промежуточные подписи для каждого отдельно взятого вашего домена.

 

[Kub]

Лучше один сертификат мультидоменный. Тогда в старых браузерах без поддержки Server Name Identification (SNI) проблем с доступом к сайту не будет.
На стартссл на домен и один поддомен выдают сертификаты. На WoSign можно было до 20 доменов на 3 года. Вот здесь скрин даже есть Для просмотра ссылки Войди или Зарегистрируйся