Выбор домена для защиты

У нас есть веб-сайт, который обслуживается обоими www.example.comи просто example.com- мы никогда не делали принудительного перемещения пользователей с одного домена на другой, поэтому, если они попадают на сайт, example.comто именно там они и остаются, и я предполагаю, что из этих для тех, кто добавляет в закладки наши страницы, они будут разделены на 50/50 (ранее была проблема, когда в некоторых наших материалах не было WWW, а спустя годы мы все еще замечаем разделение трафика).

Сейчас мы добавляем SSL. Мы не применяем SSL, пока пользователь не перейдет на страницу входа или регистрации. На каком домене мы должны запустить наш SSL?

www.example.com
example.com
secure.example.com
Что-то другое?

Я делал много сайтов SSL раньше, но они всегда разрабатывались с учетом SSL, и мы всегда использовали поддомен www.

Есть ли плюсы и минусы в этом? Моя основная задача заключается в распознавании файлов cookie, но, поскольку мы принудительно используем SSL при входе в систему, cookie-файлы сеанса в любом случае будут записываться в домен SSL. Моя главная забота о людях, к которым можно обратиться, https://example.comкогда мы запускаем сайт https://www.example.comи т. Д.

_{Другой вопрос будет: «Должен ли я переписать тех, кто попадает на сайт без www, на сайт WWW?}

— Марк Хендерсон
источник

В зависимости от того, у кого вы покупаете сертификат, они могут предоставить вам бесплатный домен в качестве альтернативного имени субъекта. Так что, если вы покупаете, www.example.comвы можете получить сертификат, который охватывает как www.example.comи example.com.

— Майкл Хэмптон

Ответы:

Я обычно иду, secure.domain.comпотому что это дает мне больше гибкости, насколько администрация. Например, я могу разместить этот субдомен на другом сервере, за каким-то лучшим механизмом IDS / IPS, и, возможно, подключить его к частной сети, которую я не хочу, чтобы веб-серверы касались.

Это хорошее место для парковки многофункциональных вещей, таких как:

secure.domain.com/checkout/
secure.domain.com/portal/
secure.domain.com/support/

... так далее.

— Тим Пост
источник

Были ли у вас проблемы с печеньем? Например, если файл cookie создан на сайте www.example.com, можете ли вы прочитать его с secure.example.com?

— Марк Хендерсон

@Farseeker: Вы можете установить cookie для .example.com(или example.com, что то же самое), и он будет работать как для www.example.com, так и для secure.example.com (с недостатком, что он всегда будет отправляться на оба поддоменов) , Вот моя любимая страница на эту тему: code.google.com/p/browsersec/wiki/…

— Крис Лерчер,

@Farseeker - Да, куки распространяются на субдомены, однако, если вы хоть немного умны, это не проблема. Например, cookie-> logged_in / connection-> ssl и т. Д. Это не похоже на CDN, где их отсутствие выгодно, их просто нужно планировать и контролировать.

— Тим Пост

@ Крис, я не знал , вы могли бы установить кук для example.comот www.example.com- я должен буду смотреть на это. Спасибо.

— Марк Хендерсон

С помощью этого решения вы также можете запретить secure.example.com в своем файле robots.txt. Так что +1. :-)

— fwaechter

Лично я просто использую сертификат SSL Plus от DigiCert с сайтами example.com и www.example.com. Как и в вашем другом вопросе, я все равно отправлю всех на www.example.com, потому что это облегчит жизнь в дальнейшем. Делая это сейчас, вы также сможете позже использовать что-то вроде secure.example.com.

Я обычно добавляю код, чтобы определить, используют ли пользователи HTTP, когда они должны использовать HTTPS, и перенаправить их. Я нахожу, что это обычно происходит только при входе в систему, но в зависимости от сайта это может происходить и в других случаях.

— Дэррил Хейн
источник