SSL vhost на связке nginx+apache

[NeverM]

Здравствуйте, имеется сервер с nginx'ом 0.7 выступающим в роли front-end'а и apache 2.2 выступающий в роли back-end'а Слышал что на апаче можно реализовать ssl для каждого виртуального хоста (vhost) на одном ip, тоесть сделать свой сертификат для каждого vhost'а. Можно ли провернуть такое на связке apache+nginx или nginx не сможет проксировать сертификаты на back-end?

[sash-kan]

восстановленное содержимое ответа уважаемого Frank

http://www.ourshop.org/resources/ssl.html

About IP addresses and SSL: Though your SSL certificate is bound to your fully qualified domain name (encrypted into the certificate request and registerd when you purchase your certificate) web servers link the certificate to the IP address. The result is that if you attempt to have more than one SSL certificate associated with the same IP address (in the case of virtual hosting) you may get undesired results.

Typically the certificate that will be used for the IP address, no matter which domain you attempt to access, will be the first one in the web server's configuration file. This is important to note for the web site owner because many of the budget and free web hosting services do not give you your own IP address.

Getting a unique IP address for an SSL certificate is usually the main factor in extra pricing for secure hosting on the budget web hosts and can often increase your pricing past that of a full service host. Even with full service web hosts if you need seperate certificates for multiple domains you will often need to open individual accounts for each so that they have their own IP addresses. On the other hand, since the certificate itself is not linked to the IP address you can usually move the certificate from one web host to another (as long as you have a unique IP address at the new host).

Our Detailed How does SSL work pages include additional IP address notes in the sidebars.

В первом приближении можно считать, что SSL layer работает с ip адресом сервера и никак не касается доменного имени, а apache работает с доменным именем и никак не касается SSL сертификатов. Поэтому на одном айпи может быть только одно доменное имя по https.

[moog]

mod_gnutls позволяет использовать отдельный сертификат для каждого vhost.

[Frank]

mod_gnutls позволяет использовать отдельный сертификат для каждого vhost.

Судя по http://en.wikipedia.org/wiki/Server_Name_Indication у клиентов с Windows XP а так же в браузере Konqueror оно работать не будет.

[moog]

Проверял на Vista (firefox) - работает. Konqueror также нормально работает.

[NeverM]

Как реализовать подобное на апаче я знаю, то что с этим будут работать не все браузеры меня не пугает. Интересует можно ли реализовать это на связке nginx+apache тоесть чтобы клиент обращался к nginx'у(nginx слушает 443 порт), nginx к апачау, апач опять к nginx'у и nginx к клиенту, или nginx в любом случае не сможет проксировать сертификаты к апачу?
Простите если не совсем понятно выражаюсь

[Olden Gremlin]

Как реализовать подобное на апаче я знаю, то что с этим будут работать не все браузеры меня не пугает. Интересует можно ли реализовать это на связке nginx+apache тоесть чтобы клиент обращался к nginx'у(nginx слушает 443 порт), nginx к апачау, апач опять к nginx'у и nginx к клиенту, или nginx в любом случае не сможет проксировать сертификаты к апачу?
Простите если не совсем понятно выражаюсь

А зачем такой огород-то городить? Или я не совсем правильно понял вопрос. Но...

nginx на каждый вхост может иметь свои настройки по ssl:

Код: Выделить всё

server {
... skip...
    listen xxx.xxx.xxx.xxx:443;
    server_name foo.com;
... skip...
    ssl on;
    ssl_certificate     /etc/nginx/ssl/foo.com.pem;
    ssl_certificate_key /etc/nginx/ssl/foo.com.key;
    ssl_session_timeout 5m;
    ssl_protocols SSLv3 TLSv1;
    ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:-SSLv2:+SSLv3::+EXP;
    ssl_prefer_server_ciphers on;
... skip...
    location / {
        access_log          /var/log/nginx/access-backend.foo.com.log;
        proxy_set_header    Host  $host;
        proxy_set_header    X-Real-IP       $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass          http://127.0.0.1:60080;
        proxy_redirect      off;
        proxy_read_timeout  500;
        proxy_next_upstream error;
    }
... skip...
}

