セルフマネージド SSL 証明書を使用する

セルフマネージド SSL 証明書は、ご自分で取得、プロビジョニング、更新する証明書です。このリソースを使用して、クライアントとロードバランサ間の通信を保護できます。

セルフマネージド証明書には、次の証明書の種類を自由に組み合わせることができます。

• ドメイン認証（DV）
• 組織認証（OV）
• 拡張認証（EV）

セルフマネージド証明書は、次のロードバランサでサポートされています。

• グローバル証明書
  • グローバル外部アプリケーション ロードバランサ
  • 従来のアプリケーション ロードバランサ
  • 外部プロキシ ネットワーク ロードバランサ（ターゲット SSL プロキシを使用）

• リージョン証明書
  • リージョン外部アプリケーション ロードバランサ
  • リージョン内部アプリケーション ロードバランサ

このページでは、有効な Compute Engine 証明書を取得し、証明書をアップロードして Google Cloud SSL 証明書リソースを作成する手順を説明します。

Certificate Manager を使用して 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 証明書リソースを作成するステップに進みます。

秘密鍵を選択または作成する

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）属性を設定する必要があります。事実上、シングル ドメイン向けの証明書であっても、CN 属性と SAN 属性の両方を設定する必要があります。macOS と iOS の最新バージョンなどの最新のクライアントは CN 属性だけに依存しないためです。

スキーマを作成するには、次の手順を行います。

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: 証明書のサブジェクト代替名。

  証明書が 1 つのホスト名のみを対象としている場合は、共通名に一致する単一のサブジェクト代替名だけを定義します。3 つ以上のサブジェクト代替名が必要な場合は、DNS の後に続く数値を増やして（DNS.3、DNS.4 など）、構成ファイルに追加します。

• PRIVATE_KEY_FILE: 秘密鍵ファイルのパス

• CSR_FILE: CSR のパス（ファイル名を含む）

CSR に署名する

認証局は CSR に署名する際、独自の秘密鍵を使用して証明書を作成します。 CSR に署名するには、次のいずれかの方法を使用します。

公的に信頼できる CA を使用する

CSR に署名するよう公的に信頼できる CA にリクエストすると、その証明書はその公開 CA を信頼するすべてのクライアントに信頼されます。署名済み証明書を作成するために公開 CA が必要とするのは、CSR のみです。

独自の内部 CA を使用する

自分の CA を管理している場合は、CSR に署名できます。クライアントも独自の CA を信頼するように構成されている場合は、独自の CA を使用して CSR に署名することで、内部的に信頼できる証明書が作成されます。

自己署名証明書を使用する

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 プロキシごとに少なくとも 1 つの 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 を使用している場合は、ドメインを設定し、ネームサーバーを更新します。

単一の証明書に複数のドメインを使用する場合は、すべてのドメインとそのサブドメインの DNS レコードを追加または更新して、すべてのレコードでロードバランサの IP アドレスを参照するようにする必要があります。

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 証明書を削除するには、まず、その証明書を参照する各ターゲット プロキシを更新する必要があります。各ターゲット プロキシについて SSL_CERTIFICATE_LIST を更新するために適切な gcloud update コマンドを実行し、削除が必要となる SSL 証明書が含まれなくなるようにします。各ターゲット SSL プロキシまたはターゲット HTTPS プロキシは、1 つ以上の 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. 15 分間待ち、すべての Google Front End（GFE）に置換オペレーションが伝播されていることを確認します。

6. （省略可）古い SSL 証明書を削除します。

SSL 証明書を定期的にローテーションする

このサンプル ソリューションでは、Google Cloud ロードバランサで使用されている証明書のステータスを定期的にチェックし、有効期間に達した時点で証明書をローテーションします。このツールは、Certificate Authority Serviceを使用して構成された CA を使用します。

このソリューションは、次のロードバランサで動作します。

• グローバル外部アプリケーション ロードバランサ
• 従来のアプリケーション ロードバランサ
• リージョン外部アプリケーション ロードバランサ
• 内部アプリケーション ロードバランサ
• SSL プロキシを使用した外部プロキシ ネットワーク ロードバランサ

次のステップ

• SSL 証明書のトラブルシューティングについては、SSL 証明書のトラブルシューティングをご覧ください。