Мой хостинг-провайдер недавно переиздал и заново установил SSL-сертификат для моего домена, после того как он допустил срок действия старого сертификата по ошибке.
Теперь я могу снова просматривать веб-сайт по протоколу HTTPS, как и мой хост, и ряд других пользователей.
Тем не менее, некоторые пользователи (по крайней мере дюжина из сотен) по-прежнему получают Your connection is not secureсообщения об ошибках в разных браузерах и платформах. (Трудно диагностировать проблему, которую я не могу воспроизвести.)
Я понимаю, что разные браузеры используют разные списки центров сертификации (CA.)
- Почему пользователь, использующий ту же версию Firefox, что и я (45.0.1 на OS X), получает
SEC_ERROR_UNKNOWN_ISSUERошибку (только для моего сайта), а я нет? Что делает это возможным? Упомянутый пользователь очистил свой кеш и перезагрузил свой ноутбук.
Я провел проверку SSL на digicert.com . Результат таков:
SSL-сертификат не является доверенным
Сертификат не подписан доверенным органом (проверка на соответствие корневому хранилищу Mozilla). Если вы купили сертификат в доверенном органе, вам, вероятно, просто нужно установить один или несколько промежуточных сертификатов. Обратитесь к вашему поставщику сертификатов за помощью в этом для вашей серверной платформы.
- Почему я могу подключиться к сайту без ошибки SSL, если это так?
источник
My hosting provider has recently re-issued and re-installed an SSL certificate for my domain, after they let the old one expire by mistake.- Почему вы оставили эту ответственность в их руках?Ответы:
Цепочка сертификатов вашего сертификата является неполной. Скорее всего, ваш поставщик не смог установить промежуточный сертификат при установке нового сертификата.
В большинстве случаев такие промежуточные сертификаты предоставляются центром SSL для поддержки некоторых старых браузеров и операционных систем. Вот почему, хотя это работает для вас, это не работает для некоторых ваших клиентов.
Действительно отличная утилита для проверки проблем SSL на вашем сайте - это проверка SSL-сервера SSLlabs . Как видно из приведенной выше ссылки, здесь возникает не только проблема цепочки, но и алгоритм подписи, используемый для создания вашего сертификата, ваш веб-сервер по-прежнему уязвим для атаки POODLE и все еще поддерживает RC4, который также считается небезопасным ...
Я не хочу ничего говорить против вашего провайдера веб-сервера, но на вашем месте я бы отправил им письмо, чтобы они исправили все эти проблемы как можно скорее или изменили на другого провайдера ...
источник
SEC_ERROR_UNKNOWN_ISSUERошибку, а я нет? Может быть, его версия ОС отличается?Чтобы сертификат был доверенным, он должен быть подписан объектом, которому доверяет комбинация вашего браузера / ОС, или который в свою очередь был подписан таким объектом. Обычно это делается одним доверенным корневым ЦС, который подписывает промежуточный ЦС, а промежуточный ЦС подписывает ваш сертификат. Это создает цепочку, как это:
Проблема здесь с промежуточным сертификатом CA. Чтобы убедиться, что каждый может проверить цепочку вплоть до корневого ЦС, ваш провайдер должен включить промежуточный сертификат в конфигурацию своего сервера. В этом случае они не имеют.
Причина, по которой это работает для некоторых пользователей, заключается в том, что они имеют промежуточный сертификат в своем собственном «хранилище доверенных сертификатов». В этих случаях они примут ваш сертификат, потому что они уже доверяют промежуточному звену. Но в случае, когда у ваших посетителей другая ОС / браузер, у них нет промежуточного сертификата, поэтому им нужно будет получить его от вашего веб-сервера - а ваш веб-сервер его не раздает, поэтому у них нет никакого способа проверяя это.
источник
Если вы использовали HTTP Pinning Public Key Pinning, и ваш провайдер выдал вам новый сертификат, публичные ключи могли уже измениться. Эти ключи сохраняются в браузере клиента на указанный вами период.
источник