Что-то изменилось в nginx и https на виртуальных хостах?

У меня было представление, что HTTPS устанавливается еще до понятия вебсервером о каком виртхосте будет идти речь и брались данные из первого ssl хоста.

У меня, видимо, было иное представление.
Регулярно сталкиваюсь с описанным, никакого баттхё недоумения никогда не вызывало. Сертификаты ведь выдаются на доменное имя, и одна из частей их смысла - убедиться, что хост действительно тот, за кого себя выдаёт.
Хотя не исключаю, что когда-то было иначе, но если и так, то точно более года назад.

Регулярно сталкиваюсь с описанным, никакого баттхё недоумения никогда не вызывало. Сертификаты ведь выдаются на доменное имя, и одна из частей их смысла - убедиться, что хост действительно тот, за кого себя выдаёт.

Это да, но можно установить защищенное соединение и просто с IP, без домена и я точно помню что был такой баттхерт, когда по разным виртхостам были разные пары ключей и в продакшне работал только один, а остальные эррорили на чужой сертификат.

Update:

Погуглил, нашел подтверждение своему баттхерту:

https://en.wikipedia.org/wiki/Virtual_hosting

The biggest issue with name-based virtual hosting is that it is difficult to host multiple secure websites running SSL/TLS. Because the SSL/TLS handshake takes place before the expected hostname is sent to the server, the server doesn't know which certificate to present in the handshake. It is possible for a single certificate to cover multiple names either through the «subjectaltname» field or through wildcards but the practical application of this approach is limited by administrative considerations and by the matching rules for wildcards. There is an extension to TLS called Server Name Indication, that presents the name at the start of the handshake to circumvent that issue, except for some older clients (in particular Internet Explorer on Windows XP or older Android versions) which do not implement SNI.

Вот как раз эта проблема (жирным пометил) и решалась одинаковым PrivateKey, так как пофигу какой из публичных прилетит - все равно расшифровываются одним.

Верно говорят что в правильно сформулированном вопросе уже содержится ответ:

только в двух случаях: SNI или же общий private.key
SNI или
SNI

Случившееся чудо называется «смерть IE6 и Windows XP» не поддерживавших SNI. Глянь на sslabs, там в детальном отчёте скорее всего будут аллерны про то что сайт не работает в IE6 и IE8 под XP потому-что они не умеют в SNI. Но sslabs похоже даже не снижает за это балл.

Случившееся чудо называется «смерть IE6 и Windows XP» не поддерживавших SNI. Глянь на sslabs, там в детальном отчёте скорее всего будут аллерны про то что сайт не работает в IE6 и IE8 под XP потому-что они не умеют в SNI. Но sslabs похоже даже не снижает за это балл.

Да, это, видимо, был пробел в моих знаниях. Я думал что SNI касается только многодоменности в рамках одного сертификата (по крайней мере, ранее точно нужно было отдельно запрашивать SNI сертификат), а он оно как...

Дабы совсем пофиксить этот пробел, ответь плиз на вопрос: самих сертификатов это все таки тоже касается? Могу ли я создать какие-то 2 «простых» сертификата, которые уже не смогут работать на одном IP? И мне повезло с тем, что в каждом из этих сертификатов у меня есть поддомены и сервер как бы «ожидает» что хендшейк будет с SNI?

Я думал что SNI касается только многодоменности в рамках одного сертификата

Что-что простите? Какая разница сколько доменов в сертификате, это ведь просто стринга. Не интересовался подробностями SSL/TLS но по логике как должна выглядеть установка соединения в общем случае?
1) Клиент отправляет запрос на сервер.
2) Сервер возвращает сертификат (публичный ключ + кусок структурированного текста про то кому принадлежит соответствующий приватный ключ + подпись УЦ).
3) Клиент проверяет подпись сертификата, если подпись кошерна то проверяет его данные. В частности проверяет его Common Name (CN). В случае https CN содержит домен или список доменов, один из доменов в списке должен совпадать с тем доменом к которому хочет обратиться клиент.

SNI или ещё какие-то ухищрения могут понадобиться только в случае если без них сервер не может определить какой сертификат нужно отправлять клиенту, т.е. если не соблюдается правило «один IP:port — один сертификат».