5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ike_s_muramatsu(村松 祥)

プライベートホストゾーンのドメインに対してACMパブリック証明書を発行する

5
Posted at

導入・背景

社内向けの管理画面や閉域網経由でのシステムをALB＋ECSで構築するケースは多いと思います。

こういったシチュエーションにおいてもパブリックの証明書が使えると嬉しい場面はあるはずです。

「プライベートホストゾーンに登録したドメインだから、パブリック証明書は使えないんじゃないか」と思うかもしれませんが、条件を満たせば発行することができます。一方で、パブリックホストゾーンと同じ感覚でコンソールでポチポチするだけでは詰まるポイントがあります。

本記事ではパブリックドメインとプライベートホストゾーンのドメインで証明書発行フローがどう違うのか、またプライベートホストゾーンでどうやってACMの検証をクリアするのかを整理します。

想定読者

  • Route 53のパブリックホストゾーン・プライベートホストゾーンの違いを理解しているエンジニア
  • ACMのDNS検証の仕組みを知っている方

プライベートホストゾーンで証明書が必要になる場面

プライベートホストゾーンで管理するドメイン（例：app.internal.test.com）に対してHTTPS通信を行う場合、ブラウザやHTTPクライアントはサーバ証明書を検証しようとします。自己署名証明書を使うとアクセスのたびに警告が出るため、ブラウザから信頼されているACMのパブリック証明書を使いたいというモチベーションが生まれます。

具体的なユースケースとしては以下が挙げられます。

  • 閉域網や社内ネットワーク経由でのみアクセスできる社内ツール・管理画面
  • Direct Connect・VPN経由でVPCに接続したオンプレミスクライアントからのアクセス

パブリックドメインの場合

まずパブリックドメイン（例：app.test.com）の場合を整理しておきます。こちらは非常に簡単です。

  1. ACMコンソールから証明書をリクエスト（DNS検証を選択）

  2. 検証画面に表示される「Route 53でレコードを作成」ボタンをクリック
    ACM.png

  3. ACMが自動的にパブリックホストゾーンにCNAMEレコードを追加してくれる

  4. 数分で検証が完了し証明書が発行される

_abc123def456.app.test.com. CNAME _xyz789.acm-validations.aws.
↑ これがパブリックホストゾーンに自動追加される

ACMの検証サーバーはパブリックDNSをポーリングしてこのCNAMEが引けることを確認します。パブリックホストゾーンにレコードがあるので問題なく検証できます。

プライベートホストゾーンの場合

プライベートホストゾーンで管理しているドメイン（例：app.internal.test.com）の場合、同じ手順でやるとハマります。

なぜ詰まるのか

「Route 53でレコードを作成」ボタンを押すと、ACMはプライベートホストゾーンにCNAMEレコードを追加しに行きます。追加自体は成功しますが、検証が一向に進みません。

原因はシンプルでACMの検証サーバーはパブリックインターネット上からDNSを引きに行くからです。プライベートホストゾーンはVPCの内側でしか解決できないため、ACMの検証サーバーからはCNAMEが見えず、検証がいつまでもPending validationのままになります。

ACMの検証サーバー（パブリック）
    ↓ _abc123.app.internal.test.com を引きに行く
    → プライベートホストゾーンなので解決できない
    → 検証タイムアウト

解決策 親のパブリックホストゾーンにCNAMEを手動追加する

プライベートホストゾーンのドメインでも、親ドメインがパブリックに登録されていればACMパブリック証明書を発行できます。ポイントは検証用のCNAMEをプライベートホストゾーンではなく、親ドメインのパブリックホストゾーンに手動追加することです。

前提条件として以下が必要です。

条件 内容
親ドメインがパブリック登録されている test.comがRoute 53などで公開管理されていること
親ドメインのパブリックホストゾーンが存在する Route 53にtest.comのパブリックホストゾーンがあること
サブドメインの追加権限がある 親ゾーンにレコードを追加できる権限があること

app.corp.internalのように架空のTLDを使っているドメインはパブリックCAからの証明書発行自体が不可能なため、この方法は使えません。

具体的な手順

