자체 관리형 SSL 인증서 사용

자체 관리형 SSL 인증서는 사용자가 직접 가져와 프로비저닝하고 갱신하는 인증서입니다. 이 리소스를 사용하여 클라이언트와 부하 분산기 간의 통신을 보호할 수 있습니다.

자체 관리형 인증서는 다음 인증서 유형을 모두 조합할 수 있습니다.

• 도메인 유효성 검사(DV)
• 조직 유효성 검사(OV)
• 확장 유효성 검사(EV)

자체 관리형 인증서는 다음 부하 분산기에서 지원됩니다.

• 전역 인증서
  • 전역 외부 애플리케이션 부하 분산기
  • 기본 애플리케이션 부하 분산기
  • 외부 프록시 네트워크 부하 분산기(대상 SSL 프록시 사용)
• 리전별 인증서
  • 리전 외부 애플리케이션 부하 분산기
  • 내부 애플리케이션 부하 분산기

이 페이지에서는 유효한 Compute Engine 인증서를 가져온 후 인증서를 업로드하여 Google Cloud SSL 인증서 리소스를 만드는 프로세스를 설명합니다.

인증서 관리자를 사용하여 Google 관리 인증서를 만들려면 배포 개요를 참조하세요.

시작하기 전에

• SSL 인증서 개요를 숙지해야 합니다.
• 자체 관리형 SSL 인증서에 사용할 도메인 이름이 있는지 확인합니다. Cloud Domains를 사용하는 경우 1단계: Cloud Domains를 사용하여 도메인 이름 등록을 참조하세요.

권한

이 가이드의 작업을 수행하려면 프로젝트에서 SSL 인증서를 만들고 수정할 수 있어야 합니다. 다음 중 하나가 참일 때 이 작업을 수행할 수 있습니다.

• 프로젝트 소유자 또는 편집자입니다(roles/owner 또는 roles/editor).
• 프로젝트에서 Compute 보안 관리자 역할(compute.securityAdmin) 및 Compute 네트워크 관리자 역할(compute.networkAdmin)을 모두 갖고 있습니다.
• 사용 중인 부하 분산기의 유형에 따라 프로젝트에서 compute.sslCertificates.* 권한과 compute.targetHttpsProxies.* 및 compute.targetSslProxies.* 중 하나 또는 둘 다 포함하는 프로젝트의 커스텀 역할이 있습니다.

1단계: 비공개 키 및 인증서 만들기

이미 비공개 키와 인증 기관(CA)의 SSL 인증서가 이미 있는 경우 이 섹션을 건너뛰고 SSL 인증서 리소스 만들기로 이동하세요.

비공개 키를 선택하거나 만들기

Google Cloud SSL 인증서에는 비공개 키와 인증서 자체가 모두 PEM 형식으로 포함됩니다. 비공개 키는 다음 기준을 충족해야 합니다.

• PEM 형식이어야 합니다.
• 암호로 보호될 수 없습니다. Google Cloud는 비공개 키를 고유한 암호화된 형식으로 저장합니다.
• 암호화 알고리즘이 RSA-2048 또는 ECDSA P-256이어야 합니다.

새 비공개 키를 만들려면 다음 OpenSSL 명령어 중 하나를 사용합니다.

• RSA-2048 비공개 키를 만듭니다.

  openssl genrsa -out PRIVATE_KEY_FILE 2048
  

• ECDSA P-256 비공개 키를 만듭니다.

  openssl ecparam -name prime256v1 -genkey -noout -out PRIVATE_KEY_FILE
  

PRIVATE_KEY_FILE을 새로운 비공개 키 파일의 경로와 파일 이름으로 바꿉니다.

인증서 서명 요청(CSR) 만들기

비공개 키를 만든 후 OpenSSL을 사용하여 PEM 형식의 인증서 서명 요청(CSR)을 생성할 수 있습니다. CSR은 다음 기준을 충족해야 합니다.

• PEM 형식이어야 합니다.
• 일반 이름(CN) 또는 주체 대체 이름(SAN) 속성이 있어야 합니다. 사실상 macOS 및 iOS의 현재 버전과 같은 최신 클라이언트는 CN 속성에만 의존하지 않으므로 인증서가 단일 도메인에 대한 것이더라도 인증서에 CN 속성과 SAN 속성을 모두 포함해야 합니다.

CSR을 만들려면 다음 단계별 안내를 따르세요.

1. OpenSSL 구성 파일을 만듭니다. 다음 예시에는 주체 대체 이름이 [sans_list]에 정의되어 있습니다.

   cat <<'EOF' >CONFIG_FILE
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   
   [dn_requirements]
   countryName               = Country Name (2 letter code)
   stateOrProvinceName       = State or Province Name (full name)
   localityName              = Locality Name (eg, city)
   0.organizationName        = Organization Name (eg, company)
   organizationalUnitName    = Organizational Unit Name (eg, section)
   commonName                = Common Name (e.g. server FQDN or YOUR name)
   emailAddress              = Email Address
   
   [sans_list]
   DNS.1                     = SUBJECT_ALTERNATIVE_NAME_1
   DNS.2                     = SUBJECT_ALTERNATIVE_NAME_2
   
   EOF
   

