Certbot: Suporte HTTP2 no plugin Nginx

De #3640

Atualmente, o plugin nginx adiciona:
listen 443 ssl; # managed by Certbot

Uma opção para HTTP 2 seria boa, especificando o sinalizador --http2 ou apenas verificando a compatibilidade do nginx.

listen 443 ssl http2;
listen [::]:443 ssl http2;

Algum progresso no assunto? Caso eu adicione http2 manualmente, ele será eliminado na renovação?

Não. Renovar seu certificado com certbot renew não mudará essas linhas.

Acabei de verificar meu problema sobre isso e vi que foi fechado há 22 horas.

Acho que a notícia de que o recurso foi adicionado seria publicada aqui, em primeiro lugar?

Surpreendentemente, rgrep -il http2 certbot-nginx não retorna nada. Portanto, ainda não foi implementado.

@benqzq , sim. Qualquer notícia de progresso sobre isso será adicionada aqui. Os tópicos no fórum da comunidade Let's Encrypt são fechados automaticamente após 30 dias sem atividade.

Sugiro adicionar um sinalizador --lhttp (o l significa "mais recente") para não bloqueá-lo em uma versão específica do http. Embora l possa ser confuso (talvez --LH ?).

@benqzq Por que tornar as coisas simples complexas? --http2 é autoexplicativo

• o comportamento padrão é http2 desativado
• --http2 ativa o http2

Às vezes, é o que você precisa, pelo menos um pouco, mas de qualquer forma, estou pronto para uma notação geral. Ou é bom IMHO ( --http2 ou uma notação geral como as que sugeri).

Esta é uma ferramenta tão importante, gostaria que alguém a adicionasse já...

Apenas observando como eu automatizo isso até que um argumento esteja disponível:

sed -i "s/listen 443 ssl;/listen 443 ssl http2;/" /etc/nginx/sites-available/$domain.conf

Ainda não há como habilitar o http2 com o certbot? Alguém tem uma solução alternativa?

@KyleTryon Eu dei minha solução alternativa sed acima, mas parece que ainda não há uma maneira oficial. Eu não consigo entender isso.

@bendqh Esse alguém pode ser você!

Surpreendentemente, esse recurso ainda não foi adicionado. :-)

@yw662 , você está interessado em enviar um pull request para isso?

É fácil de contornar então……você sabe, se eu tiver tempo para isso. Eu acho que esse é o problema. A solução é fácil, mas alterar o script não é tão fácil :-).

Bolacha para 2019.

0 0,12 * * * certbot renew --quiet
1 0,12 * * * sed -i "s/listen 443 ssl;/listen 443 ssl http2;/" /etc/nginx/sites-available/default
2 0,12 * * * sed -i "s/443 ssl ipv6only=on;/443 ssl http2 ipv6only=on;/" /etc/nginx/sites-available/default
3 0,12 * * * systemctl nginx reload

--http2 parece muito mais fácil...

@rowan-OzRunways Este https://github.com/certbot/certbot/issues/3646#issuecomment -323814774 não é válido para você? Basta anexar http2 à mão uma vez e não deve ser tocado na renovação .

Hmm, pensei que tivesse resolvido. Ficou claro uma vez, mas pode ter sido certbot-auto Obrigado, vou verificar.

:+1: :+1: :+1: Colisão
É meu aniversário por favor adicione isso obrigado

É incrível quantos desenvolvedores confiam na configuração ambígua (automatizada) em vez de solicitar manualmente o certificado e adaptar um bloco de servidor Nginx às suas necessidades...

o comportamento padrão é http2 desativado
--http2 ativa o http2

Esta é uma má ideia porque se transformará em ANOS de tutoriais on-line copiados e colados que assumem que HTTP/2 não é suportado por padrão, o que inevitavelmente será eventualmente (e depois HTTP/3).... se houver, o inverso pode fazer mais sentido, para desabilitar HTTP/2 por sinalizador, etc. Não há razão para adicionar sinalizadores de comando rapidamente relevantes se você estiver confiando na automação de configuração "burra".