ステップ1 ACMコンソールで証明書をリクエスト

対象ドメイン（例：app.internal.test.com）に対してACMパブリック証明書をリクエストします。検証方式はDNS検証を選択します。

ステップ2 検証用CNAMEの情報をコピーする

リクエスト後の画面に表示される検証用CNAMEのNameとValueをコピーします。「Route 53でレコードを作成」ボタンは押さないでください。このボタンを押すと、ACMがアカウント内の一致するホストゾーンを自動検索してレコードを追加しようとしますが、プライベートホストゾーンに追加されてしまい検証が進みません。

例）
Name:  _abc123def456.app.internal.test.com.
Value: _xyz789ghi.acm-validations.aws.

ステップ3 親のパブリックホストゾーンにCNAMEを手動追加する

Route 53コンソールを開き、test.com のパブリックホストゾーンに移動します。「レコードを作成」から以下の内容でCNAMEレコードを追加します。

項目 値
レコード名 _abc123def456.app.internal（ホストゾーン名の.test.comを除いた部分）
レコードタイプ CNAME
値 _xyz789ghi.acm-validations.aws.
TTL 300 
パブリックホストゾーン（test.com）
    └─ _abc123def456.app.internal.test.com. CNAME _xyz789ghi.acm-validations.aws.
                                                     ↑ ここをACMの検証サーバーが引きに来る

AWS CLIで追加する場合は以下のようになります。

aws route53 change-resource-record-sets \
  --hosted-zone-id <パブリックホストゾーンのID> \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_abc123def456.app.internal.test.com.",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [{"Value": "_xyz789ghi.acm-validations.aws."}]
      }
    }]
  }'

ステップ4 検証完了を待つ

ACMの検証サーバーがCNAMEレコードを確認すると証明書のステータスがIssuedに変わります。通常は数分以内に完了しますが、それ以上かかることもあります。

発行後の注意点

検証用CNAMEは削除しない

自動更新のためにパブリックホストゾーンの検証用CNAMEレコードは残し続けてください。これを削除すると証明書の自動更新が失敗します。

サービス自体のDNSレコードはプライベートホストゾーンで管理する

証明書の発行に成功した後、ALBなどに証明書を紐付けてHTTPS化します。カスタムドメイン（app.internal.test.com）をALBに向けるレコードはプライベートホストゾーンで管理してください。Route 53ではALBへのルーティングにはAliasレコード（Aレコード）を使います。パブリックホストゾーンに追加するのは検証用CNAMEのみです。

【パブリックホストゾーン（test.com）に追加するもの】
_abc123def456.app.internal.test.com. CNAME _xyz789ghi.acm-validations.aws.  ← 検証用のみ

【プライベートホストゾーン（internal.test.com）で管理するもの】
app.internal.test.com. A (Alias) → internal-alb-xxx.ap-northeast-1.elb.amazonaws.com  ← サービスのレコード

まとめ

この記事では以下の内容を整理しました。

  • ACMのDNS検証はパブリックDNSで行われるため、プライベートホストゾーンに検証用CNAMEを追加しても検証が通らない
  • 親ドメインのパブリックホストゾーンに検証用CNAMEを手動追加することで、プライベートホストゾーンのドメインでもパブリック証明書を発行できる
  • 「Route 53でレコードを作成」ボタンはプライベートホストゾーンに追加してしまうため使わず、手動でパブリックホストゾーンにCNAMEを追加する
  • 検証用CNAMEは自動更新のために削除せず残しておく
パブリックドメイン プライベートホストゾーンのドメイン
証明書発行の可否 可能 条件付きで可能
「Route 53でレコードを作成」ボタン 使える 使えない（プライベートホストゾーンに追加されてしまう）
検証用CNAMEの追加先 パブリックホストゾーン（自動） 親ドメインのパブリックホストゾーン（手動）
必要な前提条件 なし 親ドメインがパブリック登録されていること

プライベートホストゾーンのドメインへのACM証明書発行でハマるポイントは「コンソールのボタンを信じてしまうこと」です。ACMの検証はパブリックDNSで行われるという仕組みを理解していれば、解決策は自然と見えてきます。

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?