Access Server 웹 인증서 오류: 빈 CA 번들 수정

ca_bundle 값이 비었거나 PEM이 손상되면 관리 인터페이스가 멈춥니다. 재시작 전에 인증서, 키, 체인을 하나의 세트로 검증하고 VPN PKI는 건드리지 마십시오.

DNS가 올바르게 확인되는데도 웹 로그인 페이지가 로드되지 않는다면 보통 DNS 문제가 아닙니다. 서비스 로그에 인증서 번들 경로가 비었다거나 웹 인증서와 개인 키의 PEM 파싱 실패가 기록되면 HTTPS 리스너에는 쓸 수 있는 재료가 없고 이름 확인으로는 해결되지 않습니다. 수리는 세 개의 구성 키에 있으며 VPN 클라이언트 인증서를 다시 발급할 필요는 없습니다.

세 키가 실제로 가리키는 것

사용자 지정 웹 인증서 세트는 cs.cert, cs.priv_key, cs.ca_bundle로 설명됩니다. 각각 파일 경로를 저장하고 웹 서비스가 셋을 함께 사용합니다. 키가 잘못된 인증서나 실제로는 리프 인증서인 체인 파일은 빈 값과 같은 방식으로 실패합니다.

이 키들은 Admin과 Client 웹 UI에 속합니다. VPN 클라이언트에 인증서를 발급하는 PKI와는 별개입니다. 따라서 교체할 때 클라이언트 프로필, 서버 키, 인증 기관을 건드릴 필요가 없습니다. 웹 TLS 장애를 전체 PKI 재구축의 이유로 삼는 것이 여기서 가장 비싼 실수입니다.

한 가지 구분이 시간을 아낍니다. 명시적으로 빈 사용자 지정 값은 재정의가 전혀 없는 상태와 다릅니다. 전자는 파서에 빈 경로를 넘기며 로그 줄이 그렇게 말합니다. 후자는 Access Server를 자체 재료에 두므로 업그레이드 후 잘 뜨는 호스트와 그렇지 않은 호스트가 갈립니다.

존재하는 파일도 파싱되지 않는 이유

파서는 파일 이름이 아니라 파일 안의 레이블 블록을 읽습니다. 개인 키가 들어 있는 .crt, 인증서 하나를 기대하는 자리에 하나의 연결 블록으로 쓴 체인, 마지막 줄이 잘린 파일은 모두 거부됩니다. RFC 7468이 그 레이블을 정의하는 이유는 다음 객체의 종류를 알려 주는 유일한 수단이기 때문입니다.

확장자가 아니라 객체를 살펴보십시오. Linux 호스트에서 openssl x509 -noout -subject -issuer -in server.pem와 openssl pkey -noout -check -in key.pem가 중요한 두 질문에 답하며, 둘의 모듈러스나 공개 키를 비교하면 서로 짝이라는 것이 증명됩니다. 개인 키 출력은 티켓과 채팅 로그에 남기지 마십시오. 검사에는 지문이 필요하고 키는 필요 없습니다.

빈 경로는 손상된 파일만큼 의심스럽습니다. 둘 다 뒤에서 모호한 오류를 만들기 때문입니다. 로그가 번들 경로가 비었다고 하면 파일을 디버그하기 전에 저장된 값을 읽으십시오.

의도적으로 폴백으로 돌아가기

Access Server CLI에는 세 경로를 인수로 받아 세트의 사용 가능 여부를 보고하는 검증이 있습니다. 아래 경로는 예시이며 호스트의 보호된 위치로 바꾸십시오.

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

실행 중인 서비스를 건드리기 전에 결과를 읽고, 그다음에 값을 가져와 설치된 버전의 문서화된 절차로 적용하십시오. 공식 CLI 자습서는 검증, 구성 데이터베이스로의 가져오기, 적용 단계를 다루며 그 버전이 어떤 요약보다 중요합니다.

사용자가 실제로 입력하는 이름 검증

사용자 지정 재료가 망가졌고 유효한 내장 폴백이 남아 있다면 문서화된 복구는 세 재정의를 제거하고 Access Server가 그 폴백을 쓰게 하는 것입니다. 먼저 콘솔 접근과 현재 구성의 백업을 마련하십시오. 다시 시작할 서비스가 관리 인터페이스를 제공하는 서비스입니다.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

구성 데이터베이스 전체를 지우는 것은 인증서 수리가 아닙니다. 그 세 키를 대상으로 적용하고 웹 UI가 응답하는지 확인하십시오. web-ssl 디렉터리의 자체 서명 파일은 폴백 자원이지 작업 공간이 아닙니다. 덮어쓰거나 다시 생성하면 유일하게 동작하던 재료가 사라질 수 있습니다.

폴백이 적용된 뒤 브라우저가 다른 인증서를 보여 줄 것으로 예상하십시오. 그것이 올바른 결과이며, 신뢰하는 관리 절차로 확인하는 것이 답입니다. 이후의 모든 경고를 무시하도록 사용자를 가르치는 것이 아닙니다.

복구는 로그인 성공 후에 끝난다

TCP 리스너가 나타났다고 복구가 끝난 것은 아닙니다. DNS 이름, 인증서 신원, 그 이름의 체인을 검증한 뒤 Admin과 Client 웹 UI를 모두 열고 로그인을 완료하십시오. 포트 검사는 그중 아무것도 증명하지 않습니다.

Access Server 3.1 이후는 SNI 호스트 이름마다 다른 웹 인증서를 제공할 수 있습니다. 그렇게 구성되어 있다면 기본 키와 호스트 이름별 항목은 별개의 세트이며, IP 주소로 확인하면 사용자가 받는 것과 다른 인증서가 보이기 쉽습니다. 실패한 이름의 세트를 고쳐 검증하고, 사건을 닫기 전에 로그인 확인을 반복하십시오.

관련 글