LINUX.ORG.RU

История изменений

Исправление Pinkbyte, (текущая версия) :

Let's encrypt-овский - никак. Тут логика вот в чём(в общем случае, отбросим пока всякие HPKP) - корневые CA на клиенте считаются доверенными для выдачи сертификатов на любые сайты.

То есть предположим у тебя корпоративная среда. Ты распространяешь свой CA на клиенты(через Active Directory или еще как-нибудь). И потом просто отдаешь страницы с любого домена подписанные своим CA(как это делать - вопрос десятый). И клиенты считают что это окей.

В случае провайдера такая схема не взлетит, потому что доступа на компьютеры пользователей ты не имеешь - следовательно свой CA ты туда не внедришь. А ни один из CA, уже присутствующих на их компьютерах в списке доверенных не будет выписывать тебе сертификаты на любые непринадлежащие тебе домены.

Ну и заключительный совет - подтяни теорию по SSL/TLS - тогда таких вопросов возникать не будет. Ибо они изначально придумывались чтобы перехват(а редирект на свою страницу и/или выдача своего контента ВМЕСТО оригинально присутствующего на сайте - это перехват) был НЕВОЗМОЖЕН. Ну, за исключением случаев, когда сам пользователь жмет кнопку «да мне насрать»(и то - HSTS и этого не позволяет)

Исходная версия Pinkbyte, :

Let's encrypt-овский - никак. Тут логика вот в чём(в общем случае, отбросим пока всякие HPKP) - корневые CA на клиенте считаются доверенными для выдачи сертификатов на любые сайты.

То есть предположим у тебя корпоративная среда. Ты распространяешь свой CA на клиенты(через Active Directory или еще как-нибудь). И потом просто отдаешь страницы с любого домена подписанные своим CA(как это делать - вопрос десятый). И клиенты считают что это окей.

В случае провайдера такая схема не взлетит, потому что доступа на компьютеры пользователей ты не имеешь - следовательно свой CA ты туда не внедришь. А ни один из CA, уже присутствующих на их компьютерах в списке доверенных не будет выписывать тебе сертификаты на любые непринадлежащие тебе домены.