A "solução alternativa" está solicitando manualmente o certificado:

certbot certonly --noninteractive --agree-tos --expand -m ${SSL_EMAIL} -d ${SITE_DOMAIN_ONE} -d ${SITE_DOMAIN_TWO} --webroot -w /var/www/html/

Ref: https://github.com/littlebizzy/slickstack/blob/master/ss-encrypt.txt

...e, em seguida, usando um bloco de servidor Nginx personalizado, por exemplo:

server {
listen                 443 ssl http2;
listen                 [::]:443 ssl http2 ipv6only=on;
server_name            @DOMAIN;
    if ($http_host != "@DOMAIN") {
        return 301            $scheme://@DOMAIN$request_uri;
    }

Ref: https://github.com/littlebizzy/slickstack/blob/master/nginx/default-single-site.txt
Ref: https://github.com/littlebizzy/slickstack/blob/master/nginx/nginx-conf.txt

Nosso plugin nginx atualmente não suporta a ativação do suporte HTTP/2 mesmo com um sinalizador --http2 . Isso é o que está sendo rastreado pelo problema.

Quanto ao nosso comportamento padrão, o que fizemos com sinalizadores como --redirect no passado foi implementar inicialmente o suporte oculto atrás de um sinalizador e incentivar nossos usuários a experimentá-lo. Depois de ter sido bem testado, podemos olhar para torná-lo o comportamento padrão para todos os usuários depois de ter certeza de que isso não quebrará (m) nenhuma configuração.

@jessuppi

É incrível quantos desenvolvedores confiam na configuração ambígua (automatizada) em vez de solicitar manualmente o certificado e adaptar um bloco de servidor Nginx às suas necessidades...

Você perde completamente o ponto. Claro que você pode fazer isso sozinho, mas há uma funcionalidade que vem com o cliente certbot que deve ser melhorada. Se você deve ou não permitir que o certbot configure seu servidor web está completamente fora do escopo deste problema.

Esta edição já tem 4 anos . Eu não acho que as pessoas se importam muito se eles teriam que usar um sinalizador --http2 ou --no-http2 , desde que o certbot fizesse isso automaticamente para nós.

@bmw por que há um atraso tão grande em algo que deveria ser relativamente simples - em comparação com todas as grandes mudanças que já foram implementadas nos últimos 4 anos? Certamente, a equipe do certbot deve concordar que o suporte adequado às versões mais recentes do HTTP2 também é importante...

Na verdade, existe um PR aberto: https://github.com/certbot/certbot/pull/7113

@bmw por que há um atraso tão longo em algo que deveria ser relativamente simples

Porque há muitos problemas com o Certbot e somos uma equipe pequena, então temos que priorizar as coisas. Concordo que isso tem valor, só não conseguimos chegar a isso ainda.

Adicionarei um rótulo de prioridade a este problema para que possamos vê-lo mais facilmente ao procurar novos projetos no futuro.

Olá. Presumo que, mesmo que seja fornecida uma correção para que o certbot suporte a configuração http2 NGINX, isso não corrigirá o fato de que o Boundler ainda não poderá executar verificações de webroot em conexões HTTP/2, certo? cf. esse link

Isso é sobre http2 em portas não criptografadas. Não é realmente um problema aqui. Queremos apenas a opção http2 adicionada às diretivas listen na porta 443 com criptografia.

@cperrin88 Claro, mas algo a ter em mente é que o NGINX não é capaz de realizar uma atualização do protocolo HTTP/1.1 -> HTTP/2 h2c , portanto, ao usar a validação webroot, Boundler, o servidor usado pelo let'sencrypt para executar a troca de desafio, só pode assumir que o servidor fala HTTP/1.1 e reclama com o erro: "Servidor está falando HTTP/2 sobre HTTP" caso contrário.

Então isso é algo para se ter em mente quando um patch para esse problema ganhar vida IMHO :)

Essa alteração não deve adicionar http2 a portas não criptografadas de qualquer maneira. Mas devemos ter isso em mente.