SoftEther ServerCertSet: vpncmd로 갱신된 체인 가져오기

Certbot이 갱신 성공을 보고하고 디스크의 파일에는 새 날짜가 붙지만, 클라이언트는 여전히 예전 신원을 만납니다. SoftEther는 SSL 서버 인증서를 자체 서버 수준 구성에 보관하므로, 리프와 그 키를 가져오기 전까지는 디스크의 새 파일이 아무것도 바꾸지 않습니다. 아래 순서는 수동 가져오기 한 번, 갱신 때마다 실행되는 래퍼, 그리고 리스너가 실제로 제시하는 내용을 읽는 점검을 다룹니다. 각 단계는 다음 갱신 후에 비교할 수 있는 증거를 남깁니다.

갱신된 파일은 서버 신원을 바꾸지 않는다

발급과 배포는 실패 방식이 다른 별개의 사건입니다. ACME 클라이언트는 파일을 계보 디렉터리에 쓰고 성공을 기록하지만, SoftEther는 구성에 마지막으로 로드된 인증서를 계속 사용합니다. 따라서 종료 상태 영은 파일을 설명할 뿐 서비스를 설명하지 않으며, 아무도 보지 않는 동안 둘은 어긋난 채로 있을 수 있습니다. 가져오기를 배포 단계로, 갱신을 그 입력으로 다루십시오.

이 구분은 혼란스러운 절반의 실패도 설명합니다. 예전 인증서는 만료 전까지 계속 동작하므로 처음에는 아무것도 고장 난 것처럼 보이지 않습니다. 만료되면 모든 클라이언트가 한꺼번에 실패하는데, 이는 놓친 배포 단계가 아니라 장애처럼 보입니다. 갱신 때마다 제시 신원을 확인하면 그 놀라움은 일상적인 관찰이 됩니다.

리스너에 맞는 챌린지를 고르십시오

인증서에는 클라이언트가 검증하는 호스트가 들어가야 하므로 내부 레이블이나 주소 대신 공인 DNS 이름을 사용하십시오. HTTP-01은 챌린지에 잠시 포트 80으로 응답해야 하며, 이는 임시 리스너이고 SoftEther 자체 포트를 옮길 이유가 결코 아닙니다. DNS-01은 레코드로 제어를 증명하며 인바운드 HTTP가 전혀 필요하지 않습니다.

무인 갱신은 하나의 영역으로 범위가 제한된 자격 증명을 쓰는 자동화된 DNS 통합을 뜻하며, 두 달마다 손으로 입력하는 TXT 레코드가 아닙니다. 와일드카드는 챌린지 유형을 바꿀 뿐 그 자동화의 필요성을 바꾸지 않습니다. 첫 인증서가 생기기 전에 이것을 결정하십시오. 나중에 챌린지 유형을 바꾸면 클라이언트 구성과 방화벽을 함께 건드려야 합니다.

여기 있는 동안 산출물을 정리해 두십시오. 리프와 중간 인증서는 별도 파일로도, 하나로 합쳐진 체인 파일로도 도착하고, 개인 키는 다시 별도이며, 가져오기에는 짝이 맞는 키를 가진 체인이 필요합니다. 공개 인증서만으로는 안 됩니다.

서버 수준에서 체인을 가져오십시오

인증서를 건드리기 전에 서버 구성을 백업하고 관리 인터페이스에 여전히 접근할 수 있는지 확인하십시오. 인증서는 서버 객체에 속하므로 Virtual Hub 관리자가 아니라 서버 관리자로 연결하십시오. 그런 다음 체인과 키를 절대 경로로, 명령을 실행하는 계정이 읽을 수 있는 파일에서 로드하십시오. 경로가 절대적인 이유는 명령이 vpncmd를 실행한 프로세스의 작업 디렉터리에서 경로를 해석하기 때문입니다:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

성공을 가정하지 말고 명령의 출력을 읽고, 넘긴 파일을 믿지 말고 체인을 다시 읽으십시오. 전체 PEM 번들을 가져오는 빌드와 첫 인증서만 가져오는 빌드의 경계는 한 곳에 문서화되어 있지 않으므로, 앞에 있는 빌드에서는 점검이 이를 판가름합니다. 리스너가 제시하는 인증서를 세어 보십시오. 중간 인증서가 없는 리프는 첫 블록만 소비한 가져오기 도구의 표식입니다.

가져온 키는 서버를 실행하는 계정만 읽을 수 있게 하고, 관리 비밀번호는 셸 기록에 남기지 마십시오. 이 첫 가져오기에서는 비밀번호를 명령 인수로 넘기지 말고 프롬프트에서 입력하십시오. 이 두 습관은 비용이 들지 않으며, 인증서 배포가 보호해야 할 것을 흘리는 가장 흔한 경로를 없앱니다. 첫 가져오기 전에 하십시오. 이후가 아닙니다.

배포를 훅으로 연결하고, 갱신을 연결하지 마십시오

수동 가져오기가 동작하면 그 단계들을 작은 래퍼에 그대로 넣고, 갱신 성공 후 ACME 클라이언트에서 호출하십시오. Certbot은 훅을 위해 RENEWED_LINEAGE과 RENEWED_DOMAINS를 설정하므로, 여러 인증서를 관리하는 머신에서도 래퍼는 하나의 인증서에 작용할 수 있습니다. 호스트의 모든 갱신에 반응하지 말고 계보로 걸러내십시오. 래퍼는 서버 권한으로 실행되는 배포 코드이므로 그 위치의 다른 스크립트처럼 검토하십시오.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

무인으로 실행되는 훅에는 자체 보호된 자격 증명 저장소와 사람에게 닿는 실패 신호가 필요합니다. 발급이 성공하고 가져오기가 실패하면 다른 인증서를 요청하지 말고 가져오기를 다시 시도하십시오. 두 번째 요청은 새 파일 뒤에 배포 결함을 숨깁니다. Certbot 갱신 문서는 아무것도 갱신하지 않는 실행이 정상 결과라고 분명히 밝히므로, 둘을 구분하는 것은 훅입니다.

제시된 체인을 파일과 비교하십시오

디스크가 아니라 리스너를 읽으십시오. 클라이언트가 쓰는 서버 이름으로 클라이언트 방향 포트에 연결한 다음, 지문과 전달된 체인을 훅이 설치한 계보와 비교하십시오. 두 명령이면 충분하고, 첫 번째는 중간 인증서가 도착하는지도 보여 줍니다:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

그다음 새 클라이언트 연결을 만드십시오. 가져오기 전에 맺은 세션은 이전 신원으로 인증되었고 새 신원에 대해 아무것도 증명하지 못합니다. 클라이언트가 예전 리프를 고정한다면, 공개 체인이 유효해도 조율된 갱신이 필요하며 그 작업은 갱신과 같은 런북에 속합니다. 서비스 앞의 리버스 프록시가 좋은 인증서를 제시하더라도 VPN 리스너는 여전히 예전 것을 들고 있을 수 있으므로, 점검은 클라이언트가 실제로 닿는 포트를 지정해야 합니다. 갱신 날짜 옆에 지문을 기록해 두어 다음 비교가 기억이 아니라 점검이 되게 하십시오.