Подстановочные знаки SSL и CNAME

Я использую Amazon EC2 ELB и следую их рекомендации использовать CNAME для ссылки на общедоступный DNS ELB:

$ nslookup qa.mydomain.com
Server:     192.168.1.1
Address:    192.168.1.1#53

Non-authoritative answer:
qa.mydomain.com canonical name = mydomain-20530xxxx.us-west-1.elb.amazonaws.com.
Name:   mydomain-20530xxxx.us-west-1.elb.amazonaws.com
Address: 50.18.xxx.yyy

Я приобрел сертификат SSL с подстановочными знаками для защиты всех своих поддоменов. Таким образом, сертификат был выдан на *.mydomain.com. Однако, когда я посещаю qa.mydomain.com, все браузеры кричат ​​о безопасности. Сообщение в Google Chrome, когда я пытаюсь получить доступ к https://qa.mydomain.com, выглядит следующим образом:

Chrome сообщает: вы попытались получить доступ к mydomain-20530xxxx.us-west-1.elb.amazonaws.com, но вместо этого вы достигли сервера, идентифицирующего себя как * .mydomain.com. Это может быть вызвано неправильной конфигурацией на сервере или чем-то более серьезным.

Я ошибаюсь? Несовместимо ли использование CNAME с PKI / SSL? Какие у меня варианты?

Спасибо.

PS: Вот отчет об исполнении dig по адресу: qa.mydomain.com. Очевидно, фактическое доменное имя и результаты были замаскированы в целях безопасности.

$ dig qa.mydomain.com

; <<>> DiG 9.8.1-P1 <<>> qa.mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 961
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;qa.mydomain.com.       IN  A

;; ANSWER SECTION:
qa.mydomain.com.    1670    IN  CNAME   mydomain-205300xxxx.us-west-1.elb.amazonaws.com.
mydomain-205300xxxx.us-west-1.elb.amazonaws.com. 60 IN A 50.18.xxx.yyy

;; Query time: 105 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Aug  9 14:05:31 2012
;; MSG SIZE  rcvd: 121

person Raj    schedule 09.08.2012    source источник


Ответы (1)


Идет ли разрешение IP-адреса из CNAME или из записи DNS, не влияет на проверку имени сертификата.

Важно то, что имя, которое вы запрашиваете в URL-адресе, совпадает с одной из записей в сертификате.

Короче говоря, если в сертификате есть записи альтернативного имени субъекта, одна из них должна совпадать с именем хоста, которое вы запрашиваете; если нет записей SAN DNS, общее имя (CN) DN субъекта должно совпадать с именем хоста.

person Bruno    schedule 09.08.2012
comment
Спасибо за ответ, Бруно. Означает ли это, что SSL с подстановочными знаками просто не могут работать с CNAME, учитывая, что общее имя - * .mydomain.com? - person Raj; 10.08.2012
comment
Я сказал совсем не это: CNAME и подстановочные знаки вообще не связаны. Если у вас нет SAN и если CN - *.mydomain.com, https://something.mydomain.com будет работать. - person Bruno; 10.08.2012
comment
Что-то не складывается. У меня есть сертификат, выданный на * .mydomain.com. У меня есть сопоставление CNAME с моим именем, предоставленным Amazon. Когда я перехожу на страницу qa.mydomain.com, и Safari, и Google Chrome выдают мне плохой сертификат. Chrome сообщает: вы попытались достичь rmydomain-20530xxxx.us-west-1.elb.amazonaws.com, но вместо этого вы достигли сервера, идентифицирующего себя как * .mydomain.com. Это может быть вызвано неправильной конфигурацией на сервере или чем-то более серьезным ... - person Raj; 10.08.2012
comment
Вы почти наверняка используете неправильную косвенную адресацию вместо (или в сочетании с) вашего CNAME. Проверьте с помощью dig или любого инструмента запросов DNS, что qa.mydomain.com указывает на правильный IP-адрес. - person Bruno; 10.08.2012
comment
Привет, Бруно, спасибо за вашу постоянную помощь. В опубликованном мной фрагменте выполняется nslookup на qa.mydomain.com. Я обновляю свой вопрос с помощью (анонимного) отчета о раскопках. - person Raj; 10.08.2012
comment
Выглядит нормально. Проверьте с помощью инструментов разработчика Chrome или Firefox с Firebug / HttpFox, происходит ли перенаправление HTTP после первоначального подключения к https://qa.mydomain.com. Вероятно, это проблема конфигурации сервера. - person Bruno; 10.08.2012
comment
Бруно, перенаправление действительно было. Спасибо за понимание! - person Raj; 10.08.2012
comment
DIG равно Domain Information Groper; улучшение nslookup для систем Linux; хотя для Windows доступен через сторонний сервис. Подробнее о последнем здесь: danesparza.net/2011/05/using-the-dig-dns-tool-on-windows-7 - person JohnLBevan; 01.08.2017