Lua-resty-auto-ssl: 와일드카드 인증서

나는 repo 관리자가 아니지만 추가하기 쉬운 것이 아니라고 말해야 합니다. LE 와일드카드 인증서에는 DNS 검증이 필요하며 현재 lua-resty-auto-ssl은 http 검증을 사용합니다.

DNS 유효성 검사는 와일드 카드를 고려하지 않더라도 있으면 좋을 것입니다. 몇 가지 생각:

• 먼저 ACMEv2 지원을 받으려면 탈수 상태를 기다려야 합니다. dehydrated#420
• dehydrated 는 이미 (ACMEv1) dns-01 챌린지를 지원합니다 . 현재 ACMEv2 초안의 dns-01 챌린지는 나와 동일하거나 거의 동일합니다.
• 탈수된 deploy_challenge 후크는 TXT 레코드에 기록할 도메인과 토큰을 제공합니다.
• 사용자가 DNS 레코드를 어떻게 관리하는지 모르기 때문에 이 부분은 일반적이어야 합니다.
  
  
  
  1. 인기 있는 DNS API를 지원합니다. 최소한 PowerDNS, CloudFlare 또는 nsupdate에서 제공하는 것과 같은 "표준" API를 지원하는 인프라를 추가해야 합니다. 이 경우 설정에는 일종의 인증 토큰만 필요합니다.
  
  
  2. 사용자는 독점 API와 대화하거나 더티 셸 스크립트를 호출하는 것과 같이 이러한 레코드를 설정하는 사용자 지정 솔루션이 필요해야 합니다. 이러한 경우에 대한 일반 후크를 제공해야 합니다.
     
     -- Define a function to store the validation tokens for DNS verification -- by let's encrypt in your DNS setup. auto_ssl:set("deploy_dns_challenge", function(domain, token) -- talk to your DNS-API to create a new TXT record _acme-challenge.$domain with value $token end)
  
  
• 스토리지 계층 은 현재 전체 도메인을 인증서를 가져오기 위한 키로 사용할 수 있다고 가정합니다. 이것은 더 이상 사실이 아닙니다. 내 첫 번째 아이디어는 와일드카드를 parentdomain.com:wildcard:latest 로 저장하고 구체적인 인증서를 찾을 수 없는 경우 스토리지 계층에서 해당 키를 확인하도록 하는 것입니다.

질문:

1. 일반 또는 와일드카드 인증서를 생성할지 여부를 어떻게 알 수 있습니까? 새로운 사용자 정의 함수 is_wildcard_domain ? 기존 allow_domain 에 대한 새 반환 값 ?
2. DNS(와일드카드의 경우) 및 HTTP(일반 인증서의 경우) 유효성 검사를 동시에 지원합니까, 아니면 둘 다에 대해 DNS만 지원합니까? 모든 움직이는 부분을 제어하기 때문에 HTTP가 훨씬 더 빠를 수 있습니다.

참고로 이제 ACMEv2 스테이징 엔드포인트를 사용할 수 있습니다. :)

현재 ACMEv2 드래프트의 dns-01 챌린지는 나와 동일하거나 거의 동일합니다.

맞습니다 :-) V1 API와 V2 API 간의 DNS-01 챌린지에서 변경된 사항은 없습니다.

참고: 최소한 dehydrated의 개발 버전은 이제 ACMEv2와 와일드카드 인증서를 지원합니다. 이 작업을 시작하려는 사람이 있다면 지금이 기회입니다 ;)

DNS 유효성 검사를 수행하는 resty-auto-ssl은 완전히 범위를 벗어났습니다.
그러나 resty-auto-ssl을 "대역 외"로 구성된 와일드카드 인증서로 폴백할 수 있어야 합니다.
예를 들어 도메인에 대한 와일드카드 인증서를 수행하기 위해 bind9 및 certbot을 사용하여 서비스를 설정하려고 합니다. 지금 당장은 resty-auto-ssl에게 와일드카드 인증서를 생성하는 대신 사용하도록 지시할 수 없다고 생각합니다.

편집: 글쎄, 그것은 범위 밖 이 아닙니다. 사용자 지정 DNS API에 연결하기 위해 수동 스크립트로 탈수를 구성할 수 있다는 것을 몰랐습니다...

resty-auto-ssl이 사용할 수 있도록 수동으로 생성된 와일드카드 LE 인증서를 Redis에 저장하는 방법이 있습니까?

코드에서 내가 이해한 바에 따르면 이것은 불가능합니다. 각 sub.domain.tld 에 대해 스토리지 인터페이스에서 다음 검사를 쉽게 추가할 수 있습니다.

• sub.domain.tld:latest — 현재
• *.domain.tld:latest
• *.sub.domain.tld:latest

이런 식으로 지금은 이전에 생성된 인증서만 지원하는 와일드카드를 향한 첫 걸음을 내디뎠습니다. 그렇게 한 후, 우리가 원할 경우 와일드카드 인증서 생성을 지원하는 좋은 방법을 결정할 수 있습니다.

편집 : 위의 구현을 긁어 드리겠습니다.

