핸드셰이크 중에 클라이언트는 부하 분산기에 클라이언트가 핸드셰이크를 완료하는 데 사용하는 암호화 알고리즘 목록과 연결하려는 호스트 이름(선택사항)을 제공합니다. 이 호스트 이름을 서버 이름 표시 (SNI)라고도 합니다.
부하 분산기는 요청을 수신하면 보안 핸드셰이크를 완료하기 위해 인증서를 선택합니다.
정확한 호스트 이름 일치: 클라이언트가 제공한 호스트 이름이 프로비저닝된 인증서 맵의 호스트 이름 항목과 정확하게 일치하는 경우 부하 분산기에서 해당 인증서를 선택합니다.
와일드 카드 호스트 이름 일치: 클라이언트의 호스트 이름이 프로비저닝된 인증서 맵의 호스트 이름 항목과 일치하지 않지만 인증서 맵 항목의 와일드 카드 호스트 이름과 일치하는 경우 부하 분산기는 해당 인증서를 선택합니다.
예를 들어 *.myorg.example.com으로 구성된 와일드 카드 항목은 myorg.example.com 도메인의 첫 번째 수준 하위 도메인을 포괄합니다. 와일드 카드 항목은 sub.subdomain.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에 대한 인증서 맵 항목을 선택합니다.
인증서 갱신
Google 관리형 인증서는 자동으로 갱신됩니다. 자체 관리형 인증서는 수동으로 갱신해야 합니다. 필요한 경우 인증서가 만료되기 전에 Cloud Logging 알림을 구성할 수 있습니다. 자세한 내용은 로그 알림 구성을 참고하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eCertificate Manager provides granular control over certificate assignment and serving for each domain name.\u003c/p\u003e\n"],["\u003cp\u003eThe load balancer selects certificates based on exact hostname match, wildcard hostname match, or the primary certificate map entry if no matches are found.\u003c/p\u003e\n"],["\u003cp\u003eThe load balancer prioritizes certificates based on type (ECDSA over RSA) and size (smaller certificates are preferred).\u003c/p\u003e\n"],["\u003cp\u003eWildcard domain names in Google-managed certificates with DNS or CA Service authorization only match the first level of subdomains, and exact matches take precedence over wildcards.\u003c/p\u003e\n"],["\u003cp\u003eGoogle-managed certificates are renewed automatically, while self-managed certificates require manual renewal.\u003c/p\u003e\n"]]],[],null,["# How Certificate Manager works\n\nCertificate Manager uses a flexible mapping mechanism that provides you\nwith granular control over which certificates you can assign and how to serve\nthem for each domain name in your environment.\n\nThe following diagram shows the relationships between\nCertificate Manager components for a typical target proxy specified in\na load balancer forwarding rule:\n[](/static/certificate-manager/images/cm-entities.svg) Certificate Manager entities (click to enlarge).\n\nTo learn more about the components of Certificate Manager, see [Core\ncomponents](/certificate-manager/docs/how-it-works).\n\nCertificate selection logic\n---------------------------\n\nAt a high level, the load balancer selects a certificate as follows:\n\n1. A client initiates a handshake, which is a connection request to the\n service behind the load balancer.\n\n During the handshake, the client provides the load balancer a list of\n cryptographic algorithms that the client uses to complete the\n handshake, and, optionally, the hostname it is trying to reach. This\n hostname is also called Server Name Indication (SNI).\n2. On receiving the request, the load balancer selects a certificate to\n complete the secure handshake.\n\n - **Exact hostname match**: if the client's provided hostname exactly\n matches a hostname entry in the provisioned certificate map, the load\n balancer selects the corresponding certificate.\n\n - **Wildcard hostname match**: if the client's hostname doesn't match any\n one of the hostname entries in the provisioned certificate map, but\n does match a wildcard hostname in a certificate map entry, the load\n balancer selects the corresponding certificate.\n\n For example, a wildcard entry configured as `*.myorg.example.com` covers\n first-level subdomains in the `myorg.example.com` domain. The wildcard\n entry doesn't cover deeper level subdomains, such as\n `sub.subdomain.myorg.example.com`.\n - **No exact or wildcard hostname match**: if the client's hostname\n doesn't match any one of the hostname entries in the provisioned\n certificate map, the load balancer selects the primary certificate map\n entry.\n\n - **Handshake failure**: if the client didn't provide a hostname and the\n primary certificate map entry isn't configured, the handshake fails.\n\n| **Note:** A Google-managed certificate must complete provisioning before the load balancer can serve the certificate.\n\n### Certificate priority\n\nWhen selecting a certificate, the load balancer prioritizes them based on the\nfollowing factors:\n\n- **Certificate type**. If the client supports the ECDSA certificates, the load balancer prioritizes them over RSA certificates. If the client doesn't support ECDSA certificates, the load balancer serves an RSA certificate instead.\n- **Certificate size**. Because smaller certificates take less bandwidth, the load balancer prioritizes smaller certificates over larger ones.\n\n### Wildcard domain names\n\nThe following rules apply to wildcard domain names:\n\n- Only Google-managed certificates with DNS authorization and Google-managed certificates with CA Service support wildcard domain names. Google-managed certificates with load balancer authorization don't support wildcard domain names.\n- An exact match takes precedence over a wildcard when both are defined in the entry. For example, if you configured certificate map entries for `www.myorg.example.com` and `*.myorg.example.com`, a connection request against `www.myorg.example.com` always selects the entry for `www.myorg.example.com` even if an entry for `*.myorg.example.com`also exists.\n- Wildcard domain names only match the first level of subdomains. For example, a connection request for `host1.myorg.example.com` selects a certificate map entry for `*.myorg.example.com` but not one for `host1.hosts.myorg.example.com`.\n\nCertificate renewal\n-------------------\n\nGoogle-managed certificates are renewed automatically. You must renew\nself-managed certificates manually. If necessary, you can configure\nCloud Logging alerts for certificates before they expire. For more\ninformation, see [Configure log\nalerts](/certificate-manager/docs/logs-metrics#configure_log_alerts).\n\nWhat's next\n-----------\n\n- [Domain authorization types for Google-managed certificates](/certificate-manager/docs/domain-authorization)"]]