2. 다음 OpenSSL 명령어를 실행하여 인증서 서명 요청(CSR) 파일을 만듭니다. 명령어는 대화형이며 이전 단계 CONFIG_FILE의 [sans_list]에서 정의한 주체 대체 이름 외의 속성에 대한 메시지가 나타납니다.

   openssl req -new -key PRIVATE_KEY_FILE \
       -out CSR_FILE \
       -config CONFIG_FILE
   

두 단계 모두에서 다음을 바꿉니다.

• CONFIG_FILE: 파일 이름을 포함한 OpenSSL 구성 파일의 경로(이 절차를 완료한 후에 파일을 삭제할 수 있음)

• SUBJECT_ALTERNATIVE_NAME_1 및 SUBJECT_ALTERNATIVE_NAME_2: 인증서의 주체 대체 이름입니다.

  인증서가 하나의 호스트 이름만을 위한 것인 경우 일반 이름과 일치하는 단일 주체 대체 이름만을 정의해야 합니다. 세 개 이상의 주체 대체 이름이 필요한 경우 DNS(DNS.3, DNS.4 등) 다음에 오는 숫자를 증가시켜 구성 파일에 추가합니다.

• PRIVATE_KEY_FILE: 비공개 키 파일의 경로

• CSR_FILE: CSR의 파일 이름을 포함한 경로

CSR에 서명하기

인증 기관(CA)이 CSR에 서명할 때는 자체 비공개 키를 사용하여 인증서를 만듭니다. 다음 방법 중 하나를 사용하여 CSR에 서명합니다.

공개적으로 신뢰할 수 있는 CA 사용

CSR에 서명하기 위해 공개적으로 신뢰할 수 있는 CA를 요청하면 해당 인증서는 공용 CA를 신뢰하는 모든 클라이언트가 신뢰하게 됩니다. 서명된 인증서를 생성하려면 공용 CA에 CSR만 있으면 됩니다.

자체 내부 CA 사용

자체 CA를 관리하는 경우 이를 사용하여 CSR에 서명할 수 있습니다. CA를 사용하여 CSR에 서명하면 클라이언트가 자체 CA를 신뢰하도록 구성된 경우에도 이렇게 내부적으로 신뢰할 수 있는 인증서를 만듭니다.

자체 서명 인증서 사용

CSR을 만드는 데 사용한 것과 동일한 비공개 키를 사용하여 CSR에 서명하는 경우 자체 서명 인증서가 생성된 것입니다. 자체 서명 인증서는 테스트용으로만 사용해야 합니다.

Google Cloud는 자체 서명 서버 인증서에 대해 클라이언트 측 유효성 검사를 지원하지 않습니다. 따라서 인증서 유효성 검사를 건너뛰도록 클라이언트를 구성해야 합니다. 예를 들어 자체 서명 인증서를 신뢰할지 묻는 메시지를 표시하는 웹브라우저 클라이언트를 만들 수 있습니다.

자체 CA를 관리하는 경우 또는 테스트용 자체 서명 인증서를 만들려면 다음 OpenSSL 명령어를 사용할 수 있습니다.

openssl x509 -req \
    -signkey PRIVATE_KEY_FILE \
    -in CSR_FILE \
    -out CERTIFICATE_FILE \
    -extfile CONFIG_FILE \
    -extensions extension_requirements \
    -days TERM

다음을 바꿉니다.

• PRIVATE_KEY_FILE: CA의 비공개 키 경로입니다. 테스트를 위해 자체 서명 인증서를 만드는 경우 이 비공개 키는 CSR을 만드는 데 사용한 것과 동일합니다.
• CSR_FILE: CSR 경로
• CERTIFICATE_FILE: 만들 인증서 파일의 경로
• TERM: 현재부터 인증서를 확인하는 클라이언트가 인증서를 유효한 것으로 간주해야 하는 기간의 일수입니다.

일반 이름에 와일드 카드 사용

자체 관리형 SSL 인증서는 일반 이름에 와일드 카드를 사용할 수 있습니다. 예를 들어 일반 이름이 *.example.com.인 인증서는 호스트 이름 www.example.com 및 foo.example.com과 일치하지만 a.b.example.com 또는 example.com과는 일치하지 않습니다. 부하 분산기에서 인증서를 선택할 때는 와일드 카드를 사용하는 인증서보다 와일드 카드를 사용하지 않은 인증서와 호스트 이름을 일치시키는 것을 항상 선호합니다.

