Скажем, я хочу, чтобы два защищенных сайта работали с одного компьютера, использующего сервер Apache:
1. https://example.com
2. https://example.ca
Можно ли использовать порт 443 для обоих вышеуказанных сайтов?
Как уже объяснялось, SSL-соединение создается до того, как какие-либо фактические данные будут отправлены через соединение, поэтому Apache не может предоставить разные SSL-сертификаты для каждого из ваших виртуальных сайтов, поскольку он не знает, какое имя сервера запрашивается. Это означает, что независимо от того, какое имя сервера фактически запрошено (в данном случае «mysite.com» или «mysite.ca»), Apache ответит сертификатом SSL по умолчанию, который он настроил для использования. Это может быть объявлено внутри "default" 443 VirtualHost или в глобальной конфигурации Apache.
С точки зрения удобства использования это означает, что вы можете разместить оба сайта с одного и того же хоста apache и IP, но пользователи получат предупреждение при принятии сертификата, сообщающее им, что сертификат предназначен для неправильного сайта. Единственный способ обойти это - иметь два разных IP-адреса и настроить виртуальные хосты таким образом, чтобы каждый из них прослушивал разные адреса. (Обязательно обновите DNS соответствующим образом)
После обмена сертификатами будут применяться обычные правила VirtualHost, и вы можете фактически размещать различный контент на каждом имени сервера, если это то, что вы хотите сделать.
Эти примеры немного грубые, вы захотите проконсультироваться с официальной документацией apache по поводу точных имен параметров для настройки виртуальных хостов и настройки ssl, если вы еще не знаете основ.
Пример: два сервера на разных IP-адресах с разными корнями документов, каждый из которых представляет правильный сертификат.
<VirtualHost 1.1.1.1:443>
ServerName mysite.com
DocumentRoot /var/www/comroot
SSLEngine On
// Configure certificate for mysite.com
</VirtualHost>
<VirtualHost 2.2.2.2:443>
ServerName mysite.ca
DocumentRoot /var/www/caroot
SSLEngine On
// Configure certificate for mysite.ca
</VirtualHost>
Пример: два сервера на одном IP-адресе используют неправильный сертификат (настроенный в другом месте), но по-прежнему обслуживают разный контент на основе имени сервера.
<VirtualHost *:443>
ServerName mysite.com
DocumentRoot /var/www/comroot
SSLEngine On
</VirtualHost>
<VirtualHost *:443>
ServerName mysite.ca
DocumentRoot /var/www/caroot
SSLEngine On
</VirtualHost>
Вы можете запустить несколько сайтов SSL с одного IP-адреса, используя несколько методов, каждый из которых имеет свои недостатки.
Первый способ - получить SSL-сертификат, охватывающий оба сайта. Идея здесь состоит в том, чтобы иметь единый сертификат SSL, охватывающий все домены, которые вы хотите разместить с одного IP-адреса. Вы можете сделать это с помощью подстановочного сертификата, охватывающего оба домена, или использовать альтернативное имя субъекта.
Сертификаты с подстановочными знаками будут иметь вид * .example.com, который будет охватывать www.example.com, mail.example.com и support.example.com. Есть ряд проблем с сертификатами с подстановочными знаками. Во-первых, каждое имя хоста должно иметь общий домен, например с * .example.com вы можете иметь www.example.com, но не www.example.org. Во-вторых, у вас не может быть более одного поддомена, т.е. у вас может быть www.example.com, но не www.eu.example.com. Это может работать в более ранних версиях Firefox (<= 3.0), но не работает в 3.5 или любой версии Internet Explorer. В-третьих, групповые сертификаты значительно дороже обычных сертификатов, если вы хотите, чтобы они были подписаны корневым центром сертификации.
Альтернативное имя субъекта - это метод использования расширения сертификатов X509, в котором перечислены альтернативные имена хостов, действительные для этого сертификата. Он включает в себя добавление к сертификату поля «subjectAltName», в котором перечислены все дополнительные хосты, на которые должен распространяться сертификат. Это должно работать в большинстве браузеров; конечно, каждый современный основной браузер. Обратной стороной этого метода является то, что вам нужно указать все домены на сервере, которые будут использовать SSL. Возможно, вы не хотите, чтобы эта информация была общедоступной. Вероятно, вы не хотите, чтобы несвязанные домены указывались в одном сертификате. Также может быть сложно добавить дополнительные домены позже к вашему сертификату.
Второй подход заключается в использовании так называемого SNI (Server Name Indication), которое является расширением TLS, которое решает проблему курицы и яйца, заключающуюся в том, что вы не знаете, какой сертификат отправить клиенту, поскольку клиент еще не отправил заголовок Host :. В рамках согласования TLS клиент отправляет требуемое имя хоста в качестве одного из вариантов. Единственным недостатком этого является поддержка клиентов и серверов. Поддержка в браузерах обычно лучше, чем в серверах. Firefox поддерживает его с 2.0. Internet Explorer поддерживает его начиная с 7, но только в Vista или более поздних версиях. Chrome поддерживает его только в Vista или более поздних версиях. Поддерживаются Opera 8 и Safari 8.2.1. Другие браузеры могут не поддерживать его.
Самая большая проблема, препятствующая внедрению, - это поддержка серверов. До недавнего времени ни один из двух основных веб-серверов не поддерживал его. Apache получил поддержку SNI с версии 2.2.12, выпущенной в июле 2009 года. На момент написания IIS не поддерживает SNI ни в одной версии. nginx, lighttpd и Cherokee поддерживают SNI.
Забегая вперед, SNI - лучший метод решения проблемы виртуального хостинга HTTPS на основе имен, но поддержка может быть неоднородной в течение года или двух. Если в ближайшем будущем вам необходимо без проблем организовать виртуальный хостинг HTTPS, виртуальный хостинг на основе IP - единственный вариант.
Только если сайты находятся на собственных IP-адресах.
SSL-соединение происходит до того, как клиент запрашивает веб-сайт, поэтому, когда SSL-соединение установлено, сервер не знает, что клиент собирается запросить.
Например, если вы представляете сертификат .com SSL, клиенты, запрашивающие .ca, будут недовольны.
Решение состоит в том, чтобы настроить второй IP-адрес для .ca и настроить отдельный экземпляр веб-сервера для прослушивания этого IP-адреса с помощью SSL-сертификата .ca.
Да, если вы назначаете машине несколько IP-адресов. По одному для каждого SSL-сертификата / домена. Как правило, вам понадобится уникальный IP-адрес для каждого SSL-сервера. Windows, Linux, BSD и Solaris поддерживают несколько IP-адресов на одном сетевом адаптере, или вы можете добавить дополнительные сетевые адаптеры или многопортовые сетевые адаптеры. В среде веб-обслуживания довольно часто назначают 10-20 IP-адресов на машину / сетевую карту.
Другие варианты SSL, которые не будут работать с вашими критериями.
SSL-сертификаты с подстановочными знаками могут содержать множество поддоменов при условии, что домен второго уровня один и тот же, обычно используемый для массового виртуального хостинга.
Общие сертификаты SSL могут использоваться на нескольких машинах в одном домене, как правило, для переключения при отказе и балансировки нагрузки.
Хорошие ответы, однако, использование одного HTTP-сервера для размещения обоих сайтов имеет SPOF, то есть один раз экземпляр сервера apache. Если этот сервер apache выйдет из строя, оба сайта станут недоступны. Как насчет двухпортовой карты Ethernet? или, что еще лучше, с помощью виртуализации. Я большой поклонник виртуализации, такой как xen или openVZ. Однако вам нужно будет потратить немного денег на оборудование.
Уважаемые пользователи, пожалуйста, используйте haproxy перед вашим apache2, в этом случае вы сможете перенаправить другой домен на один и тот же сервер apache на другой порт ssl, но вам необходимо настроить буксировку другого сайта под сайтом, включенным с такими портами, как 443 и 8443, которые вы можно скопировать мимо первого ssl-сайта и изменить только порт и псевдоним домена, вы найдете помощь в отношении активации apache2 ssl, также вам нужно определить файл hosts с 2 ips, например 127.0.1.1 web-ssl1 127.0.2.1 web-ssl2