@akalipetis 설정 여부를 확인하려고 했습니까?

ssl_options.fullchain_der
ssl_options.privkey_der

allow_domain에서 작동합니까?
가능하다면 allow_domain에서 redis 요청을 수행하고 설정할 수 있습니다.

방금 이 문제에 부딪힌 기록을 위해 lua-resty-auto-ssl 를 사용하여 모니터링 서비스에서 사용자 정의 도메인 상태 페이지에 대한 인증서를 생성하고 대부분의 사람들은 xxxx.status.updown.io 와 같은 자체 도메인을 사용하여 훨씬 더 효율적입니다. 와일드 카드 인증서를 사용합니다.

*status.updown.io 에 대한 인증서 생성을 건너뛰기 위해 allow_domain 람다를 사용하여 이것을 달성했습니다.

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

그런 다음 와일드카드를 기본 대체 인증서로 제공했습니다.

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

다음과 같은 DNS 챌린지를 사용하여 수동으로 인증서를 생성했습니다.

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

DNS 챌린지로 복잡해 보이기 때문에 자동화하는 데 시간을 할애할 가치가 있는지 잘 모르겠습니다. 낮은 기술이지만 예상대로 작동합니다. :)

이는 좋은 해결 방법이며 많은 사용 사례에 적용되는 해결 방법입니다.
그러나 https://github.com/AnalogJ/lexicon 을 사용하면 DNS 챌린지가 매우 쉬워졌습니다!
그것은 잘 작동하고 많은 공급자를 지원합니다. 나는 그들 중 하나를 추가했고 그 과정은 엄청나게 쉽습니다.

@kapouer lexicon 에 대한 팁을 주셔서 감사합니다. 자동화하려는 경우 염두에 두겠습니다 ;)

방금 이 문제에 부딪힌 기록을 위해 lua-resty-auto-ssl 를 사용하여 모니터링 서비스에서 사용자 정의 도메인 상태 페이지에 대한 인증서를 생성하고 대부분의 사람들은 xxxx.status.updown.io 와 같은 자체 도메인을 사용하여 훨씬 더 효율적입니다. 와일드 카드 인증서를 사용합니다.

*status.updown.io 에 대한 인증서 생성을 건너뛰기 위해 allow_domain 람다를 사용하여 이것을 달성했습니다.

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

그런 다음 와일드카드를 기본 대체 인증서로 제공했습니다.

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

다음과 같은 DNS 챌린지를 사용하여 수동으로 인증서를 생성했습니다.

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

DNS 챌린지로 복잡해 보이기 때문에 자동화하는 데 시간을 할애할 가치가 있는지 잘 모르겠습니다. 낮은 기술이지만 예상대로 작동합니다. :)

나는 또한 우리 앱에 대해 동일한 유형의 도메인 검사를 수행하고 있습니다. 사용자의 포털 호스트에 "자체" 도메인 중 하나가 포함되어 있으면 정적 CA에서 와일드카드 인증서를 사용하는 것으로 되돌아갑니다. 그러나 나는 여전히 LE를 사용하고 수동으로 와일드카드를 생성한다는 당신의 아이디어를 좋아합니다.

나는 이것을 시험해 볼 것이다.

업데이트
좋아, 이것은 내가 원하는 것을 실제로 수행하는 솔루션입니다. 클라우드플레어 플러그인. 문서는 꽤 좋습니다. 1~2시간 안에 작업을 완료했습니다.

https://certbot-dns-cloudflare.readthedocs.io/en/stable/

@jarthod 이것을 자동화하는 다른 해결 방법이 있습니까? 3개월마다 와일드카드를 갱신하는 것을 기억하는 것은 실제로 고통스럽습니다.

@jarthod 이것을 자동화하는 다른 해결 방법이 있습니까? 3개월마다 와일드카드를 갱신하는 것을 기억하는 것은 실제로 고통스럽습니다.

내 편이 아니라 나는 여전히 이것을 사용하고 3 개월마다 수동 갱신을하고 있습니다. 내 서비스(updown.io)를 사용하여 끝점을 모니터링하고 인증서가 만료되려고 할 때 알려주므로 기억하는 것은 문제가 되지 않습니다.

나는 또한 당신의 서비스의 사용자입니다. 어쨌든 나는 계속해서 전통적인 1년 와일드 카드 SSL을 얻었습니다.

이제 당신의 서비스는 내년을 상기시켜줄 일이 생겼습니다 😄

2020년 10월 3일 오후 10시 30분에 Adrien Rey-Jarthon [email protected] 에서 다음과 같이 썼습니다.

</s></s> 수있는
@jarthod 이것을 자동화하는 다른 해결 방법이 있습니까? 3개월마다 와일드카드를 갱신하는 것을 기억하는 것은 실제로 고통스럽습니다.

내 편이 아니라 나는 여전히 이것을 사용하고 3 개월마다 수동 갱신을하고 있습니다. 내 서비스(updown.io)를 사용하여 끝점을 모니터링하고 인증서가 만료되려고 할 때 알려주므로 기억하는 것은 문제가 되지 않습니다.

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