SSTP 인증서 불일치: 서버가 제시해야 하는 이름

SSTP 클라이언트는 TLS 검증이 성공한 뒤에만 서버를 받아들이고, 그 검사는 이름과 체인, 용도를 비교합니다. 이름은 연결 프로필에서 나오며, 우연히 핑이 통하는 주소에서 오는 것이 아닙니다. 셋 중 하나라도 맞지 않으면 클라이언트는 인증서 문제를 보고하고 로그인 프롬프트에 절대 도달하지 않습니다.

프로필 이름이 무엇을 검사할지 결정한다

SSTP는 TCP 443 위에서 TLS를 실행하므로 클라이언트는 다른 TLS 클라이언트와 똑같이 동작하며, 프로필에서 호스트 이름을 가져와 그 이름을 요청하고 인증서를 그것과 비교합니다. 프로필에 IP 주소를 입력하면 비교는 IP 주소 비교가 되고, 대부분의 서버 인증서는 이를 충족하지 못합니다.

브라우저가 프로필과 다른 이름을 사용했기 때문에 브라우저 테스트는 성공하는데 VPN은 실패할 수 있습니다. 같은 분열은 split-horizon DNS가 VPN 호스트 이름을 내부 주소로 해석하는데 브라우저는 공용 주소에 도달했을 때도 나타납니다. 먼저 프로필을 문서화된 호스트 이름에 맞추고, 그 다음 인증서를 비교하십시오. 그 전에 바꾸는 다른 무엇이든 추측입니다.

서버 인증서가 담아야 하는 것

최신 클라이언트는 주체 대체 이름 확장과 대조하므로 호스트 이름이 거기에 DNS 항목으로 있어야 합니다. 일반 이름만으로는 오늘날의 검증 스택에 충분하지 않고, 와일드카드는 하나의 레이블을 덮을 뿐 당신이 만들어 낸 임의의 하위 도메인을 덮지 않습니다. 세 인증서가 경계를 보여 줍니다: 올바른 이름에 잘못된 용도는 신원을 검증한 뒤 용도 검사에서 실패하고, 올바른 이름과 용도라도 중간 인증서가 없으면 체인에서 실패하며, 일반 이름에만 있는 이름은 그 둘 중 어느 것도 중요해지기 전에 실패합니다.

인증서에는 Microsoft의 SSTP 사양에 명시된 확장 키 사용 값, 즉 객체 식별자 1.3.6.1.5.5.7.3.1을 가진 serverAuth라는 서버 인증 용도도 필요합니다. 키 사용과 유효한 체인이 집합을 완성합니다. 서버에 있고 올바른 이름으로 발급되었지만 클라이언트 인증 전용인 인증서는 여전히 실패합니다.

자격 증명보다 먼저 체인과 시계를 확인한다

시간과 신뢰의 실패는 이름 불일치와 같은 가시적 결과를 낳고, 둘 다 암호 문제보다 진단 비용이 적습니다. 서버의 시계와 클라이언트의 시계를 확인한 다음, 클라이언트가 보는 대로 체인을 읽으십시오:

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

첫 번째 명령은 이름과 유효 기간, 클라이언트가 비교할 대체 이름을 출력합니다. 두 번째는 제시된 체인과 함께 검증 오류를 보고하며, 중간 인증서 누락이 바로 거기에서 드러납니다. Windows에서는 시간 서비스 조회가 시계가 교정되는지 아니면 그저 흘러갔는지 알려 줍니다.

내부 CA는 클라이언트가 그 CA를 신뢰해야 한다는 조건을 하나 더 추가합니다. 조직 루트는 그 결정이 곧 신뢰 모델 전체의 축소판이기 때문에 대체 인증서를 제공하는 페이지가 아니라 승인된 배포 경로로 설치하십시오.

서버 검증과 사용자 인증은 실패 원인이 다른 연속 단계입니다. 인증서 오류는 클라이언트가 서버를 한 번도 신뢰하지 않았다는 뜻이고, 거부된 암호는 서버를 신뢰했지만 자격 증명이 틀렸다는 뜻입니다. 암호 프롬프트에 도달하려고 인증서 검증을 끄는 것은 보증을 고치는 대신 없애는 일입니다. 나머지 경로가 작동함을 증명하려면 체인을 이미 신뢰하는 클라이언트에서 같은 호스트 이름과 포트를 테스트하고, 배포된 프로필은 그대로 두십시오.

이름이나 인증서를 고친 뒤 다시 테스트한다

세 조건이 수리를 결정합니다. 프로필 이름이 틀렸다면 프로필을 고치거나 빠진 이름을 인증서에 추가하십시오. 체인이 불완전하다면 서버에 중간 인증서를 설치하십시오. 용도가 틀렸다면 주변을 덧대지 말고 다시 발급하십시오.

변경 후 지원되는 클라이언트로 다시 연결하고 로그인 프롬프트가 나타나는지, 그다음 터널이 올라오는지 확인하십시오. 티켓에 사용한 호스트 이름과 발급자, 만료 날짜를 기록하십시오. 그 기록이 다음 갱신을 또 한 번의 장애가 아닌 계획된 작업으로 만들고, 세 조건 중 무엇이 실제로 깨졌는지 다음 사람에게 보여 줍니다.