f*.example.com과 같이 와일드 카드 부분이 포함된 인증서는 지원되지 않습니다.

2단계: 자체 관리형 SSL 인증서 리소스 만들기

Google Cloud SSL 인증서 리소스를 만들려면 먼저 비공개 키와 인증서가 있어야 합니다. 아직 비공개 키와 인증서를 만들지 않았거나 얻지 못한 경우 비공개 키 및 인증서 만들기를 참조하세요.

인증서를 만든 후에는 범위를 전역에서 리전으로 또는 리전에서 전역으로 변경할 수 없습니다.

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --certificate=CERTIFICATE_FILE \
    --private-key=PRIVATE_KEY_FILE \
    --global

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --certificate=CERTIFICATE_FILE \
    --private-key=PRIVATE_KEY_FILE \
    --region=REGION

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_certificate(
    project_id: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a global SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

    Returns:
        Dictionary with information about the new global SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.sslCertificates().insert(
        project=project_id, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)
    return response

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_regional_certificate(
    project_id: str,
    region: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a regional SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

        Returns:
        Dictionary with information about the new regional SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.regionSslCertificates().insert(
        project=project_id, region=region, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)

    return response

3단계: SSL 인증서를 대상 프록시와 연결

각 대상 HTTPS 또는 SSL 프록시에 SSL 인증서를 하나 이상 연결해야 합니다. 대상 HTTPS 또는 SSL 프록시당 최대 SSL 인증서 수를 사용하여 대상 프록시를 구성할 수 있습니다. 동일한 대상 프록시에서 여러 자체 관리형 인증서를 참조할 수 있습니다.

gcloud compute target-https-proxies update TARGET_PROXY_NAME \
    --global \
    --ssl-certificates=SSL_CERTIFICATE_LIST \
    --global-ssl-certificates

gcloud compute target-ssl-proxies update TARGET_PROXY_NAME \
    --ssl-certificates=SSL_CERTIFICATE_LIST

gcloud compute target-https-proxies update TARGET_PROXY_NAME \
    --region=REGION \
    --ssl-certificates=SSL_CERTIFICATE_LIST \
    --ssl-certificates-region=REGION

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-xlb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-xlb-map",
"sslCertificates": /projectsPROJECT_IDglobal/sslCertificates/SSL_CERT_NAME
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetSslProxy

{
"name": "l7-ssl-proxy",
"sslCertificates": /projectsPROJECT_IDglobal/sslCertificates/SSL_CERT_NAME
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-xlb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"region": "us-west1"
"sslCertificates": /projectsPROJECT_IDregions/us-west1/sslCertificates/SSL_CERT_NAME
}

4단계: 부하 분산기의 IP 주소를 가리키도록 DNS A 및 AAAA 레코드 업데이트

등록기관의 사이트, DNS 호스트 또는 ISP(DNS 레코드를 관리하는 곳)에서 도메인과 모든 하위 도메인에 DNS A 레코드(IPv4용) 및 DNS AAAA 레코드(IPv6용)를 추가 또는 업데이트하여 부하 분산기의 전달 규칙과 연결된 IP 주소를 가리키도록 합니다.

Cloud DNS 및 Cloud Domains를 사용할 경우 도메인을 설정하고 네임서버를 업데이트합니다.

단일 인증서에 여러 도메인을 사용하는 경우 모두 부하 분산기의 IP 주소를 가리키도록 모든 도메인과 하위 도메인에 대해 DNS 레코드를 추가하거나 업데이트해야 합니다.

DNS 전파가 완료될 때까지 기다린 후 dig 명령어를 실행하여 설정을 확인할 수 있습니다. 예를 들어 도메인이 www.example.com이라고 가정해 보겠습니다. 다음 dig 명령어를 실행합니다.

dig www.example.com

; <<>> DiG 9.10.6 <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31748
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.example.com.           IN  A

;; ANSWER SECTION:
www.example.com.        1742    IN  CNAME   www.example.com.edgekey.net.
www.example.com.edgekey.net. 21330 IN   CNAME   www.example.com.edgekey.net.globalredir.akadns.net.
www.example.com.edgekey.net.globalredir.akadns.net. 3356 IN CNAME   e6858.dsce9.akamaiedge.net.
e6858.dsce9.akamaiedge.net. 19  IN  A   203.0.113.5

;; Query time: 43 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jun 03 16:54:44 PDT 2020
;; MSG SIZE  rcvd: 193

이 예시에서 203.0.113.5는 부하 분산기의 IP 주소입니다.

5단계: OpenSSL로 테스트

부하 분산기가 자체 관리형 SSL 인증서를 사용하기까지 최대 30분이 걸릴 수 있습니다.

테스트하려면 다음 OpenSSL 명령어를 실행하여 DOMAIN을 DNS 이름으로, IP_ADDRESS를 부하 분산기의 IP 주소로 바꿉니다.

echo | openssl s_client -showcerts -servername DOMAIN -connect IP_ADDRESS:443 -verify 99 -verify_return_error

이 명령어는 부하 분산기가 클라이언트에 제공하는 인증서를 출력합니다. 출력에는 세부정보와 함께 인증서 체인과 Verify return code: 0 (ok)가 포함됩니다.

자체 관리형 SSL 인증서 작업

다음 섹션에서는 SSL 인증서 리소스를 나열, 보기, 삭제, 교체 방법을 설명합니다.

SSL 인증서 나열

gcloud compute ssl-certificates list \
   --global

gcloud compute ssl-certificates list \
   --filter="region:(REGION ...)"

SSL 인증서 설명

gcloud  compute ssl-certificates describe CERTIFICATE_NAME \
   --global

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
   --region=REGION

SSL 인증서 삭제

SSL 인증서를 삭제하려면 먼저 인증서를 참조하는 각 대상 프록시를 업데이트해야 합니다. 각 대상 프록시에 대해 적절한 gcloud update 명령어를 실행하여 대상 프록시의 SSL_CERTIFICATE_LIST를 업데이트하여 삭제해야 하는 SSL 인증서가 포함되지 않도록 합니다. 각 대상 SSL 프록시 또는 대상 HTTPS 프록시는 SSL 인증서를 최소 하나 이상 참조해야 합니다.

대상 프록시를 업데이트한 후에 SSL 인증서를 삭제할 수 있습니다.

gcloud compute ssl-certificates delete CERTIFICATE_NAME \
    --global

gcloud compute ssl-certificates delete CERTIFICATE_NAME \
    --region=REGION

SSL 인증서 만료 전에 교체 또는 갱신

SSL 인증서를 교체하거나 갱신하거나 순환해야 하는 경우 다음 단계를 따르세요.

1. 현재 인증서에 대해 gcloud compute ssl-certificates describe 명령어를 실행하여 만료 예정인지 확인합니다.

2. 새 SSL 인증서 리소스를 만듭니다. 새 SSL 인증서는 프로젝트 내에 고유한 이름이 있어야 합니다.

3. 대상 프록시를 업데이트하여 이전 SSL 인증서를 분리하고 새 인증서를 추가합니다. 보관할 다른 기존 SSL 인증서를 포함해야 합니다.

   다운타임을 방지하려면 --ssl-certificates 플래그와 함께 단일 gcloud 명령어를 실행합니다. 예를 들면 다음과 같습니다.

   전역 외부 애플리케이션 부하 분산기:

   gcloud compute target-https-proxies update 명령어를 --global 플래그와 함께 사용합니다.

   gcloud compute target-https-proxies update TARGET_PROXY_NAME \
      --global \
      --ssl-certificates=new-ssl-cert,other-certificates \
      --global-ssl-certificates
   

   리전 외부 애플리케이션 부하 분산기 및 내부 애플리케이션 부하 분산기:

   gcloud compute target-https-proxies update 명령어를 --region 플래그와 함께 사용합니다.

   gcloud compute target-https-proxies update TARGET_PROXY_NAME \
      --region REGION \
      --ssl-certificates=new-ssl-cert,other-certificates \
      --global-ssl-certificates
   

   외부 프록시 네트워크 부하 분산기:

   gcloud compute target-ssl-proxies update 명령어를 --backend-service 플래그와 함께 사용합니다.

   gcloud compute target-ssl-proxies update TARGET_PROXY_NAME \
      --ssl-certificates=new-ssl-cert,other-certificates
   

4. 다음 OpenSSL 명령어를 실행하여 부하 분산기가 교체 인증서를 제공하는지 확인합니다.

   echo | openssl s_client -showcerts -connect IP_ADDRESS:443 -verify 99 -verify_return_error
   

5. 모든 Google 프런트엔드(GFE)에 교체 작업이 전파되도록 15분 동안 기다립니다.

6. (선택사항) 이전 SSL 인증서를 삭제합니다.

주기적으로 SSL 인증서 순환

이 샘플 솔루션은 Google Cloud 부하 분산기에 사용되는 인증서의 상태를 정기적으로 확인하고 전체 기간의 일정 비율에 도달하면 인증서를 순환합니다. 이 도구는 Certificate Authority Service를 사용하여 구성된 CA를 사용합니다.

이 솔루션은 다음 부하 분산기에서 작동합니다.

• 전역 외부 애플리케이션 부하 분산기
• 기본 애플리케이션 부하 분산기
• 리전 외부 애플리케이션 부하 분산기
• 내부 애플리케이션 부하 분산기
• SSL 프록시를 사용하는 외부 프록시 네트워크 부하 분산기

다음 단계

• SSL 인증서 문제를 해결하려면 SSL 인증서 문제 해결을 참조하세요.