У меня есть подстановочный SSL-сертификат для *.example.com
.
Я использую Nginx и перенаправляю весь трафик с HTTP на HTTPS, а также переписываю URL-адреса, чтобы удалить субдомен www (если он есть).
Так оно и есть,
http://subdomain.example.com
---> https://subdomain.example.com
http://www.subdomain.example.com
---> https://subdomain.example.com
https://www.subdomain.example.com
---> https://subdomain.example.com
https://subdomain.example.com
---> https://subdomain.example.com
Однако, поскольку мой сертификат предназначен для *.example.com
, случай 3 получает ошибку SSL в chrome («Вероятно, это не тот сайт, который вы ищете!»), но если вы щелкнете по нему, он будет перенаправлен, и все в порядке.
Я понимаю, почему, поскольку начальное соединение для HTTPS с www (2 уровня поддоменов), что не соответствует тому, что указано в сертификате с подстановкой.
Я думал, что решением будет получить дополнительный сертификат для *.*.example.com
покрывать www.*.example.com
. Но похоже, что это не сработает. Я разговаривал с агентами из Namecheap и Comodo, и оба сказали *.*.example.com
не представилось возможным.
Я также наткнулся Эта статья в котором говорится:
Будет ли SSL работать с многоуровневыми подстановочными знаками?
В распространении Firefox 3.5 все основные браузеры допускают только один уровень сопоставления поддоменов с именами сертификатов, которые содержат подстановочные знаки, в соответствии с RFC 2818.
Другими словами сертификат
*.mydomain.com
будет работать наone.mydomain.com
илиtwo.mydomain.com
но нетone.two.mydomain.com
.
Есть ли этому решение? Чтобы уметь прикрыть www.*.example.com
?
Сертификаты с подстановочными знаками идут только на один уровень. Вам нужно будет получить подстановочный знак, который также имеет альтернативные имена для всех www.<subdomain>.example.com
места. Это позволит выполнить перенаправление.
Любое решение, кроме размещения действительных сертификатов на двухуровневых поддоменах, не будет работать, потому что рукопожатие SSL всегда будет происходить перед любым перенаправлением или повторной записью.
Небольшой обходной путь - переписать URL-адреса перед установкой SSL-соединения, но вы никогда не получите https://www.subdomain.mydomain.com работать без предупреждения, прежде чем вы получите сертификат для этого доменного имени. Что-то такое:
server {
listen 111.222.333.444:80;
server_name www.subdomain.mydomain.com;
rewrite ^ https://$host$request_uri permanent;
}
server {
listen 111.222.333.444:443
server_name subdomain.mydomain.com
ssl on;
...
}
Проблема в том, как работают сертификаты с подстановочными знаками. Как вы видите, они работают только с поддоменами первого уровня. Чтобы обойти это, вам нужно использовать запись PTR, чтобы указать www.subdomain.domain.com на subdomain.domain.com, и он должен быть невидимым для сервера.