у меня естькомпания.svдомен и недавно приобрел подстановочный сертификат RapidSSL, я установил его и протестировал во многих браузерах (Firefox, Chromium, Chrome, IE) и инструментах проверки SSL. Он отлично работал во всех браузерах, кроме Google Chrome, ни в Windows, ни в Linux, ни в Android.
Каждый раз, когда я захожу на сайт через Google Chrome, появляется предупреждение о том, что я пытался получить доступwww.company.svилилюбая.компания.svно сервер идентифицирует себя как **.company.sv*. Если я продолжу, несмотря на предупреждение, и нажму на красный замок, он скажет мне, что я подключен к серверу, который действителен только внутри моей сети и не может быть проверен через внешний объект сертификации.
Я связался со службой поддержки реселлера сертификатов, но они не смогли дать мне прямого ответа о том, в чем проблема. Я задавался вопросом, связано ли это с тем, что TLD.sv. Я также проверил исходный код Chromium, но это кажется бесполезным, поскольку сертификат безупречно работает на Chromium.
Возможно, стоит упомянуть, что я использую NGINX на сервере Ubuntu 12.04 и что я протестировал бесплатный однодоменный сертификат от Comodo, прежде чем покупать подстановочный сертификат.
решение1
Похоже, вы забыли установить промежуточный пакет сертификатов на своем веб-сервере. Посетите веб-сайт поставщика сертификатов, чтобы загрузить промежуточный пакет.
Для nginx это необходимо объединить с вашим сертификатом и поместить в ssl_certificateдирективу, например:
# cat company.sv.crt ca_bundle.crt > company.sv.chained.crt
И в вашей конфигурации nginx:
ssl_certificate /etc/path/to/company.sv.chained.crt
решение2
Я подозреваю, что у вас есть имя сайта в поле Subject CN=, оно должно быть в поле альтернативного имени субъекта, чтобы Chrome принял его. Если вы отображаете сертификат в браузере или с помощьюopenssl x509 -in certificate-file -text
Видеть:
Эти базовые требования обязывают центры сертификации всегда включать в выдаваемые ими SSL-сертификаты по крайней мере одно альтернативное имя субъекта. Это означает, что сегодня приложению не нужно проверять и общее имя, и альтернативное имя субъекта, достаточно проверить только последнее.
В настоящее время большинство центров сертификации также включают первое DNS-имя из альтернативного имени субъекта в поле общего имени, но это делается в первую очередь из соображений сохранения наследия и в не столь отдаленном будущем прекратится.
Сертификаты имеют два способа выражения домена/IP, к которому они привязаны, — один из них неструктурированный и неоднозначный (commonName), а другой — четко определенный (subjectAltName). При отсутствии SubjectAltNames Chrome в настоящее время возвращается к сравнению домена с commonName, если он есть.
Это предложение заключается в том, чтобы удалить этот резервный путь; по сути, требуя subjectAltName. В идеале мы бы сделали это для всех сертификатов (публично доверенных и конфиденциально доверенных), но если есть опасения по поводу риска совместимости, мы можем ограничить его до публично доверенных сертификатов.