Certbot: 독립 실행형은 대체 포트가 바인딩되도록 허용해야 합니다(인증되지 않음).

클라이언트가 이미 원하는 기능을 가지고 있다고 생각하지만 주로 테스트에 사용되었기 때문에 매우 사용자 친화적인 방식으로 제공되지는 않습니다. 클라이언트에는 다음 플래그가 있습니다.

  --tls-sni-01-port TLS_SNI_01_PORT
                        Port number to perform tls-sni-01 challenge. Boulder
                        in testing mode defaults to 5001. (default: 443)
  --http-01-port HTTP01_PORT
                        Port used in the SimpleHttp challenge. (default: 80)

이 플래그를 사용하면 클라이언트가 도메인 유효성 검사 문제를 설정하는 포트를 지정할 수 있습니다. 일반적으로 --tls-sni-01 는 들어오는 포트 443 트래픽을 라우팅한 포트여야 하고 --http-01-port 는 들어오는 포트 80 트래픽을 라우팅한 포트여야 합니다.

두 플래그를 모두 사용할 필요는 없지만 기본적으로 독립 실행형은 443 이상의 문제를 수행합니다. 다음 플래그를 사용하여 이 동작을 제어할 수 있습니다.

  --standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
                        Supported challenges. Preferred in the order they are
                        listed. (default: tls-sni-01,http-01)

이게 도움이 되길 바란다!

감사합니다. 내일 시도해 보겠습니다.

이것이 작동한다면 실제로 예제로 사용해야 합니다. 확인 프로세스를 처리하기 위해 모든 것을 오프라인으로 전환하는 것보다 프록시 전달을 활성화/비활성화하기 위해 서버를 다시 시작하는 것이 훨씬 쉽습니다.

2016년 3월 22일 오후 3시 16분에 bmw [email protected] 에서 다음과 같이 썼습니다.

클라이언트가 이미 원하는 기능을 가지고 있다고 생각하지만 주로 테스트에 사용되었기 때문에 매우 사용자 친화적인 방식으로 제공되지는 않습니다. 클라이언트에는 다음 플래그가 있습니다.

--tls-sni-01-포트 TLS_SNI_01_PORT
tls-sni-01 챌린지를 수행하기 위한 포트 번호입니다. 둥근 돌
테스트 모드에서 기본값은 5001입니다. (기본값: 443)
--http-01-포트 HTTP01_PORT
SimpleHttp 챌린지에 사용된 포트입니다. (기본값: 80)
이 플래그를 사용하면 클라이언트가 도메인 유효성 검사 문제를 설정하는 포트를 지정할 수 있습니다. 일반적으로 --tls-sni-01은 들어오는 포트 443 트래픽을 라우팅한 포트여야 하고 --http-01-port는 들어오는 포트 80 트래픽을 라우팅한 포트여야 합니다.

두 플래그를 모두 사용할 필요는 없지만 기본적으로 독립 실행형은 443 이상의 문제를 수행합니다. 다음 플래그를 사용하여 이 동작을 제어할 수 있습니다.

--standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
지원되는 과제. 있는 순서대로 선호
나열. (기본값: tls-sni-01,http-01)
이게 도움이 되길 바란다!

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

@jvanasco 대부분의 사람들은 해당 사용 사례에 대해 webroot 플러그인을 사용하지만 예, 프록시 패스 nginx 예제가 좋을 수 있습니다. 문서에 추가하는 PR을 자유롭게 만드십시오. 이것은 아마도 이 파일의 맨 아래에 새 섹션을 가져와야 하는 충분히 전문화된 사용 사례입니다.

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst

그러나 기존 독립 실행형 섹션에서 연결할 수 있습니다.

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst#standalone

이에 대한 답변을 듣지 못했으므로 이 문제를 종료합니다. 다시 열려면 저에게 소리를 지르며 댓글을 달아주세요.

이것은 작동하지 않는 것 같습니다. @bmw

/usr/local/bin/certbot-auto certonly --http-01-port 8484 --config-dir /etc/letsencrypt --work-dir /var/lib/letsencrypt --logs-dir /var/log/letsencrypt --standalone --standalone-supported-challenges http-01 --email [email protected] --domains example.com --agree-tos --non-interactive

tcp        0      0 0.0.0.0:8484                0.0.0.0:*                   LISTEN      7270/python2

인증이 포트 80을 통해 들어오는 것을 보았지만 python2 서버는 8484에서 시작되었습니다.

포트 80의 Nginx

66.133.109.36 - - [25/Aug/2016:12:41:15 +0100] "GET /.well-known/acme-challenge/xxxxxxxx HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