"Индейцу", при этом, вовсе необязательно уметь поддерживать ssl, так как за эту часть работы уже отвечает nginx. На порту локалхоста 60080 "висит" самый обычный http сервер. Собственно в итоге получаем набор виртуальных серверов каждый из которых имеет свои сертификаты...
Или тебе критически важно чтобы именно apach устанавливал с клиентом ssl-соединение?

[danger08]

nginx на каждый вхост может иметь свои настройки по ssl:

Код: Выделить всё

server {
... skip...
    listen xxx.xxx.xxx.xxx:443;
    server_name foo.com;
... skip...
}

Все упирается туда же - для ssl vhost-а, по хорошему, нужен отдельный ip.

Топикстартеру совет - купите нужное количество IP-адресов и проблема исчезнет сама собой (настроите vhost-ы по ip, как пишет Olden Gremlin). И не надо огород городить, с поддержкой нескольких сертификатов для одного адреса.

[Olden Gremlin]

nginx на каждый вхост может иметь свои настройки по ssl:

Код: Выделить всё

server {
... skip...
    listen xxx.xxx.xxx.xxx:443;
    server_name foo.com;
... skip...
}

Все упирается туда же - для ssl vhost-а, по хорошему, нужен отдельный ip.

Топикстартеру совет - купите нужное количество IP-адресов и проблема исчезнет сама собой (настроите vhost-ы по ip, как пишет Olden Gremlin). И не надо огород городить, с поддержкой нескольких сертификатов для одного адреса.

Секундочку, я конечно же не проверял, но... Кто мешает nginx'у слушать 443 порт и при этом реагировать на нужную секцию server, а следовательно и подставлять нужные сертификаты, по server_name? Ведь для 80-го порта именно так и организуются иртхосты, так что-же мешает это делать для 443-го? Религия?
А вот proxy_pass для разных server_name можно куда душе угодно направить...
Так что никто никуда имхо не упирается...

[danger08]

Кто мешает nginx'у слушать 443 порт и при этом реагировать на нужную секцию server,

Если там будут разные IP, то ничего не мешает. То же самое, справедливо и для apache.

а следовательно и подставлять нужные сертификаты, по server_name?

Дело в том, что до разбора полей http-запроса дело доходит только после установки защищенного соединения. Т.е., если вкратце, последовательность действий такова:
- при обращении клиента на 443/tcp на определенный IP-адрес хоста веб-сервер отдает сертификат, и устанавливает с клиентом защищенное соединение.
- в рамках установленного защищенного соединения клиент делает HTTP-запрос, вот здесь только и появляется пресловутый server_name.

Поэтому и используют привязку "IP-сертификат", чтобы однозначно сопоставить ip-based vhosts и сертификаты веб-сервера (на каждый IP по сертификату). Посмотрите, выше sash-kan писал.

Ведь для 80-го порта именно так и организуются иртхосты, так что-же мешает это делать для 443-го?

Для 80 уже с первого запроса клиента понятно, к какому виртуальному хосту он обращается. С 443, видите ли, сперва надо отдать какой-то сертификат, а потом в рамках сессии парсить запрос, куда реально ( HTTP/1.1 поле Host: xxx ) клиент хочет обратиться.

[Olden Gremlin]

Ведь для 80-го порта именно так и организуются иртхосты, так что-же мешает это делать для 443-го?

Для 80 уже с первого запроса клиента понятно, к какому виртуальному хосту он обращается. С 443, видите ли, сперва надо отдать какой-то сертификат, а потом в рамках сессии парсить запрос, куда реально ( HTTP/1.1 поле Host: xxx ) клиент хочет обратиться.

Уже пообщался с людьми... Осознал свою ошибку в рассуждениях...
Ну, разве что https для разных виртуалхостов на разные порты вешать... Этого ведь тоже пока никто не запрещал Хотя извратно это больно...

[danger08]

Да нет, проще IP-шников накупить на сервер с nginx-ом и сделать "ip based vhosts".
А там уж настроить проксирование на backend с apache, как душе угодно.

[sash-kan]

Посмотрите, выше sash-kan писал.

это не я написал. я всего лишь восстановил содержимое утраченного поста. автор поста: Frank

чтобы не вмешиваться «грязными ручками» в работу движка, автора поста не стал менять, а ограничился припиской в начале поста.

[sash-kan]

кстати: http://sysoev.ru/nginx/docs/http/ngx_http_ssl_module.html
всё подробно разжёвано.