Да, вы можете иметь прокси-запросы nginx к HTTP-серверам, а затем сами отвечать клиентам через HTTPS. При этом вы должны быть уверены, что соединение с прокси-сервером nginx <-> вряд ли будет обнаружено кем бы то ни было, кем бы вы ни были. Достаточно безопасные подходы мощь включают:

• проксирование на тот же хост (как и вы)
• проксирование на другие хосты за вашим брандмауэром

Проксирование на другой хост в общедоступном Интернете вряд ли будет достаточно безопасным.

Вот инструкции по получению сертификата Let's Encrypt с помощью того же веб-сервера, который вы используете в качестве прокси.

Запрос исходного сертификата у Let's Encrypt

Измените свой server предложение, чтобы разрешить подкаталог .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: сильная безопасность SSL на nginx и протестируйте свою конфигурацию на SSL Labs.

(Рекомендуется) Перенаправить HTTP-запросы на HTTPS

После того, как вы подтвердите, что ваш сайт работает с https:// версии URL-адреса, вместо того, чтобы некоторые пользователи обслуживали небезопасный контент, потому что они перешли на http://sub.domain.com, перенаправьте их на HTTPS-версию сайта.

Замените весь порт 80 server пункт с:

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 дней, поэтому запускать эту команду безопасно (и рекомендуется!) очень регулярно, и автоматически, если это возможно. Например, вы можете ввести следующую команду в /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