편집하다:
--tls-sni-01-port 5001 --http-01-port 5002 둘 다 필요합니다!

편집하다:
독립 실행형 서버를 스핀업하고 인증하는 방법에 대해 여전히 현명하지 않습니다.

또한 --tls-sni-01-port 이 무시되는 문제가 있습니다.

# certbot certonly --noninteractive --email "matt.hanley@****" --domain **** --agree-tos --tls-sni-01-port 40443 --http-01-port 4080 --standalone  
Failed authorization procedure. ****** (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 2af2853170e5be7e86cdff79d0ca****.febd4f14bb130b15910f30587cf4****.acme.invalid from 185.***.***.***:443. Received certificate containing '*****'

요청은 실제로 :443 로 이동했습니다. 다른 인증서를 제공하는 :443 에서 실행 중인 HTTPS 서비스가 이미 있습니다. 그러나 이것은 renew 에서 작동합니다.

--tls-sni-01-port 문제도 있습니다.

certbot certonly -n -d example.com --agree-tos --email "[email protected]" --standalone --tls-sni-01-port 8443 --http-01-port 8080

Failed to connect to 1.2.3.4:443 for TLS-SNI-01

--http-01-port / --tls-sni-01-port 에서는 Let's Encrypt가 서버에 연결할 포트를 지정할 수 없습니다. 항상 각각 80/443을 사용합니다. 이 모든 플래그를 사용하면 독립 실행형과 같은 플러그인에 대해 Certbot이 수신 대기하는 포트를 제어할 수 있습니다. 이는 예를 들어 모든 포트 80 트래픽을 포트 8080으로 라우팅하는 경우에 유용합니다.

예, 기본적으로 공용 IP 주소에서 액세스할 수 있는 포트 80이 있어야 합니다.

문서에 매우 부족한 부분은 Let's Encrypt가 80에서 들어오는 트래픽을 제어할 수 없는 소수의 목적에 적합하지 않음을 의미합니다(예: 중국/특정 ISP, Corp 방화벽).

나는 이것에 관한 여러 게시물을 읽었습니다. 80에서 수신하는 기능은 Nix 상자의 특권 포트이기 때문에 보안 이득/신뢰 측정으로 간주되는 것처럼 보입니다.

비록 암호화가 웹 서버 외부의 인증서에 대한 사용을 인식하지 못하는 것 같지만 .. 예를 들어 이메일 서버 등, 인증을 처리하기 위해 노드 앱의 포트 7722에서 빠른 부팅을 원할 수 있습니다. t 웹 서버를 실행 ..하지만 그림을 이동합니다.

또한 예를 들어 Chef와 같은 자동화를 사용하는 경우 구성에 SSL이 있는 경우 nginx를 부팅할 수 있도록 자체 서명된 인증서를 구성해야 하며 최소한 유효한 인증서가 있어야 합니다.

SSL만 실행하는 경우 다른 옵션은 다른 웹 서버가 80을 제공하도록 하여 nginx가 부팅을 시도하기 전에 인증서가 다운로드되도록 하는 것입니다. (귀찮은 설정)

내 요리사 배포는 이제 다음을 통해 실행됩니다.

1. 자체 서명된 인증서를 설치합니다.
2. 부팅 nginx(자체 인증서 포함)
3. 실행 인증서
4. 내 위치에 대한 Symlink 인증서
5. nginx 새로고침

내 iPhone에서 보낸

2016년 9월 15일 23:18에 Brad Warren [email protected] 이 다음과 같이 썼습니다.

--http-01-port/--tls-sni-01-port에서는 Let's Encrypt가 서버에 연결할 포트를 지정할 수 없습니다. 항상 각각 80/443을 사용합니다. 이 모든 플래그를 사용하면 독립 실행형과 같은 플러그인에 대해 Certbot이 수신 대기하는 포트를 제어할 수 있습니다. 이는 예를 들어 모든 포트 80 트래픽을 포트 8080으로 라우팅하는 경우에 유용합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

내 웹 서버는 SSL 연결을 위해 하나의 포트에서만 수신 대기하며 기본값 443이 아닙니다. 이는 웹 서버가 포트 전달을 허용하지만 포트 80 또는 443으로의 포트 전달을 허용하지 않는 VPN 서비스 뒤에 있기 때문입니다.

이 서버에서 Let's Encrypt를 구성하려고 하지만 로그에서 acme 클라이언트가 포트 80(액세스할 수 없음)에서 연결을 시도하고 실패하는 것을 볼 수 있습니다.

내가 받는 오류는 "연결할 수 없음" 상태 400입니다.

"addressesResolved" 값은 정확합니다. "port" 값이 80이고 모든 URL이 올바르지 않다는 것입니다. 예를 들어 subdomain.domain과 같은 사용자 지정 포트가 지정되어 있어야 하기 때문입니다. tld:1234 여기서 1234는 내 사용자 지정 포트입니다.

내 설정으로 작동하게 하는 방법이 있습니까?

@gsdevme 에서 포트 80에 공개적으로 액세스할 수 있어야 한다는 인상을 받았습니다...

_ACME 서버를 확인하려면 공개적으로 액세스할 수 있는 포트 80이 있어야 합니다._

_이 솔루션은 내부적으로 대체 포트에서 서버를 실행하고 PORT80에서 대체 포트로 프록시하기 위한 것입니다._

_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._
_PORT80에 액세스할 수 없는 경우 DNS 확인을 사용해야 합니다._

@jvanasco 답변 감사합니다. 사용자 지정 포트를 지정할 수 없다는 것이 너무 아쉽습니다. 내 동적 DNS 공급자 http://freedns.afraid.org/ 에는 TXT 레코드를 자동으로 변경하는 인터페이스가 없기 때문에 DNS 확인은 옵션이 아닙니다.

@jvanasco 님 의 답변이 전적으로 옳다는 것을 알지만 답변하기 전에 우리 모두가 조금 진정되면 좋을 것입니다 :D

구성 가능한 예상 시간이 있습니까? 많은 사람들이 사용자 정의 포트에서 웹 서버를 실행하고 있다고 확신하기 때문입니다.

디자인 선택으로 구성할 수 없습니다.

내 iPhone에서 보낸

2017년 2월 14일 16:16에 nvaert1986 [email protected] 에서 다음과 같이 썼습니다.

구성 가능한 예상 시간이 있습니까? 많은 사람들이 사용자 정의 포트에서 웹 서버를 실행하고 있다고 확신하기 때문입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

여기에도 같은 문제가 있지만 도커용입니다.

문제 :
비프로덕션 환경에서는 항상 실패하기 때문에 certbot 명령을 내 웹서버 시작 명령과 함께 패키지하고 싶지 않습니다.
그래서 다음과 같은 certbot을 포함하는 특정 이미지를 만들고 싶습니다.

• 인증서를 요청
• 내 웹 서버와 공유되는 볼륨 안에 인증서를 넣습니다.

그러나 이 솔루션은 이미 포트 80 및 443에 바인딩된 웹 서버의 컨테이너를 중지하는 경우에만 작동합니다.

해결책 :
certbot 포트를 변경할 수 있습니다. 그러면 certbot과 웹 서버 컨테이너가 모두 병렬로 실행될 수 있습니다.

DNS 유효성 검사를 사용하면 사용 사례를 해결할 수 있습니다.

내 iPhone에서 보낸

2017년 2월 26일 23:32에 NilsRenaud [email protected] 이 다음과 같이 썼습니다.

여기에도 같은 문제가 있지만 도커용입니다.

문제 :
비프로덕션 환경에서는 항상 실패하기 때문에 certbot 명령을 내 웹서버 시작 명령과 함께 패키지하고 싶지 않습니다.
그래서 다음과 같은 certbot을 포함하는 특정 이미지를 만들고 싶습니다.

인증서를 요청
내 웹 서버와 공유되는 볼륨 안에 인증서를 넣습니다.
그러나 이 솔루션은 이미 포트 80 및 443에 바인딩된 웹 서버의 컨테이너를 중지하는 경우에만 작동합니다.

해결책 :
certbot 포트를 변경할 수 있습니다. 그러면 certbot과 웹 서버 컨테이너가 모두 병렬로 실행될 수 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

그럴 수 있지만 이 유효성 검사 모드는 독립 실행형 모드에서는 불가능합니다./
(출처: https://certbot.eff.org/docs/using.html#plugins)

보안을 손상시키지 않고 합리적인 중간 지점은 DNS SRV 레코드를 통해 포트 검색을 허용하는 것 같습니다. Letsencrypt는 다음과 같은 레코드를 쿼리할 수 있습니다.

_letsencrypt._tcp IN SRV 0 0 8080 10.10.10.10

도메인에서 확인 요청을 결과 주소/포트 조합으로 전달합니다. 이는 DNS 확인과 동일한 이점이 있지만 동적 업데이트가 필요하다는 단점이 없습니다.

이것은 또한 사용자가 원하는 경우 중앙 인증서 서버를 참조하여 인증서 관리를 쉽게 중앙 집중화할 수 있음을 의미합니다.

대체 포트를 허용하면 보안이 어떻게 손상됩니까?

이 FOSS 유틸리티는 TCP/443 포트가 사용 중이거나 TCP/443 포트가 전달되지 않은 호스트에 대한 ACME 인증서의 직접 및 간접 설치를 자동화하는 데 도움이 될 수 있습니다.

https://www.actiu.net/sesele/

SeSeLe가 사용을 허용하는 방법에 대한 문서는 어디에 있습니까?
443과 다른 포트?.

2017년 10월 26일 오후 1시 21분에 "Narcis Garcia" [email protected] 이 작성했습니다.

이 FOSS 유틸리티는 직접 및 간접 설치를 자동화하는 데 도움이 될 수 있습니다.
TCP/443 포트가 사용 중이거나 TCP/443이 없는 호스트에 대한 ACME 인증서
그들에게 포트 포워딩:

https://www.actiu.net/sesele/

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/certbot/certbot/issues/2697#issuecomment-339754606 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAOGHuxKLiYjM4-cME-0GBu9Ujoe0NB_ks5swM20gaJpZM4H1uae
.

더 나은 문서 조정을 허용하려면 SeSeLe 포럼의 문제로 이동하십시오. (답은 현재 SeSeLe 문서에 작성되어 있습니다)

이 문제를 다시 검토할 수 있습니까? 근본적인 문제에 대한 해결책은 아직 없습니다. 예, 독립 실행형을 다른 포트에 바인딩할 수 있지만 athority는 여전히 80/443에 연결되므로 쓸모가 없습니다.

프로덕션 환경에서 이미 80/443에서 실행 중인 서버가 있는 경우 해당 포트를 해제할 여유가 없을 때가 있습니다. 챌린지 파일을 수동으로 배치하는 것도 문제가 될 수 있습니다(Docker에서 실행되는 서버).

여기서 실제 솔루션은 기관이 대체 또는 이와 유사한 것으로 연결을 시도할 상위(10,000+)의 포트 세트를 지정하는 것입니다. 전문가가 아니라 보안 관련 문제가 있을 수 있습니다.

LE가 포트 80/443에만 연결하는 동기는 무엇입니까? 이것은?
공식적으로 문서화된 제한?

누구든지 올바른 문서를 알려줄 수 있습니까?

2017년 11월 30일 오전 6시 31분에 "cen1" [email protected] 이 작성했습니다.

이 문제를 다시 검토할 수 있습니까? 아직까지 해법은 없다.
근본적인 문제. 예, 독립형을 다른 포트에 바인딩할 수 있지만
athority는 여전히 80/443에 연결되기 때문에 쓸모가 없습니다.

프로덕션 환경에서 이미 80/443에서 실행 중인 서버가 있는 경우
때때로 단순히 해당 포트를 해제할 여유가 없습니다. 수동 배치
챌린지 파일도 문제가 될 수 있습니다(Docker에서 실행되는 서버).

여기서 실제 솔루션은 상위(10
000+) 권한이 대체 또는 무언가로 연결을 시도하는 곳
그런. 전문가가 아니라 보안 관련 문제가 있을 수 있습니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/certbot/certbot/issues/2697#issuecomment-348162321 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAOGHqWG9XZyTVDdAbm3t5xQ-AD6Y_OQks5s7pIDgaJpZM4H1uae
.

LE가 포트 80/443에만 연결하는 동기는 무엇입니까?
이것은 공식적으로 문서화된 제한 사항입니까?

누구든지 올바른 문서를 알려줄 수 있습니까?

여기에 설명된 현재 CA/B 포럼 요구 사항입니다.
https://cabforum.org/2017/09/19/ballot-190-revised-validation-requirements/

여기에 더 자세히 설명되어 있습니다. https://community.letsencrypt.org/t/support-for-ports-other-than-80-and-443/3419/100

제가 영어를 잘 못해서 이해하는 바와 같이 CA/Browser Forum에서 그들은 2017년 9월에 TCP 포트 25, 115, 22의 추가 가능성에 대해 토론했습니다.
제안이 승인되었으며 올해 11월에 발효되어야 합니다.

누군가 Google에서 (나와 같은) 여기로 올 경우 미래의 메모:

2018-08-29 13:43:33,495: WARNING:certbot.plugins.standalone: 
The standalone specific supported challenges flag is deprecated. 
Please use the --preferred-challenges flag instead.

nginx를 사용하는 경우 certbot certonly --nginx 과 함께 nginx 모듈을 사용할 수 있습니다. 구성 없이 기존 nginx 서버를 활용합니다.

플래그 --http-01-port 는 실제로 직관적이지 않으며 명령의 도움으로 찾을 수 없었고 플래그 --http-01-port 에 대해 Google을 검색해야 했습니다. 도움말에 플래그가 언급되어 있으면 좋을 것입니다.