Certbot: Nginx 플러그인에서 HTTP2 지원

#3640에서

현재 nginx 플러그인은 다음을 추가합니다.
listen 443 ssl; # managed by Certbot

HTTP 2에 대한 옵션은 --http2 플래그를 지정하거나 nginx의 호환성을 확인하는 것이 좋습니다.

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

문제에 진전이 있습니까? http2 를 직접 추가하면 갱신 시 지워지나요?

아니요 certbot renew 로 인증서를 갱신해도 이 행은 변경되지 않습니다.

이것에 관한 내 문제를 확인하고 22시간 전에 문을 닫았습니다.

기능이 추가되었다는 소식이 가장 먼저 여기에 게시될 것 같은데요?

놀랍게도 rgrep -il http2 certbot-nginx 는 아무 것도 반환하지 않습니다. 그래서 아직 시행되지 않고 있습니다.

@benqzq 네. 이에 대한 모든 진행 소식이 여기에 추가됩니다. Let's Encrypt 커뮤니티 포럼의 주제는 30일 동안 활동이 없으면 자동으로 닫힙니다.

--lhttp 플래그를 추가하는 것이 좋습니다( l 는 "최신"을 의미함). 그러면 특정 버전의 http에 고정되지 않습니다. l 가 혼란스러울 수 있지만(아마도 --LH ?).

@benqzq 간단한 것을 복잡하게 만드는 이유는 무엇입니까? --http2 은(는) 자명합니다.

• 기본 동작은 http2 꺼짐입니다.
• --http2는 http2를 켭니다.

때로는 최소한 필요한 것이지만 어쨌든 나는 일반적인 표기법에 모두 동의합니다. 둘 중 하나는 좋은 IMHO입니다( --http2 또는 내가 제안한 일반 표기법).

이것은 매우 중요한 도구입니다. 누군가가 이미 추가해 주었으면 하는 바램입니다...

인수를 사용할 수 있을 때까지 자동화하는 방법:

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

certbot으로 http2를 활성화할 수 있는 방법이 아직 없나요? 누구든지 해결 방법이 있습니까?

@KyleTryon 위에서 sed 해결 방법을 제공했지만 아직 공식적인 방법이 없는 것 같습니다. 나는 그것을 이해할 수 없다.

@bendqh 누군가가 당신일 수 있다는 것!

놀랍게도 이 기능은 아직 추가되지 않았습니다. :-)

@yw662 , 풀 리퀘스트를 제출하시겠습니까?

해결하기 쉽기 때문에 ... 시간만 있다면 알 수 있습니다. 이것이 문제라고 생각합니다. 해결 방법은 쉽지만 스크립트를 변경하는 것은 쉽지 않습니다 :-).

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 가 훨씬 쉬울 것 같습니다...

@rowan-OzRunways https://github.com/certbot/certbot/issues/3646#issuecomment -323814774가 귀하에게 유효하지 않습니까? http2 를 손으로 한 번만 추가하면 갱신 할 때 건드리지 않아야 합니다.

흠 클리어한 줄 알았습니다. 한 번은 지워졌지만 certbot-auto 였을 수 있습니다. 감사합니다. 확인하겠습니다.

:+1: :+1: :+1: 범프
제 생일입니다 추가해주세요 감사합니다

얼마나 많은 개발자가 수동으로 인증서를 요청하고 필요에 따라 Nginx 서버 블록을 조정하는 대신 모호한(자동) 구성에 의존하는지 놀랍습니다...

기본 동작은 http2 꺼짐입니다.
--http2는 http2를 켭니다.

이것은 HTTP/2가 기본적으로 지원되지 않는다고 가정하고 결국에는 HTTP/3이 될 것이라고 가정하는 온라인 튜토리얼의 복사 붙여넣기로 수년이 걸리기 때문에 나쁜 생각입니다. 플래그 등으로 HTTP/2를 비활성화하는 것이 더 합리적일 수 있습니다. "멍청한" 구성 자동화에 의존하는 경우 일시적으로 관련된 명령 플래그를 추가할 이유가 없습니다.

