SSL 발급 자동화를 향하여

SSL 인증서를 사용하여 작업해야 하는 경우가 많습니다. 인증서를 생성하고 설치하는 과정을 기억해 봅시다(대부분의 경우 일반적인 경우).

• 공급자(SSL을 구매할 수 있는 사이트)를 찾으세요.
• CSR을 생성합니다.
• 제공업체에 보내세요.
• 도메인 소유권을 확인하세요.
• 인증서를 받으세요.
• 인증서를 필수 형식으로 변환합니다(선택 사항). 예를 들어 pem에서 PKCS #12까지입니다.
• 웹 서버에 인증서를 설치합니다.

비교적 빠르고 복잡하지 않으며 이해하기 쉽습니다. 이 옵션은 최대 XNUMX개의 프로젝트가 있는 경우 매우 적합합니다. 그 수가 더 많고 환경이 세 개 이상 있으면 어떻게 될까요? 클래식 개발 - 준비 - 제작. 이 경우 이 프로세스를 자동화하는 것에 대해 생각해 볼 가치가 있습니다. 저는 문제를 좀 더 깊이 파고들어 인증서 생성 및 유지 관리에 소요되는 시간을 더욱 최소화할 수 있는 솔루션을 찾을 것을 제안합니다. 이 기사에는 문제 분석과 반복에 대한 간단한 가이드가 포함됩니다.

미리 예약하겠습니다. 저희 회사의 주요 전문 분야는 .net이고 그에 따라 IIS 및 기타 Windows 관련 제품도 있습니다. 따라서 ACME 클라이언트와 그에 대한 모든 작업도 Windows 사용 관점에서 설명됩니다.

누구에게 관련이 있으며 일부 초기 데이터는

저자가 대표하는 K사. URL(예): company.tld

프로젝트 X는 우리 프로젝트 중 하나이며, 작업하는 동안 인증서 작업 시 시간을 최대한 절약해야 한다는 결론에 도달했습니다. 이 프로젝트에는 개발, 테스트, 스테이징, 프로덕션이라는 네 가지 환경이 있습니다. 개발과 테스트는 우리 측에서, 스테이징과 프로덕션은 클라이언트 측에서 담당합니다.

프로젝트의 특별한 특징은 하위 도메인으로 사용할 수 있는 모듈이 많다는 것입니다.

즉, 다음과 같은 그림이 있습니다.

데브
Test
준비
생산

projectX.dev.company.tld
projectX.test.company.tld
스테이징.projectX.tld
projectX.tld

module1.projectX.dev.company.tld
module1.projectX.test.company.tld
module1.staging.projectX.tld
module1.projectX.tld

module2.projectX.dev.company.tld
module2.projectX.test.company.tld
module2.staging.projectX.tld
module2.projectX.tld

...
...
...
...

moduleN.projectX.dev.company.tld
moduleN.projectX.test.company.tld
moduleN.staging.projectX.tld
moduleN.projectX.tld

프로덕션에는 구매한 와일드카드 인증서가 사용되며 여기서는 질문이 발생하지 않습니다. 하지만 이는 하위 도메인의 첫 번째 수준에만 적용됩니다. 따라서 *.projectX.tld에 대한 인증서가 있는 경우 이는 Staging.projectX.tld에 대해서는 작동하지만 module1.staging.projectX.tld에 대해서는 작동하지 않습니다. 그런데 왠지 따로 사고 싶지 않네요.

그리고 이는 한 회사의 한 프로젝트의 예에만 근거한 것입니다. 그리고 물론 하나 이상의 프로젝트가 있습니다.

모든 사람이 이 문제를 해결하는 일반적인 이유는 다음과 같습니다.

• 최근에 Google은 SSL 인증서의 최대 유효 기간을 줄이는 것을 제안했습니다.. 모든 결과가 있습니다.
• 프로젝트와 회사 전체의 내부 요구에 맞게 SSL을 발급하고 유지하는 프로세스를 촉진합니다.
• DNS 및 후속 자동 갱신을 사용한 도메인 확인 문제를 부분적으로 해결하고 클라이언트 신뢰 문제도 해결하는 인증서 레코드의 중앙 집중식 저장입니다. 그럼에도 불구하고 파트너/수행자 회사의 서버에 있는 CNAME은 타사 리소스보다 더 신뢰할 수 있습니다.
• 음, 마지막으로, 이 경우에는 "가지지 않는 것보다 있는 것이 낫다"라는 문구가 완벽하게 들어맞습니다.

SSL 공급자 선택 및 준비 단계

무료 SSL 인증서에 사용 가능한 옵션 중에서 cloudflare 및 letsencrypt가 고려되었습니다. 이(및 일부 다른 프로젝트)의 DNS는 cloudflare에서 호스팅되지만 저는 해당 인증서를 사용하는 것을 좋아하지 않습니다. 따라서 letsencrypt를 사용하기로 결정했습니다.
와일드카드 SSL 인증서를 생성하려면 도메인 소유권을 확인해야 합니다. 이 절차에는 일부 DNS 레코드(TXT 또는 CNAME)를 생성한 다음 인증서 발급 시 이를 확인하는 과정이 포함됩니다. Linux에는 유틸리티가 있습니다. certbot를 사용하면 이 프로세스를 부분적으로(또는 일부 DNS 공급자의 경우 완전히) 자동화할 수 있습니다. Windows의 경우 발견하고 확인했습니다 내가 결정한 ACME 클라이언트 옵션 WinACME.

도메인에 대한 레코드가 생성되었으므로 인증서 생성을 진행해 보겠습니다.

