Позволяет зашифровать с помощью обратного прокси-сервера nginx
Введение
У меня есть сервер разработки (в настоящее время работает Ubuntu 14.04 LTS), который я уже некоторое время использую для размещения различных инструментов разработки на разных портах. Поскольку порты может быть трудно запомнить, я решил использовать порт 80 для всех своих служб и выполнять внутреннюю переадресацию портов на основе имени хоста.
Вместо того, чтобы писать domain.com:5432, я могу просто получить к нему доступ через sub.domain.com
Например, приложение X, которое использует порт 7547 и работает на sub.domain.com, имеет следующее Конфигурация nginx:
upstream sub {
server 127.0.0.1:7547;
}
server {
listen 80;
server_name sub.domain.com www.sub.domain.com;
access_log /var/log/nginx/sub.log combined;
location / {
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:7547;
proxy_set_header Authorization "";
}
}
Вопрос
Учитывая текущую структуру конфигурации, которую я выбрал, можно ли использовать letsencrypt и запускать различные службы под https?
Да, вы можете отправлять запросы прокси-сервера nginx к HTTP-серверам, а затем отвечать клиентам по HTTPS. При этом вы должны быть уверены, что соединение с прокси-сервером nginx <-> вряд ли будет обнаружено кем-либо, кто является вашим предполагаемым злоумышленником. Достаточно безопасные подходы могут включать:
- проксирование на тот же хост (как и вы)
- проксирование на другие хосты за вашим брандмауэром
Проксирование на другой хост в общедоступном Интернете маловероятно
Ниже приведены инструкции по получению сертификата Let's Encrypt с использованием того же веб-сервера, который вы используете в качестве прокси.
Запрос исходного сертификата у Let's Encrypt
Измените свой сервер , чтобы разрешить обслуживание подкаталога .well-known из локального каталога, например:
server {
listen 80;
server_name sub.domain.com www.sub.domain.com;
[…]
location /.well-known {
alias /var/www/sub.domain.com/.well-known;
}
location / {
# proxy commands go here
[…]
}
}
http://sub.domain.com/.well-known - это место, где Let's Encrypt серверы будут искать ответы на возникающие проблемы.
Затем вы можете использовать клиент certbot , чтобы запросить сертификат у Let's Encrypt с помощью подключаемого модуля webroot (от имени пользователя root):
certbot certonly --webroot -w /var/www/sub.domain.com/ -d sub.domain.com -d www.sub.domain.com
Ваш ключ, сертификат,и цепочка сертификатов теперь будет установлена в /etc/letsencrypt/live/sub.domain.com/
Настройка nginx для использования вашего сертификата
Сначала создайте новое предложение сервера, например:
server {
listen 443 ssl;
# if you wish, you can use the below line for listen instead
# which enables HTTP/2
# requires nginx version >= 1.9.5
# listen 443 ssl http2;
server_name sub.domain.com www.sub.domain.com;
ssl_certificate /etc/letsencrypt/live/sub.domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/sub.domain.com/privkey.pem;
# Turn on OCSP stapling as recommended at
# https://community.letsencrypt.org/t/integration-guide/13123
# requires nginx version >= 1.3.7
ssl_stapling on;
ssl_stapling_verify on;
# Uncomment this line only after testing in browsers,
# as it commits you to continuing to serve your site over HTTPS
# in future
# add_header Strict-Transport-Security "max-age=31536000";
access_log /var/log/nginx/sub.log combined;
# maintain the .well-known directory alias for renewals
location /.well-known {
alias /var/www/sub.domain.com/.well-known;
}
location / {
# proxy commands go here as in your port 80 configuration
[…]
}
}
Перезагрузите nginx :
service nginx reload
Убедитесь, что HTTPS теперь работает, посетив https://sub.domain.com и https://www.sub.domain.com в своем браузере (и любой другие браузеры, которые вы хотите поддерживать) и убедитесь, что они не сообщают об ошибках сертификатов.
Рекомендуется: также просмотрите raymii.org: Strong SSL Security на nginx и проверьте свою конфигурацию в SSL Labs .
(рекомендуется) Перенаправьте HTTP-запросы на HTTPS
После того, как вы подтвердите, что ваш сайт работает с https: // версии URL-адреса, вместо того, чтобы предоставлять некоторым пользователям небезопасный контент из-за того, что они перешли на http://sub.domain.com , перенаправьте их на HTTPS-версию сайта.
Замените всю вашу страницу целиком. порт 80 сервер предложение с:
server {
listen 80;
server_name sub.domain.com www.sub.domain.com;
rewrite ^ https://$host$request_uri? permanent;
}
Вы также должны теперь раскомментировать эту строку в конфигурации порта 443, чтобы браузеры не забывали даже не пробовать HTTP-версию сайта:
add_header Strict-Transport-Security "max-age=31536000";
Автоматически обновлять свой сертификат
Вы можете использовать эту команду (как root), чтобы обновить все сертификаты, известные certbot, и перезагрузить nginx, используя новый сертификат (который будет иметь тот же путь, что и ваш существующий сертификат):
certbot renew --renew-hook "service nginx reload"
certbot будет пытаться обновить только сертификаты, которые старше 60 дней, поэтому безопасно (и рекомендуется!) запускать эту команду очень регулярно [1 140164], и автоматически, если это вообще возможно. Например, вы можете поместить следующую команду в / etc / crontab :
# at 4:47am/pm, renew all Let's Encrypt certificates over 60 days old
47 4,16 * * * root certbot renew --quiet --renew-hook "service nginx reload"
Вы можете протестировать продление с помощью любого пробного запуска, который свяжется с промежуточными серверами Let's Encrypt, чтобы провести реальную проверку связи с вашим доменом , но не будет сохранять полученные сертификаты:
certbot --dry-run renew
Или вы можете принудительно выполнить раннее обновление с помощью:
certbot renew --force-renew --renew-hook "service nginx reload"
Примечание: вы можете выполнить пробный запуск столько раз, сколько захотите, но настоящее продление подлежит Ограничения скорости Let's Encrypt .
Да, вы можете использовать nginx в качестве конечной точки https и взаимодействовать с бэкэндами через http. Например, моя конфигурация:
server {
server_name host;
listen 443 ssl;
...
location /svn/ {
auth_ldap off;
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_set_header X-Forwarded-Proto $scheme;
proxy_pass http://localhost:1080/svn/;
proxy_redirect http://localhost:1080/ https://host/;
}
...
}
Но, как я знаю, с помощью Let's encrypt вы должны указывать все поддомены при получении сертификата, и если это проблема, вы выбираете url https: // host / service вместо https://service.host