"해결 방법"이 수동으로 인증서를 요청하고 있습니다.

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

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

... 그런 다음 사용자 지정 Nginx 서버 블록을 사용합니다. 예:

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

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

우리 nginx 플러그인은 현재 --http2 플래그가 있어도 HTTP/2 지원 활성화를 지원하지 않습니다. 그것이 문제에 의해 추적되고 있는 것입니다.

기본 동작과 관련하여 과거에 --redirect 와 같은 플래그로 수행한 작업은 초기에 플래그 뒤에 숨겨진 지원을 구현하고 사용자가 시도하도록 권장하는 것입니다. 테스트를 잘 거친 후에는 구성을 중단하지 않는지 확인한 후 모든 사용자의 기본 동작으로 만드는 방법을 살펴볼 수 있습니다.

@jessuppi

얼마나 많은 개발자가 수동으로 인증서를 요청하고 필요에 따라 Nginx 서버 블록을 조정하는 대신 모호한(자동) 구성에 의존하는지 놀랍습니다...

요점을 완전히 놓치고 있습니다. 물론 직접 할 수도 있지만 개선해야 할 certbot 클라이언트와 함께 제공되는 기능이 있습니다. certbot이 웹 서버를 구성하도록 허용해야 하는지 여부는 이 문제의 범위를 완전히 벗어납니다.

이 문제는 이제 4년 이 되었습니다. certbot이 자동으로 수행하는 한 --http2 또는 --no-http2 플래그를 사용해야 하는지 여부는 사람들이 별로 신경 쓰지 않는다고 생각합니다.

@bmw 지난 4년 동안 이미 구현된 모든 주요 변경 사항에 비해 상대적으로 단순해야 하는 일에 왜 그렇게 긴 지연이 있습니까? 확실히 certbot 팀은 최신 버전의 HTTP2에 대한 적절한 지원도 중요하다는 데 동의해야 합니다...

실제로 공개 PR이 있습니다. https://github.com/certbot/certbot/pull/7113

@bmw 상대적으로 단순해야 할 일에 왜 그렇게 긴 지연이 있습니까?

많은 Certbot 문제가 있고 우리는 작은 팀이기 때문에 우선 순위를 지정해야 합니다. 나는 이것이 가치가 있다는 데 동의합니다. 우리는 아직 그것에 도달하지 못했습니다.

앞으로 새 프로젝트를 찾을 때 더 쉽게 볼 수 있도록 이 문제에 우선 순위 레이블을 추가하겠습니다.

안녕하세요. http2 NGINX 구성을 지원하는 certbot에 대한 수정 사항이 제공되더라도 Boundler가 여전히 HTTP/2 연결에 대해 웹 루트 검사를 수행할 수 없다는 사실을 수정하지 않을 것이라고 가정합니다. 맞습니까? 참조. 이 링크

이것은 암호화되지 않은 포트의 http2에 관한 것입니다. 여기에서는 문제가 되지 않습니다. 암호화를 사용하여 포트 443의 listen 지시문에 http2 옵션을 추가하기만 하면 됩니다.

@cperrin88 물론이지만 명심해야 할 것은 NGINX는 HTTP/1.1 -> HTTP/2 h2c 프로토콜 업그레이드 를 수행할 수 없다는 것입니다. 챌린지 교환은 서버가 HTTP/1.1을 사용한다고 가정하고 "서버가 HTTP를 통해 HTTP/2를 사용하고 있습니다"라는 오류와 함께 불평할 수 있습니다.

따라서 이 문제에 대한 패치가 적용될 때 염두에 두어야 할 사항입니다. IMHO :)

이 변경으로 인해 암호화되지 않은 포트에 http2가 추가되어서는 안 됩니다. 그러나 우리는 그것을 염두에 두어야 합니다.