Сегодня я поиграю в капитана Очевидность и расскажу, как настроить SSL в nginx для отдельно взятого виртуального хоста.

Шучу. На самом деле я начну потихоньку описывать рецепты того, как облегчить связку nginx+apache. А для кого-то (дада, те кто использует php-fpm/php-fcgi) они станут полезными статьями по настройке nginx. Вообще статьи будут сводиться к тому, чтобы избавиться от необходимости загружать дополнительные модули в apache (которые достаточно неплохо повышают прожорливость апача по памяти под большой нагрузкой). Сегодня мы избавимся от mod_ssl (2-4 метра памяти на каждый worker в определенных условиях).

Немного предыстории. mod_ssl в апаче умеет всё. Ему, формально, уже больше 10 лет. Он состоит из костылей для обратной совместимости со старыми протоколами. 90% его функционала сегодня уже никому не требуются. Поэтому его использование бессмысленно в свете того, что есть nginx и поддержка ssl в нем. Мы попробуем облегчить страдания apache по работе с ssl. Зачем? Затем же, зачем apache убирают за nginx. Выставлять apache на 443м порту при том, что на 80м — nginx — глупо.

Подразумевается, что вы уже умеете настраивать nginx, знаете как сгенерировать сертификат или уже купили сертификат у регистратора. У вас должно быть в наличии следующее:
— nginx более или менее свежей версии (я это проделывал на 0.7)
— файл-ключ /var/www/certs/domain.ru.key (желательно, незапароленный, иначе нужно будет вводить пароль при каждом рестарте nginx. Небезопасно, но…. В общем сами решайте.)
— файл-сертификат /var/www/certs/domain.ru.crt от регистратора
— промежуточный сертификат /var/www/certs/domain.ru_bundle.crt от регистратора
или аналогичные самоподписанные файлы.

Я опишу 2 примера:
— первый — на 80 и 443м порту мы получим одинаковый сайт (вы же используете относительные ссылки в href и src, да?)
— второй — с принудительным редиректом с http на https
Оба варианта я пишу из расчета минимальных затрат ресурсов. Можно использовать переменную $scheme, пихать её в if, и если она http — то редиректить на https. Но когда в такую конструкцию вам начнут долбится 1к реквестов в секунду — мало не покажется.

Подготавливаем наш сертификат:
root@nginx-host:~# cat /var/www/certs/domain.ru.crt > /var/www/certs/domain.ru-bundled.crt
root@nginx-host:~# cat /var/www/certs/domain.ru_bundle.crt >> /var/www/certs/domain.ru-bundled.crt
Теперь nginx сможет корректно работать с нашим подписанным сертификатом.

Первый вариант:
Создаём файл /etc/nginx/sites-available/10-domain.ru.conf
Пишем в него следующее:
server {
listen 80;
listen 443 ssl;
server_name domain.ru www.domain.ru;
ssl_certificate /var/www/certs/domain.ru-bundled.crt;
ssl_certificate_key /var/www/certs/domain.ru.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
root /var/www/domain.ru;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:81;
}
... other configuration;
}

Немного пояснений. По нашему конфигу nginx будет слушать 80й порт на всех интерфейсах по http, 443й — по https. server_name — указываем Host-ы, которые обрабатывать в этом server. ssl_certificate — указываем путь до сертификата, который мы подготовили выше. ssl_certificate_key — указываем путь до ключа. Не забывайте, что сертификат и ключ нужно хранить в безопасном месте. Директивами ssl_session_* мы снижаем нагрузку — новая ssl сессия будет устанавливаться раз в 10 минут. Дальше мы проксируем все запросы в apache на locahost, который слушает 81й порт по http. Ну и потом пишем всё остальное (locations со статикой и т.д. и т.п.).
Во всей этой конструкции не стоит забывать, что глюпый вындовзь ХыРы не умеет SNI совсем, плюс SNI не умеют некоторые версии браузеров на висте и семерке. Поэтому пока что не следует на одном IP вешать несколько ssl-сайтов — ХР пойдет за сертификатом для первого. Можно использовать listen ip1:443 ssl; listen ip2:443 ssl; для размещения нескольких сайтов с ssl. Другого варианта пока что нет.
Ещё вам следует проверить, что ваш сайт не содержит в src ссылок вида http://domain.ru/blah — тогда браузеры клиентов будут жаловаться на «небезопасное содержимое на странице».
Вот, вроде как-то так.

Ну и опишем второй вариант (с редиректом) с минимальными затратами ресурсов:
server {
listen 80;
server_name domain.ru www.domain.ru;
rewrite ^/(.*) https://domain.ru/$1 permanent;
# только не забывайте, что query_string в nginx не попадает в uri. А rewrite обрабатывает только uri = не обрабатывает query_string (то, что в ссылке после символа "?")
}

server {
listen 443;
ssl on;
server_name domain.ru www.domain.ru;
ssl_certificate /var/www/certs/domain.ru-bundled.crt;
ssl_certificate_key /var/www/certs/domain.ru.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
root /var/www/domain.ru;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:81;
}
... other configuration;
}

В общем-то сложное позади. Делаем симлинк:
root@nginx-host:~# ln -s /etc/nginx/sites-available/10-domain.ru.conf /etc/nginx/sites-enabled/10-domain.ru.conf
рестартим nginx (именно restart, а не reload):
root@nginx-host:~# /etc/init.d/nginx restart

Теперь радостно выключаем mod_ssl у apache (a2dismod ssl, вроде), удаляем все куски конфигурации.