ERR_SSL_PROTOCOL_ERROR

이 오류의 의미와 확인 방법

• Chrome 또는 Edge에 ERR_SSL_PROTOCOL_ERROR와 함께 “이 사이트는 보안 연결을 제공할 수 없습니다”가 표시됩니다.
• proxy 또는 load balancer 뒤의 전체 사이트, 특정 subdomain 또는 하나의 hostname에만 문제가 발생할 수 있습니다.
• port 80의 일반 HTTP는 작동하지만 HTTPS가 실패할 수 있습니다. 이는 반드시 애플리케이션 문제가 아니라 TLS 경로의 문제임을 나타냅니다.
• 인증서 갱신, 서버 마이그레이션, web server 설정 변경, CDN 변경 또는 port 443에서 수신하는 service 변경 후 오류가 시작될 수 있습니다.
• CDN, reverse proxy 또는 load balancer가 개입하면 직접 origin을 테스트한 결과와 public hostname을 테스트한 결과가 다를 수 있습니다.

가능성이 높은 순서의 주요 원인

1. port 443에서 일반 HTTP 또는 다른 non-TLS protocol을 제공하는 경우. HTTPS listener가 없거나 잘못된 service가 port 443에 bind되었을 수 있습니다. 그러면 브라우저는 TLS handshake가 아닌 데이터를 받게 됩니다.
2. HTTPS virtual host 또는 server block이 잘못된 경우. 서버가 잘못된 address에서 수신하거나, 잘못된 hostname을 선택하거나, web server에 필요한 TLS directive가 없을 수 있습니다.
3. CDN, reverse proxy 또는 load balancer의 origin 설정이 일치하지 않는 경우. proxy가 origin이 HTTPS를 요구하는데 HTTP를 사용하거나, 잘못된 port 또는 backend에 연결할 수 있습니다.
4. TLS 설정이 호환되지 않거나 잘못 구성된 경우. 지원되지 않는 protocol version, 지나치게 제한적인 cipher 설정, SNI routing 문제 또는 잘못 구성된 TLS termination 장치로 인해 인증서 검증 전에 handshake가 중단될 수 있습니다.
5. 인증서 또는 chain을 사용할 수 없는 경우. 만료된 인증서, 누락된 intermediate 인증서 또는 요청한 hostname을 포함하지 않는 인증서로 인해 secure connection이 차단될 수 있습니다. 일부 브라우저와 connection 경로에서는 대신 더 구체적인 인증서 경고가 표시됩니다.
6. 갱신된 인증서가 service에 로드되지 않은 경우. 디스크의 인증서 파일을 업데이트해도 실행 중인 web server가 제공하는 인증서는 변경되지 않습니다. service의 문서화된 절차에 따라 설정을 reload하거나 restart해야 합니다.

해결 방법

1. 문제가 public, origin 전용 또는 local인지 확인

두 번째 network 또는 device에서 문제가 발생한 정확한 hostname을 시도하세요. 한 대의 컴퓨터에서만 실패한다면 local 보안 software, interception proxy 및 system time을 확인하세요. 모든 client에서 실패한다면 server, proxy, CDN 또는 load balancer를 계속 조사하세요.

HTTP는 작동하지만 HTTPS가 작동하지 않는다면 TLS listener, port 443, 인증서 선택 및 client와 origin 사이의 proxy에 집중하세요. HTTP가 성공한다고 해서 HTTPS 설정이 올바르다고 가정하지 마세요.

2. 서버 상태를 변경하지 않고 TLS handshake 테스트

endpoint에 network access가 있는 관리자용 terminal에서 다음 명령을 실행하세요.

openssl s_client -connect [your-hostname]:443 -servername [your-hostname] -showcerts

SNI가 인증서 또는 virtual host를 선택하는 경우 -servername option이 중요합니다. handshake가 시작되는지, 어떤 인증서가 반환되는지, 인증서 만료일, Subject Alternative Name hostname 및 intermediate 인증서가 포함되어 있는지를 기록하세요.

• 연결에서 일반 HTTP가 반환되거나 인증서가 나타나기 전에 실패하면 port 443 listener와 proxy routing을 확인하세요.
• 인증서가 반환되면 요청한 hostname과 비교하고 유효 기간 및 chain을 확인하세요.
• 직접 origin 테스트는 성공하지만 public hostname이 실패하면 애플리케이션을 변경하지 말고 CDN, reverse proxy, load balancer 또는 DNS 경로를 조사하세요.

3. HTTPS listener 및 hostname routing 확인

적절한 서버 access와 authorization이 있는 상태에서 활성 web server 설정을 검사하고 다음을 확인하세요.

