はじめに
Akamaiを導入した環境では、HTTPS通信で使用するサーバ証明書をどこに配置するのでしょうか。
Akamaiを利用しない一般的なWebシステムでは、ClientがWeb Serverへ直接HTTPS接続するため、Web Serverにサーバ証明書を配置します。
一方、Akamaiを導入すると、ClientからのHTTPS通信はAkamai Edge Serverでいったん終端されます。その後、必要に応じてAkamai Edge ServerからOrigin Serverへ別のHTTPS接続が確立されます。
そのため、Akamai環境のTLS通信は次の2つに分けて考えることが重要です。
- Client ↔ Akamai Edge Server
- Akamai Edge Server ↔ Origin Server
この記事では、Akamai導入時のTLS通信の仕組みと、Edge CertificateとOrigin Certificateの違い、証明書更新時の注意点について解説します。
Akamai導入前のHTTPS通信
まず、Akamaiを利用していない一般的なHTTPS通信を確認します。
ClientはWeb Serverと直接TLS接続を確立します。
Web ServerはTLSハンドシェイクの際にサーバ証明書を提示し、Clientは証明書の有効期限やホスト名、証明書チェーンなどを検証します。
検証に問題がなければTLS接続が確立され、HTTPS通信が開始されます。
Akamai導入後のHTTPS通信
Akamaiを導入すると、HTTPS通信の構成が変わります。
重要なのは、ClientからOrigin Serverまで1本のTLS接続が確立されるわけではないという点です。
Akamai Edge ServerでClientからのTLS通信が終端されるため、次の2つの独立したTLS接続として考えます。
| 通信区間 | 使用する証明書 | 証明書を検証する側 |
|---|---|---|
| Client ↔ Akamai Edge | Edge Certificate | Client |
| Akamai Edge ↔ Origin | Origin Certificate | Akamai Edge |
Client ↔ Akamai Edge Server
ユーザがWebサイトへHTTPSでアクセスすると、ClientはAkamai Edge Serverとの間でTLS接続を確立します。
このときAkamai Edge ServerがClientへ提示する証明書がEdge Certificateです。Clientはこの証明書を検証します。
Akamaiでは、Default DV CertificateやCertificate Provisioning System（CPS）などを利用してEdge Certificateを管理できます。特にAkamai-managed certificateでは、証明書の発行・配備・更新といったライフサイクルをAkamai側の仕組みで自動化できます。
そのため、Edge Certificateは「Akamai側で管理・自動化する証明書」と捉えると全体像を理解しやすくなります。ただし、Domain Validationに必要なDNS設定の維持や、CPS / Control Center上の更新状態の確認など、利用者側で必要な設定・運用が完全になくなるわけではありません。
Akamai Edge Server ↔ Origin Server
Akamai Edge ServerからOrigin Serverへのアクセスが必要な場合、Edge ServerからOrigin Serverへリクエストが送信されます。
Originへの通信をHTTPSにしている場合、この区間でも別のTLS接続が確立されます。このときOrigin ServerがAkamai Edge Serverへ提示する証明書がOrigin Certificateです。
Akamai Edge ServerはOrigin Serverから提示された証明書を検証し、問題がなければTLS接続を確立します。
Edge CertificateとOrigin Certificateの違い
Akamai環境で証明書を管理する際は、Edge CertificateとOrigin Certificateを混同しないことが重要です。
| 項目 | Edge Certificate | Origin Certificate |
|---|---|---|
| 使用区間 | Client ↔ Akamai Edge | Akamai Edge ↔ Origin |
| 証明書を提示する側 | Akamai Edge | Origin Server |
| 証明書を検証する側 | Client | Akamai Edge |
| 主な管理 | Akamai CPS / Default DVなど ※利用者側の設定・確認も一部必要 | Origin Server側 |
この2つは異なるTLS接続で使用されるため、基本的には別々の証明書として管理します。
Origin Certificateはどのように検証される？
Akamai Edge Serverは、Origin ServerへHTTPS接続するときにOrigin Certificateを受け取り、設定に基づいて検証します。
証明書検証では、主に次のようなポイントを確認します。
- 証明書が信頼するCAによって署名されているか
- 証明書の有効期限に問題がないか
- CN（Common Name）やSAN（Subject Alternative Name）が接続先のホスト名と一致しているか
- 証明書チェーンを正しく検証できるか
AkamaiのProperty Managerでは、Origin ServerへのHTTPS接続に対してOrigin TLS Certificate Verificationを設定できます。Platform SettingsではAkamaiのCertificate Storeに含まれるCAを信頼し、構成に応じてCustom CAや特定の証明書を指定することもできます。
そのため、Origin Certificateを更新するときは、Origin Serverへ新しい証明書を導入するだけでなく、Akamai側のOrigin TLS設定や証明書検証条件との整合性も確認することが重要です。
特に、特定のCAや証明書を信頼する構成にしている場合は、証明書更新によって発行元CAや証明書チェーンが変わらないか確認しておきましょう。
Edge CertificateとOrigin Certificateの更新は別
証明書更新についても、Edge CertificateとOrigin Certificateを分けて考える必要があります。
Origin Certificateを更新したからといって、Edge Certificateも同時に更新する必要があるわけではありません。
それぞれ異なるTLS接続で使用される証明書だからです。
Origin Certificateの更新
Origin Certificateの有効期限が近づいた場合は、Origin Server側の証明書を更新します。
更新時は、有効期限だけでなく、CN / SAN、証明書チェーン、発行元CA、Akamai側の証明書検証設定への影響も確認します。
Edge Certificateの更新
Edge Certificateは、AkamaiのCertificate Provisioning System（CPS）やDefault DV Certificateなどを利用して、発行・配備・更新をAkamai側で自動化できます。
Default DV Certificateは、PropertyへSecure Hostnameを追加するときに作成できるDV証明書です。Domain Validationでは複数の方式を利用できますが、AkamaiはAuto DNS CNAMEを一般的かつ推奨される方式として案内しています。
Auto DNS CNAMEでは、Akamaiから指定された_acme-challengeのCNAMEレコードをDNSへ登録します。このCNAMEが指定されたValidation Hostnameを指した状態で維持されていれば、Domain Validationと証明書更新を自動化できます。
したがって、一般的な構成ではEdge CertificateのライフサイクルはAkamai側で管理・自動化し、利用者は自動更新に必要なDNS設定と更新状態を確認するという整理が分かりやすいでしょう。
Manual Domain Validationを使うケース
Manual DNSやManual HTTPによるDomain Validationを利用する構成もあります。たとえばMulti-CDNなど、Akamai向けの自動Validation構成を利用しにくいケースではManual方式を選択することがあります。
Manual方式では、証明書更新時に新しいValidation Challengeへの対応が必要になる場合があります。そのため、Manual方式を利用している場合は、更新時の作業を運用手順として管理しておくことが重要です。
Edge Certificateについては、次のポイントを押さえておけば十分です。
- Edge CertificateはAkamai側の仕組みでライフサイクルを自動化できる
- Default DVではAuto DNS CNAMEが推奨されている
- 自動更新に必要なDNS設定を維持する
- CPS / Control Centerで証明書の更新状態やエラーを確認する
- Manual方式を利用している場合は更新時のValidation Challengeに対応する
証明書更新時に確認したいポイント
Akamai環境で証明書を更新するときは、まず「どちらのTLS接続で使用している証明書なのか」を確認しましょう。
| 確認項目 | Edge Certificate | Origin Certificate |
|---|---|---|
| 使用区間 | Client ↔ Akamai Edge | Akamai Edge ↔ Origin |
| 配置先 | Akamai Edge | Origin Server |
| 検証する側 | Client | Akamai Edge |
| 主な管理 | Akamai CPS / Default DVなど ※利用者側の設定・確認も一部必要 | Origin Server側 |
| 更新時の主な確認 | CPS / Control Centerの更新状態、自動更新に必要なDNS設定 | 有効期限、CN / SAN、証明書チェーン、発行元CA、Akamai側の検証設定 |
特にOrigin Certificateの更新では、証明書そのものだけでなく、Akamai Edge Serverが更新後の証明書を正しく検証できるかという視点で確認することがポイントです。
まとめ
Akamaiを導入したHTTPS環境では、ClientからOrigin Serverまで1本のTLS接続が確立されるわけではありません。
Akamai Edge ServerでTLS通信が終端されるため、次の2つのTLS接続として考えます。
- Client ↔ Akamai Edge Server：Edge Certificateを使用し、Clientが検証する
- Akamai Edge Server ↔ Origin Server：Origin Certificateを使用し、Akamai Edge Serverが検証する
「誰と誰がTLS接続しているのか」「誰がどの証明書を検証するのか」を分けて考えると、Akamai環境の証明書配置や更新を整理しやすくなります。
証明書管理の考え方としては、Edge CertificateはAkamai側でライフサイクル管理を自動化し、Origin CertificateはOrigin Server側で管理すると整理すると分かりやすくなります。Edge Certificateについても、自動更新に必要なDNS設定やCPS / Control Center上の更新状態は確認しておきましょう。
この構造を理解しておけば、証明書更新だけでなく、OriginへのTLS接続エラーが発生した際のトラブルシューティングにも役立ちます。
AkamaiのCDNの仕組みについては、以下の記事でも解説しています。
Japanese 
English
コメント