인증서 관리자는 할당할 수 있는 인증서와 사용자 환경의 각 도메인 이름에 대한 인증서 제공 방법을 세밀하게 제어할 수 있게 해주는 유연한 매핑 메커니즘을 사용합니다. 이 메커니즘에는 다음 항목이 포함됩니다.
- 인증서
- 인증서 맵
- 인증서 맵 항목
- 도메인 승인
다음 다이어그램에서는 부하 분산기 전달 규칙에 지정된 일반적인 대상 프록시의 이러한 항목 간의 관계를 보여줍니다.
인증서 관리자는 대상 HTTPS 프록시와 대상 SSL 프록시를 지원합니다. 이러한 프록시 유형 간 차이점에 대한 자세한 내용은 대상 프록시 사용을 참조하세요.
인증서 관리자가 지정하는 인증서 유형에 대한 자세한 내용은 배포 개요를 참조하세요.
인증서
기본적으로 인증서는 특정 도메인 이름 또는 도메인 와일드 카드에 발급된 단일 X.509 전송 계층 보안(TLS)(SSL) 인증서를 나타냅니다.
인증서 관리자는 다음과 같은 인증서 유형을 지원합니다.
- Google 관리형 인증서는 Google Cloud가 가져오고 관리하는 인증서입니다.
- 자체 관리형 SSL 인증서는 사용자가 직접 가져와 프로비저닝하고 갱신하는 인증서입니다.
공개적으로 신뢰할 수 있는 CA를 사용하여 인증서를 발급하면 CA는 공개적으로 액세스할 수 있는 인증서 투명성 로그에 연결된 도메인 관련 정보를 게시합니다. 이는 공개적으로 신뢰할 수 있는 모든 CA에서 채택하는 표준 인증서 발급 프로세스의 일부이며 Google 관리형 인증서와 자체 관리형 인증서 모두에 적용됩니다. 하지만 Certificate Authority Service를 사용하여 Google 관리형 인증서를 발급하려는 경우 인증서 관리자는 인증서 투명성 로그에 어떠한 정보도 게시하지 않습니다.
자세한 내용은 인증서 투명성을 참조하세요.
인증서 관리자로 인증서를 배포하는 방법은 배포 개요를 참조하세요.
Google 관리형 인증서
웹사이트 및 애플리케이션의 Google 관리형 TLS(SSL) 인증서 관리는 수동 구성과 정기적인 유지보수가 포함된 복잡하고 시간이 오래 걸리는 태스크일 수 있습니다. 인증서 관리자는 중앙화된 플랫폼을 제공하여 이 프로세스를 간소화하는 데 도움이 되도록 설계된 서비스입니다. 인증서 발급 및 갱신 책임을 인증서 관리자에게 위임하여 다른 중요한 태스크에 집중할 시간을 확보할 수 있습니다.
부하 분산기 기반 또는 DNS 기반 승인을 사용하여 관련 도메인 소유권을 확인할 수 있습니다. 인증서 관리자는 RSA Google 관리 인증서를 지원합니다.
기본적으로 Google CA에서 Google 관리 인증서를 발급합니다. 새 Google 관리형 인증서가 발급되거나 갱신될 때 새로 생성된 비공개 키를 사용합니다. 특정 도메인에 대해 Google CA에서 인증서를 가져올 수 없는 경우 인증서 관리자는 Let's Encrypt CA로 돌아갑니다. 예를 들어 Google CA가 인증서 발급을 거부할 수 있거나 CA 승인 레코드로 인해 해당 도메인에서 Google CA의 인증서 발급이 명시적으로 금지됩니다.
클라이언트 측 전용 인증은 지원되지 않습니다.
도메인의 인증서를 발급할 수 있는 CA를 제한하는 방법은 Google 관리 인증서를 발급할 수 있는 CA 지정을 참조하세요.
리전별 Google 관리형 인증서는 DNS 기반 승인만 지원하며 Google CA에서 인증서를 가져옵니다.
Certificate Authority Service에서 발급한 Google 관리형 인증서
Google에서 승인한 Public CA를 사용해 인증서를 발급하는 대신 자체 신뢰 체인을 사용하려는 경우 Certificate Authority Service의 CA 풀을 인증서 발급기관으로 대신 사용하도록 구성하면 됩니다. CA 풀에 대한 자세한 내용은 CA 풀 만들기를 참조하세요.
자체 관리형 인증서
비즈니스 요구사항에 따라 Google 관리형 인증서 사용이 허용되지 않는 경우 해당 연결된 키와 함께 외부 CA에서 발급된 인증서를 업로드할 수 있습니다. 자체 관리형 인증서를 수동으로 발급하고 갱신할 책임은 사용자에게 있습니다.
인증서 관리자를 사용하면 보안 웹 프록시 프록시 및 리전 부하 분산기(미리보기)에 리전별 자체 관리형 인증서를 배포할 수도 있습니다.
인증서 맵
인증서 맵은 특정 인증서를 특정 호스트 이름에 할당하는 하나 이상의 인증서 맵 항목을 참조합니다. 인증서 맵 항목은 클라이언트 연결을 설정할 때 부하 분산기가 따르는 선택 로직도 정의합니다. 여러 부하 분산기에서 재사용할 수 있도록 인증서 맵을 여러 대상 프록시와 연결할 수 있습니다.
클라이언트가 인증서 맵에 지정된 호스트 이름을 요청하면 부하 분산기는 해당 호스트 이름에 매핑된 인증서를 제공합니다. 그렇지 않으면 부하 분산기가 기본 인증서를 제공합니다. 자세한 내용은 인증서 선택 로직을 참조하세요.
인증서 맵 항목
인증서 맵 항목은 특정 도메인 이름에 제공되는 인증서 목록입니다. 도메인 또는 하위 도메인과 같은 여러 도메인 이름에 서로 다른 인증서 집합을 정의할 수 있습니다. 예를 들어 ECDSA 및 RSA 인증서를 업로드하고 동일한 도메인 이름에 매핑할 수 있습니다. 클라이언트가 해당 도메인 이름에 연결하면 부하 분산기는 핸드셰이크 도중 클라이언트에 제공할 인증서 유형을 협상합니다.
도메인 승인
인증서 관리자를 사용하면 다음 표에 설명된 대로 Google 관리형 인증서를 발급할 도메인의 소유권을 증명할 수 있습니다.
| 부하 분산기 승인 | DNS 승인 | |
|---|---|---|
| 설정 난이도 | DNS 구성에 추가 구성 단계나 변경이 필요하지 않습니다. | DNS 승인을 만들고 해당 CNAME 레코드를 DNS 구성에 추가해야 합니다. |
| 네트워크 보안 | 부하 분산기는 인증서에서 제공하는 모든 도메인의 DNS 구성을 포함하여 포트 443의 인터넷에서 완전히 액세스할 수 있어야 합니다. 다른 구성에서는 작동하지 않습니다. | 443 이외의 포트 및 대상 프록시 앞에 있는 CDN 레이어와 같은 복잡성이 높은 구성에서 작동합니다. |
| 프로비저닝 속도 | 부하 분산기가 완전히 설정되고 네트워크 트래픽을 제공한 후에만 인증서를 프로비저닝할 수 있습니다. | 대상 프록시가 네트워크 트래픽을 제공할 준비가 되기 전에 인증서를 미리 프로비저닝할 수 있습니다. |
인증서 관리자가 각 방법을 사용하여 도메인 소유권을 확인하는 방법은 Google 관리형 인증서의 도메인 승인을 참조하세요.
인증서 발급 구성
인증서 발급 구성은 인증서 관리자가 자체 Certificate Authority Service 인스턴스의 CA 풀을 사용하여 Google CA 또는 Let's Encrypt CA대신 Google 관리형 인증서를 발급할 수 있게 해주는 리소스입니다. 이를 통해 는 인증서 발급 및 만료를 관리하는 다양한 파라미터를 지정하고 이러한 방식으로 발급된 인증서의 키 알고리즘을 선택할 수 있습니다.
트러스트 구성
트러스트 구성은 상호 TLS 인증 시나리오에 사용할 인증서 관리자의 공개 키 인프라(PKI) 구성을 나타내는 리소스입니다. 단일 트러스트 저장소를 캡슐화하고 차례로 신뢰 앵커와 하나 이상의 중간 인증서(선택사항)를 캡슐화합니다.
상호 TLS 인증에 대해 자세히 알아보려면 Cloud Load Balancing 문서의 상호 TLS 인증을 참조하세요.
트러스트 구성 리소스는 트러스트 저장소, 신뢰 앵커, 중간 인증서 항목을 캡슐화합니다.
트러스트 저장소
트러스트 저장소는 상호 TLS 인증 시나리오에 사용할 인증서 관리자의 트러스트 보안 비밀 구성을 나타냅니다. 단일 신뢰 앵커와 하나 이상의 중간 인증서(선택사항)를 캡슐화합니다.
신뢰 앵커
신뢰 앵커는 상호 TLS 인증 시나리오에 사용할 단일 루트 인증서를 나타냅니다. 트러스트 저장소 내에 캡슐화됩니다.
중간 인증서
중간 인증서는 루트 인증서나 상호 TLS 인증 시나리오에 사용하기 위해 캡슐화 트러스트 저장소에서 참조되는 중간 인증서로 서명한 단일 중간 인증서를 나타냅니다.
PKI 구성에 따라 하나 이상의 중간 인증서를 트러스트 저장소 내에 캡슐화할 수 있습니다. 트러스트 구성 내에 지정된 모든 중간 인증서는 요청 자체에 지정된 중간 인증서 목록 외에도 모든 연결 요청에 대한 트러스트 평가의 일부로 포함됩니다.
허용 목록이 필요한 인증서
선택적으로 자체 서명되었거나, 만료되었거나, 유효하지 않은 인증서를 사용해야 하는 경우 또는 루트 및 중간 인증서에 대한 액세스 권한이 없는 경우 해당 인증서를 allowlistedCertificates 필드의 트러스트 구성에 추가할 수 있습니다. 허용 목록에 인증서를 추가하기 위해 트러스트 저장소가 필요하지 않습니다.
허용 목록에 인증서를 추가하면 인증서가 파싱 가능하고, 비공개 키 소유 증명이 설정되었으며, 인증서의 SAN 필드에 대한 제약조건이 충족되는 한 인증서가 항상 유효한 것으로 간주됩니다.
인증서 선택 로직
대략적으로 부하 분산기는 다음과 같이 인증서를 선택합니다.
- 클라이언트가 핸드셰이크를 시작합니다. 이 단계에서는 부하 분산기에 핸드셰이크를 완료하는 데 사용할 수 있는 암호화 알고리즘 목록과 호스트 이름(선택사항)을 제공합니다.
부하 분산기는 클라이언트가 제공하는 호스트 이름과 구성된 인증서 맵 항목을 기반으로 보안 핸드셰이크를 완료하기 위해 인증서를 선택합니다. 부하 분산기가 선택하는 인증서를 결정하는 요소는 다음과 같습니다.
정확한 호스트 이름 일치: 클라이언트가 프로비저닝된 인증서 맵의 항목과 정확하게 일치하는 호스트 이름을 제공하는 경우 부하 분산기에서 해당 인증서를 선택합니다.
와일드 카드 호스트 이름 일치: 클라이언트의 호스트 이름이 어떤 항목과도 일치하지 않지만 인증서 맵 항목의 와일드 카드 호스트 이름과 일치하는 경우, 부하 분산기는 해당 항목에서 인증서를 선택합니다. 예를 들어
*.myorg.example.com으로 구성된 와일드 카드 항목은myorg.example.com도메인 아래의 첫 번째 수준 하위 도메인을 포괄합니다.호스트 이름 일치 없음 및 사전 구성된 기본 인증서 맵 항목: 호스트 이름 일치 또는 일치하는 프로비저닝된 인증서 맵 항목이 없으면 부하 분산기는 사전 구성된 기본 인증서 맵 항목을 선택합니다.
핸드셰이크 실패: 다음과 같은 이유로 부하 분산기가 일치하는 인증서를 찾을 수 없는 경우 핸드셰이크가 실패합니다.
- 클라이언트가 프로비저닝된 모든 인증서 맵 항목에 지정된 일치 또는 와일드 카드 호스트 이름과 일치하지 않거나 호스트 이름을 전혀 제공하지 않는 호스트 이름을 제공합니다.
- 일치하는 기본 인증서 맵 항목이 없거나 기본 인증서 맵 항목을 구성하지 않은 경우입니다.
인증서 우선순위
부하 분산기는 다음을 기반으로 인증서 맵 항목 내에서 인증서를 선택합니다.
- 인증서 유형. 연결 클라이언트가 보다 안전한 ECDSA 인증서를 지원하는 경우 부하 분산기는 RSA 인증서보다 이를 더 우선시합니다. 클라이언트가 ECDSA 인증서에 대한 지원을 나타내지 않으면 부하 분산기는 대신 RSA 인증서를 제공합니다.
- 인증서 크기. 부하 분산기는 가장 작은 인증서부터 가장 큰 인증서의 우선순위를 지정합니다.
와일드 카드 도메인 이름
와일드 카드 도메인 이름에는 다음 규칙이 적용됩니다.
- DNS 승인을 사용하는 Google 관리형 인증서와 CA 서비스를 사용하는 Google 관리형 인증서만 와일드 카드 도메인 이름을 지원합니다. 부하 분산기 승인을 사용하는 Google 관리형 인증서는 와일드 카드 도메인 이름을 지원하지 않습니다.
- 항목에 둘 다 정의된 경우 일치검색이 와일드 카드보다 우선 적용됩니다. 예를 들어
www.myorg.example.com및*.myorg.example.com에 대한 인증서 맵 항목을 구성한 경우www.myorg.example.com에 대한 연결 요청은*.myorg.example.com항목이 있더라도 항상www.myorg.example.com의 항목을 선택합니다. - 와일드 카드 도메인 이름은 하나의 하위 도메인 수준에서만 일치합니다. 예를 들어
host1.myorg.example.com에 대한 연결 요청은host1.hosts.myorg.example.com에 대한 것이 아닌*.myorg.example.com에 대한 인증서 맵 항목을 선택합니다.
Public CA
인증서 관리자의 Public CA 기능을 사용하려면 다음 개념을 잘 알고 있어야 합니다.
ACME 클라이언트. 자동 인증서 관리 환경(ACME) 클라이언트는 ACME 프로토콜을 사용하는 인증서 관리 클라이언트입니다. ACME 클라이언트는 Public CA에서 작업하려면 외부 계정 바인딩(EAB)을 지원해야 합니다.
외부 계정 바인딩(EAB) 인증서 관리자 Public CA와 함께 사용 중인 각 ACME 계정을 외부 계정 바인딩을 사용하여 대상 Google Cloud 프로젝트에 결합해야 합니다. 이렇게 하려면 해당 Google Cloud 프로젝트에 연결된 보안 비밀을 사용하여 각 ACME 계정을 등록해야 합니다. 자세한 내용은 외부 계정 바인딩을 참조하세요.
Public CA 챌린지
Public CA를 사용하여 인증서를 요청하면 인증서 관리자가 해당 인증서에 나열된 도메인에 대한 제어 권한을 증명하도록 요청합니다. 챌린지를 해결하여 도메인 제어를 증명할 수 있습니다. Public CA에서는 대상 도메인의 제어 권한이 증명된 후 도메인 이름을 승인합니다.
필요한 승인을 받은 후에는 특정 기간 동안만 유효한 인증서를 요청할 수 있습니다. 이 기간이 지나면 세 가지 챌린지 유형 중 하나를 해결하여 도메인 이름을 다시 검증하여 인증서를 계속 요청해야 합니다.
로그인 질문 유형
Public CA는 다음 유형의 챌린지를 지원합니다.
HTTP 챌린지. 이 챌린지를 수행하려면 Public CA가 검색하고 확인할 수 있도록 HTTP 서버(포트 80)의 잘 알려진 위치에 파일을 만들어야 합니다. 자세한 내용은 HTTP 챌린지를 참조하세요.
TLS-애플리케이션 레이어 프로토콜 협상(ALPN) 챌린지. 포트 443의 TLS 협상 중에 특정 도메인에 대한 제어를 증명하기 위해 서버에서 특정 인증서를 제공해야 합니다. 자세한 내용은 ACME TLS-ALPN 챌린지 확장 프로그램을 참조하세요.
DNS 챌린지. 정의된 위치에 특정 DNS 레코드를 추가하여 도메인에 대한 제어를 증명해야 합니다. 자세한 내용은 DNS 챌린지를 참조하세요.
HTTP 챌린지 또는 TLS-ALPN 챌린지를 사용하여 도메인 이름을 검증하면 클라이언트는 검증된 도메인 이름만 인증서에 포함하도록 요청할 수 있습니다. DNS 챌린지를 사용하는 경우 클라이언트가 해당 도메인 이름의 하위 도메인을 인증서에 포함하도록 요청할 수도 있습니다.
예를 들어 DNS 챌린지를 사용하여 *.myorg.example.com을 검증하면 subdomain1.myorg.example.com 및 subdomain2.myorg.example.com에는 와일드 카드 인증서가 자동으로 적용됩니다. 그러나 HTTP 또는 TLS-ALPN 챌린지를 사용하여 myorg.example.com을 검증하면 클라이언트는 인증서에 myorg.example.com을 포함하도록 요청만 할 수 있으며 DNS 이외의 챌린지를 사용하여 *.myorg.example.com을 검증할 수 없습니다.
챌린지 솔루션 로직
Public CA 챌린지 로직은 다음과 같습니다.
- Public CA는 무작위 토큰을 제공합니다.
- 클라이언트가 잘 정의된 위치에서 토큰을 사용할 수 있도록 합니다. 위치는 챌린지에 따라 다릅니다.
- 클라이언트가 챌린지가 준비되었음을 Public CA에 알립니다.
- Public CA는 예상 위치에 있는 토큰이 예상 값과 일치하는지 확인합니다.
이 프로세스가 완료되면 도메인 이름이 승인됩니다. 클라이언트는 해당 도메인 이름이 포함된 인증서를 요청할 수 있습니다. 도메인 이름당 하나의 챌린지만 해결하면 됩니다.