• 의도한 service가 port 443에서 수신하고 있는지;
• HTTPS server block 또는 virtual host가 활성화되어 있는지;
• 요청한 hostname이 관련 server_name 또는 ServerName/ServerAlias 설정에 포함되어 있는지;
• 해당 listener에서 TLS가 활성화되어 있는지;
• 인증서 및 private-key 경로가 의도한 파일을 가리키는지.

Nginx에서는 활성화된 server block과 listen 443 ssl 설정을 확인하세요. Apache에서는 <VirtualHost *:443> 설정과 SSLEngine on을 확인하세요. 설치된 server가 지원하는 syntax와 version을 확인하지 않은 채 제품 간 directive를 복사하지 마세요.

4. 인증서 및 chain 검증

제공된 인증서가 다음 조건을 충족하는지 확인하세요.

• 만료되지 않았고 유효 시작 시점 이전가 아닌지;
• Subject Alternative Name 항목에 정확한 hostname이 포함되어 있는지;
• 해당 private key와 일치하는지;
• 필요한 intermediate 인증서 chain이 함께 제공되는지.

bare domain용 인증서가 모든 subdomain을 자동으로 포함하는 것은 아닙니다. subdomain은 명시적으로 나열되어 있거나 적절한 wildcard 인증서로 포함되어야 합니다. 서버가 leaf 인증서만 제공한다면 certificate authority가 제공한 chain file을 web server가 요구하는 형식으로 설치하세요.

5. 갱신 및 인증서 로드 확인

Certbot으로 관리되는 deployment에서는 관리자가 certbot renew --dry-run을 실행하여 production 인증서를 발급하지 않고 갱신 workflow를 테스트할 수 있습니다. 출력, 갱신 설정, permission 및 service의 reload hook을 검토하세요.

갱신은 성공했지만 client가 여전히 이전 인증서를 받는다면 web server 또는 TLS를 termination하는 proxy가 새 파일을 로드했는지 확인하세요. reload 또는 restart는 service 상태를 변경하므로 승인된 maintenance window에서 rollback plan과 제품의 문서화된 절차에 따라 수행해야 합니다. 이 운영 작업은 read-only 진단과 분리하세요.

6. CDN, proxy 및 load balancer의 TLS 설정 검사

TLS가 어디에서 termination되는지 확인하세요. CDN, edge proxy, load balancer 또는 origin server일 수 있습니다. 구성된 origin protocol과 port가 origin에서 실제로 제공하는 것과 일치하는지 확인하세요.

CDN에서 Flexible, Full 또는 Full (strict)와 같은 mode를 제공한다면 origin의 실제 설정 및 인증서 유효성에 맞는 mode를 선택하세요. 덜 엄격한 mode는 근본적인 문제를 숨기거나 다른 오류를 만들 수 있으며, 유효한 origin 인증서를 대신할 영구적인 해결책이 아닙니다. authorization이 있을 때만 설정을 변경한 다음, 가능한 경우 public hostname과 origin 경로를 모두 다시 테스트하세요.

7. protocol, SNI 또는 network device 간섭 확인

endpoint가 유효하고 일치하는 인증서를 제공하지만 handshake가 계속 실패한다면 서로 다른 network와 TLS client에서 결과를 비교하세요. firewall, load balancer, web application firewall 및 TLS inspection 설정에서 차단된 protocol version, 지원되지 않는 cipher policy, 잘못된 SNI routing 또는 변경된 traffic이 있는지 검토하세요. hosting provider 또는 network administrator에게 전달할 수 있도록 handshake 출력과 관련 server log를 보존하세요.

예방 및 해결 확인 방법

• 갱신 mechanism과 별도로 인증서 만료를 모니터링하고 인증서가 무효화되기 전에 alert를 설정하세요.
• non-production 또는 dry-run workflow에서 갱신을 테스트하고 service reload hook이 실제로 새 인증서를 제공하는지 확인하세요.
• 모든 hostname, TLS termination 지점, 인증서, private key 및 intermediate chain의 문서화된 inventory를 유지하세요.
• 인증서, proxy, load balancer 또는 port mapping을 변경한 후 public hostname과 중요한 각 subdomain을 테스트하세요.
• 배포 전에 TLS 설정 변경 사항이 SNI, protocol version, cipher 및 origin port와 호환되는지 검토하세요.
• 최근 server, proxy 및 인증서 세부 정보를 보관하여 실패한 handshake를 마지막으로 정상 작동한 설정과 비교할 수 있도록 하세요.

자주 묻는 질문