SSL/TLS는 인터넷에서 가장 널리 사용되는 암호화 프로토콜입니다. 기술적으로 TLS는 SSL의 후속 버전이지만 이 문서에서와 같이 두 용어가 같은 의미로 사용되는 경우가 있습니다.
전송 계층 보안(TLS)은 네트워크를 통해 정보가 전송되는 동안 암호화하는 데 사용되며 클라이언트와 서버 또는 부하 분산기 간의 개인정보 보호를 제공합니다. SSL을 사용하는 애플리케이션 부하 분산기 또는 프록시 네트워크 부하 분산기에는 비공개 키와 SSL 인증서가 하나 이상 필요합니다.
인증서 구성 방법
대상 HTTPS 프록시를 사용하는 애플리케이션 부하 분산기의 경우 부하 분산기의 대상 프록시가 1~15개의 Compute Engine SSL 인증서를 참조해야 합니다. 각 Compute Engine SSL 인증서 리소스에는 비공개 키, 해당 인증서, CA 인증서(선택사항)가 포함됩니다.
부하 분산기 지원
다음 표에는 각 부하 분산기에서 지원하는 인증서 구성 방법이 나와 있습니다.
부하 분산기 | 인증서 구성 방법: 대상 프록시 참조... | |||
---|---|---|---|---|
Compute Engine SSL 인증서 | Certificate Manager 인증서 맵 | Certificate Manager 인증서로 직접 | ||
애플리케이션 부하 분산기(대상 HTTPS 프록시) | ||||
리전 외부 애플리케이션 부하 분산기 | 리전 인증서 자체 관리형 Google 관리형 지원 |
자체 관리형 Google 관리형 |
||
리전 내부 애플리케이션 부하 분산기 | 리전 인증서 자체 관리형 Google 관리형 지원 |
자체 관리형 Google 관리형 |
인증서 유형
부하 분산기에 자체 관리형 SSL 인증서를 만들 수 있습니다.
자체 관리형 SSL 인증서
자체 관리형 SSL 인증서는 사용자가 직접 가져와 프로비저닝하고 갱신하는 인증서입니다. 자체 관리형 인증서는 다음 공개키 인증서 유형 중 하나일 수 있습니다.
- 도메인 유효성 검사(DV)
- 조직 유효성 검사(OV)
- 확장 유효성 검사(EV) 인증서
Compute Engine SSL 인증서 리소스를 사용하여 자체 관리형 SSL 인증서를 만들 수 있습니다. 자세한 내용은 자체 관리형 SSL 인증서 사용을 참조하세요.
여러 SSL 인증서
애플리케이션 부하 분산기의 대상 프록시는 최대 15개의 Compute Engine SSL 인증서를 참조할 수 있습니다. 첫 번째로 참조된 Compute Engine SSL 인증서 리소스는 대상 프록시의 기본(주요) 인증서입니다.
자세한 내용은 부하 분산 문서의 대상 프록시 및 SSL 인증서를 참조하세요.
인증서 선택 프로세스
다음 인증서 선택 프로세스는 대상 프록시가 여러 Compute Engine SSL 인증서를 참조하는 부하 분산기에 적용됩니다.
클라이언트가 부하 분산기에 연결하면 클라이언트와 부하 분산기가 TLS 세션을 협상합니다. TLS 세션 협상 중에 클라이언트는 ClientHello
에서 지원하는 TLS 암호화 목록을 부하 분산기에 전송합니다. 부하 분산기는 공개 키 알고리즘이 클라이언트와 호환되는 인증서를 선택합니다. 클라이언트는 이 협상의 일부로 서버 이름 표시(SNI) 호스트 이름을 부하 분산기에 보낼 수도 있습니다. SNI 호스트 이름 데이터는 부하 분산기가 클라이언트에 보낼 인증서를 선택하는 데 도움이 되는 경우가 있습니다.
부하 분산기의 대상 프록시가 인증서를 하나만 참조하는 경우 해당 인증서가 사용되며 클라이언트에서 전송한 SNI 호스트 이름 값은 관련이 없습니다.
부하 분산기의 대상 프록시가 두 개 이상의 인증서를 참조하는 경우 부하 분산기는 다음 프로세스를 사용하여 단일 인증서를 선택합니다.
클라이언트가
ClientHello
에서 SNI 호스트 이름을 보내지 않으면 부하 분산기는 인증서 목록의 첫 번째 인증서를 사용합니다.클라이언트가 인증서 일반 이름(CN)과 일치하지 않고 인증서 주체 대체 이름(SAN)과 일치하지 않는 SNI 호스트 이름을 보내는 경우 부하 분산기는 인증서 목록의 첫 번째 인증서를 사용합니다.
그 외의 모든 상황: 부하 분산기는 다음과 같은 일치 프로세스를 사용하여 인증서를 선택합니다.
일치는 RSA 인증서보다 ECDSA 인증서를 선호하며 일반 이름(CN)과 주체 대체 이름(SAN) 인증서 속성 모두에 대해 가장 긴 서픽스를 사용하여 수행됩니다.
일치하는 방법을 설명하기 위해 다음 두 인증서를 참조하는 대상 프록시를 살펴보겠습니다.
인증서 A
- CN:
cats.pets.example.com
- SAN:
cats.pets.example.com
,*.pets.example.com
,*.example.com
- CN:
인증서 B
- CN:
dogs.pets.example.com
- SAN:
dogs.pets.example.com
,*.pets.example.com
,*.example.com
- CN:
이제 다음 시나리오를 고려해 보세요.
- 클라이언트에서 전송한 SNI 호스트 이름이
cats.pets.example.com
인 경우 부하 분산기는 인증서 A를 사용합니다. - 클라이언트에서 전송한 SNI 호스트 이름이
ferrets.pets.example.com
인 경우 정확한 일치가 없으므로 부하 분산기는 인증서 A 또는 인증서 B 중 하나를 선택합니다. 두 인증서 모두 SAN 목록에*.pets.example.com
이 포함되어 있기 때문입니다. 이 경우 선택된 인증서를 제어할 수 없습니다.
- 클라이언트에서 전송한 SNI 호스트 이름이
인증서가 선택된 후 부하 분산기는 선택된 인증서가
ClientHello
에서 클라이언트가 보낸 암호화와 호환되는 공개 키 알고리즘을 사용하는 경우에만 클라이언트에 해당 인증서를 전송합니다. 부하 분산기가 선택한 인증서의 공개 키 알고리즘(ECDSA 또는 RSA)을 포함하는 암호화 스위트를 클라이언트가 지원하지 않으면 TLS 협상이 실패합니다.