Sim, você pode ter solicitações de proxy nginx para servidores HTTP e, em seguida, responder aos clientes por HTTPS. Ao fazer isso, você deve ter certeza de que é improvável que a conexão nginx<->proxy seja detectada por quem quer que seja o invasor esperado. Abordagens suficientemente seguras podem incluir:

• proxy para o mesmo host (como você faz)
• proxy para outros hosts por trás de seu firewall

É improvável que o proxy para outro host na Internet pública seja seguro o suficiente.

Aqui estão as instruções para obter um certificado Let's Encrypt usando o mesmo servidor web que você está usando como proxy.

Solicitando seu certificado inicial da Let's Encrypt

Modifique sua servercláusula para permitir que o subdiretório .well-knownseja servido a partir de um diretório local, por exemplo:

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é onde os servidores Let's Encrypt irão buscar as respostas para os desafios que lança.

Você pode usar o cliente certbot para solicitar um certificado do Let's Encrypt usando o plug-in webroot (como root):

certbot certonly --webroot -w /var/www/sub.domain.com/ -d sub.domain.com -d www.sub.domain.com

Sua chave, certificado e cadeia de certificados agora serão instalados em/etc/letsencrypt/live/sub.domain.com/

Configurando o nginx para usar seu certificado

Primeiro crie uma nova cláusula de servidor como esta:

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
        […]
    }
}

Recarregue o nginx:

service nginx reload

Verifique se o HTTPS agora funciona visitando https://sub.domain.come https://www.sub.domain.comem seu navegador (e quaisquer outros navegadores que você deseja especificamente oferecer suporte) e verificando se eles não relatam erros de certificado.

Recomendado: revise também raymii.org: Strong SSL Security on nginx e teste sua configuração em SSL Labs .

(Recomendado) Redirecionar solicitações HTTP para HTTPS

Depois de confirmar que seu site funciona com a https://versão do URL, em vez de receber conteúdo inseguro de alguns usuários porque acessaram http://sub.domain.com, redirecione-os para a versão HTTPS do site.

serverSubstitua toda a cláusula da porta 80 por:

server {
    listen 80;
    server_name sub.domain.com www.sub.domain.com;
    rewrite     ^   https://$host$request_uri? permanent;
}

Você também deve agora descomentar esta linha na configuração da porta 443, para que os navegadores se lembrem de nem tentar a versão HTTP do site:

add_header Strict-Transport-Security "max-age=31536000";

Renove seu certificado automaticamente

Você pode usar este comando (como root) para renovar todos os certificados conhecidos pelo certbot e recarregar o nginx usando o novo certificado (que terá o mesmo caminho do seu certificado existente):

certbot renew --renew-hook "service nginx reload"

O certbot tentará apenas renovar os certificados com mais de 60 dias, portanto, é seguro (e recomendado!) Executar esse comando regularmente e automaticamente, se possível. Por exemplo, você poderia colocar o seguinte comando em /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"

Você pode testar as renovações com um teste, que entrará em contato com os servidores temporários da Let's Encrypt para fazer um teste real de contato com seu domínio, mas não armazenará os certificados resultantes:

certbot --dry-run renew

Ou você pode forçar uma renovação antecipada com:

certbot renew --force-renew --renew-hook "service nginx reload"

Observação: você pode testar quantas vezes quiser, mas as renovações reais estão sujeitas aos limites de taxa da Let's Encrypt .

Sim, você pode usar nginxcomo ponto final de https e cooperar com back-ends via http. Por exemplo minha configuração:

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/;
        }
...
}

Mas, como eu sei, com vamos criptografar, você deve apontar todos os subdomínios quando obter o certificado e, se isso for um problema, escolha url https://host/serviceem vez dehttps://service.host