🥇SSL 발급 자동화를 향해

SSL 인증서를 사용하는 경우가 꽤 많습니다. (대부분의 사람들에게 일반적으로 적용되는) 인증서를 만들고 설치하는 과정을 다시 한번 살펴보겠습니다.

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

비교적 빠르고 복잡하지 않으며 명확합니다. 이 옵션은 프로젝트가 최대 10개일 때 매우 적합합니다. 하지만 프로젝트 수가 더 많고 최소 세 개의 환경이 있는 경우에는 어떨까요? 클래식 개발 환경 - 스테이징 환경 - 프로덕션 환경. 이 경우 이 프로세스를 자동화하는 것을 고려해 볼 만합니다. 문제를 좀 더 깊이 파고들어 인증서 생성 및 유지 관리에 소요되는 시간을 더욱 최소화할 수 있는 해결책을 찾는 것이 좋습니다. 이 글에서는 문제에 대한 분석과 반복 작업에 대한 간략한 가이드를 제공합니다.

미리 말씀드리겠습니다. 저희 회사의 주요 전문 분야는 .NET이며, 따라서 IIS 및 기타 Windows 관련 분야도 다룹니다. 따라서 ACME 클라이언트와 그에 대한 모든 작업도 Windows 사용 관점에서 설명하겠습니다.

이것은 누구와 관련이 있습니까? 그리고 몇 가지 초기 데이터

작성자가 대표하는 회사 K. URL(예시): company.tld

프로젝트 X는 저희 프로젝트 중 하나이며, 인증서 작업 시 최대한의 시간 절약을 목표로 해야 한다는 결론을 내렸습니다. 이 프로젝트는 개발, 테스트, 스테이징, 운영, 이렇게 네 가지 환경으로 구성됩니다. 개발 및 테스트 환경은 저희 측에서, 스테이징 및 운영 환경은 고객 측에서 각각 관리합니다.

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

즉, 우리는 다음과 같은 그림을 얻습니다.

데브
Test
준비
생산

projectX.dev.company.tld
프로젝트X.테스트.회사.tld
스테이징.프로젝트X.tld
프로젝트X.tld

모듈1.프로젝트X.dev.회사.tld
모듈1.프로젝트X.테스트.회사.tld
모듈1.스테이징.프로젝트X.tld
모듈1.프로젝트X.tld

모듈2.프로젝트X.dev.회사.tld
모듈2.프로젝트X.테스트.회사.tld
모듈2.스테이징.프로젝트X.tld
모듈2.프로젝트X.tld

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

모듈N.projectX.dev.company.tld
모듈N.projectX.test.company.tld
모듈N.스테이징.프로젝트X.tld
모듈N.projectX.tld

프로덕션 환경에서는 구매한 와일드카드 인증서를 사용하는데, 여기에는 의문의 여지가 없습니다. 하지만 이 인증서는 하위 도메인의 첫 번째 레벨에만 적용됩니다. 따라서 *.projectX.tld에 대한 인증서가 있다면 staging.projectX.tld에는 작동하지만, module1.staging.projectX.tld에는 작동하지 않습니다. 그리고 저는 별도로 인증서를 구매하고 싶지 않습니다.

그리고 이는 한 회사의 한 프로젝트 사례에 불과합니다. 물론 이 프로젝트가 유일한 것은 아닙니다.

우리 모두가 이 문제를 다루려는 공통적인 이유는 다음과 같습니다.

비교적 최근에 구글, SSL 인증서 최대 유효 기간 단축 제안. 모든 결과를 감수하면서요.
프로젝트 내부 및 회사 전체의 요구에 맞춰 SSL을 발급하고 유지하는 프로세스를 원활하게 해줍니다.
인증서 레코드를 중앙에서 저장하면 DNS를 이용한 도메인 확인 및 자동 갱신 문제를 부분적으로 해결하고 클라이언트 신뢰 문제도 해결할 수 있습니다. 하지만 파트너/실행자 회사 서버에 대한 CNAME은 타사 리소스에 대한 CNAME보다 더 신뢰할 수 있습니다.
글쎄요, 마지막으로 이 경우에는 "가진 게 없는 것보다 낫다"라는 문구가 완벽하게 들어맞습니다.

SSL 공급자 선택 및 준비 단계

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

도메인에 대한 레코드가 생성되었으므로 인증서 생성으로 넘어가겠습니다.

자동화된 SSL 발급을 향해

우리는 마지막 출력, 즉 와일드카드 인증서 발급을 위한 도메인 소유권 확인에 사용 가능한 옵션에 관심이 있습니다.

DNS 레코드를 수동으로 생성(자동 업데이트는 지원되지 않음)
acme-dns 서버를 사용하여 DNS 레코드 만들기(자세한 내용은 여기에서 읽을 수 있음) 여기에.
자신의 스크립트를 사용하여 DNS 레코드를 생성합니다(Certbot용 Cloudflare 플러그인과 유사).

언뜻 보기에는 세 번째 항목이 매우 적합해 보이지만, DNS 제공업체가 이 기능을 지원하지 않는다면 어떻게 해야 할까요? 일반적인 경우를 생각해 봅시다. 일반적인 경우는 CNAME 레코드이며, 모두가 지원합니다. 따라서 두 번째 항목에서 멈추고 ACME-DNS 서버를 구성해 보겠습니다.

ACME DNS 서버 설정 및 인증서 발급

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

필수 요구 사항 서버가 제대로 작동하려면 해당 도메인에 대한 NS 레코드와 A 레코드를 생성해야 합니다. 제가 처음 불편하게 느낀 점은 Cloudflare(적어도 무료 사용 모드에서는)가 동일한 호스트에 대해 NS 레코드와 A 레코드를 동시에 생성할 수 없다는 것이었습니다. 문제가 있었던 것은 아니지만, bind에서는 가능합니다. 지원팀은 패널에서 이를 허용하지 않는다고 답변했습니다. 문제없습니다. 두 개의 레코드를 생성해 보겠습니다.

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 서버 설정 및 실행으로 넘어가겠습니다. 저는 다음 위치에 서버를 호스팅할 예정입니다. ubuntu 서버 도커 컨테이너에서 실행되지만, Go 언어가 설치된 곳이라면 어디에서든 실행할 수 있습니다. 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.

자동화된 SSL 발급을 향해

우리는 필요한 기록을 만들고 그것이 올바르게 만들어졌는지 확인합니다.

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

winacme에 필요한 항목을 생성했는지 확인하고 인증서 생성 프로세스를 계속 진행합니다.

자동화된 SSL 발급을 향해

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

인증서 생성 과정이 완료되었습니다. 웹 서버에 설치하여 사용할 수 있습니다. 인증서를 생성할 때 스케줄러에 작업을 추가하면 향후 인증서 갱신 과정이 자동으로 진행됩니다.

출처 : habr.com