우리는 마지막 결론, 즉 와일드카드 인증서 발급을 위해 도메인 소유권을 확인하는 데 사용할 수 있는 옵션에 관심이 있습니다.

1. 수동으로 DNS 레코드 생성(자동 업데이트는 지원되지 않음)
2. acme-dns 서버를 사용하여 DNS 레코드 생성(자세한 내용은 여기에.
3. 자체 스크립트를 사용하여 DNS 레코드 생성(certbot용 cloudflare 플러그인과 유사)

언뜻 보면 세 번째 사항이 매우 적합하지만 DNS 공급자가 이 기능을 지원하지 않으면 어떻게 될까요? 하지만 우리에게는 일반적인 경우가 필요합니다. 그러나 일반적인 경우는 모두가 CNAME 레코드를 지원하기 때문입니다. 따라서 지점 2에서 멈추고 ACME-DNS 서버 구성으로 이동합니다.

ACME-DNS 서버 설정 및 인증서 발급 프로세스

예를 들어 2nd.pp.ua라는 도메인을 만들었고 앞으로도 사용할 예정입니다.

필수 요구사항 서버가 올바르게 작동하려면 해당 도메인에 대한 NS 및 A 레코드를 생성해야 합니다. 그리고 제가 직면한 첫 번째 불쾌한 순간은 cloudflare(적어도 무료 사용 모드에서는)가 동일한 호스트에 대해 NS 및 A 레코드를 동시에 생성하는 것을 허용하지 않는다는 것입니다. 이것이 문제가 되는 것은 아니지만, 구속력이 있는 경우에는 가능합니다. 지원팀은 패널이 이를 허용하지 않는다고 응답했습니다. 문제 없습니다. 두 개의 레코드를 만들어 보겠습니다.

acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.

이 단계에서 호스트는 다음 사항을 해결해야 합니다. acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data

하지만 acme.2nd.pp.ua 이를 제공하는 DNS 서버가 아직 실행되지 않기 때문에 확인되지 않습니다.

레코드가 생성되었으므로 ACME-DNS 서버 설정 및 시작을 진행합니다. 그것은 내 우분투 서버에 살 것입니다 도커 컨테이너이지만 golang을 사용할 수 있는 곳이라면 어디에서나 실행할 수 있습니다. Windows도 꽤 적합하지만 저는 여전히 Linux 서버를 선호합니다.

필요한 디렉터리와 파일을 만듭니다.

$ mkdir config
$ mkdir data
$ touch config/config.cfg

선호하는 텍스트 편집기로 vim을 사용하고 샘플을 config.cfg에 붙여넣어 보겠습니다. 구성.

성공적인 작업을 위해서는 일반 및 API 섹션을 수정하는 것으로 충분합니다.

[general]
listen = "0.0.0.0:53"
protocol = "both"
domain = "acme.2nd.pp.ua"
nsname = "acmens.2nd.pp.ua" 
nsadmin = "admin.2nd.pp.ua" 
records = 
    "acme.2nd.pp.ua. A 35.237.128.147",
    "acme.2nd.pp.ua. NS acmens.2nd.pp.ua.",                                                                                                                                                                                                  ]
...
[api]
...
tls = "letsencrypt"
…

또한 원하는 경우 기본 서비스 디렉터리에 docker-compose 파일을 생성합니다.

version: '3.7'
services:
  acmedns:
    image: joohoi/acme-dns:latest
    ports:
      - "443:443"
      - "53:53"
      - "53:53/udp"
      - "80:80"
    volumes:
      - ./config:/etc/acme-dns:ro
      - ./data:/var/lib/acme-dns

준비가 된. 실행할 수 있습니다.

$ docker-compose up -d

이 단계에서 호스트는 해결을 시작해야 합니다. acme.2nd.pp.ua, 404가 나타납니다. https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes of data.

$ curl https://acme.2nd.pp.ua
404 page not found

이것이 나타나지 않으면 - docker logs -f <container_name> 다행스럽게도 로그는 꽤 읽기 쉽습니다.

인증서 생성을 시작할 수 있습니다. 관리자 권한으로 powershell을 열고 winacme를 실행합니다. 우리는 선거에 관심이 있습니다:

• M: 새 인증서 생성(전체 옵션)
• 2:수동 입력
• 2: [dns-01] acme-dns를 사용하여 확인 레코드를 생성합니다(https://github.com/joohoi/acme-dns)
• ACME-DNS 서버에 대한 링크를 묻는 질문에 답변에 생성된 서버의 URL(https)을 입력합니다. acme-dns 서버의 URL: https://acme.2nd.pp.ua

처음에는 클라이언트가 기존 DNS 서버에 추가해야 하는 레코드를 발행합니다(일회성 절차).

[INFO] Creating new acme-dns registration for domain 1nd.pp.ua

Domain:              1nd.pp.ua
Record:               _acme-challenge.1nd.pp.ua
Type:                   CNAME
Content:              c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Note:                   Some DNS control panels add the final dot automatically.
                           Only one is required.

필요한 레코드를 생성하고 올바르게 생성되었는지 확인합니다.

$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.

winacme에서 필수 항목을 생성했음을 확인하고 인증서 생성 프로세스를 계속합니다.

certbot을 클라이언트로 사용하는 방법이 설명되어 있습니다. 여기에.

이로써 인증서 생성 과정이 완료되었으며, 웹 서버에 설치하여 사용할 수 있습니다. 인증서를 생성할 때 스케줄러에서도 작업을 생성하면 나중에 인증서 갱신 프로세스가 자동으로 발생합니다.

출처 : habr.com