Skip navigation
All Places > ジャパンユーザーグループ (Japan User Group) > Blog

本記事では、新しいCPS(2017年11月リリース)にてDV証明書を申請する方法を、紹介させていただきます。

 

1. 「設定」より「Certificate Provisioning System (CPS)」をクリックし、CPSに移動する

 

2. 「Create New Certificate」より、証明書申請ページに移動する

 

3. 証明書の認証タイプにて、今回はAkamai Managed Certificate配下の「Domain Validation (DV)」を選択する

選択後、右下の「Next」をクリックして、次のステップに進みます。

※「Next」をクリックすると、「1. Select Validation Type」と「2. Select Certificate Settings」が完了し、以下の状態になります。

 

4. 証明書のCommon Name、SANs、会社情報を入力する

入力後、右下の「Next」をクリックして、次のステップに進みます。

※CSRに記載される情報(Common NameやOrganization Nameなど)には制限があります。詳細はこちらをご確認ください。

 

5. 申請会社情報を確認する

 4.で入力した会社情報と同じ場合、「Same as certificate company information」にチェックします。

 4.で入力した会社情報と異なる場合、「Same as certificate company information」のチェックを外し、情報を入力してください。

確認後、右下の「Next」をクリックして、次のステップに進みます。

 

6. お客様情報およびアカマイ技術担当者情報を入力する

 ・お客様情報の最下部にある会社情報は、4.と同じ場合、「Same as certificate company information」にチェックします。

  4.と異なる場合、Same as certificate company information」のチェックを外し、情報を入力してください。

 ・アカマイ技術担当者情報には、以下を入力してください。

項目入力していただく情報
First NameJapan
Last NameAkamai
Email Address

ssl-cps-jp(あっとまーく)akamai.com

※(あっとまーく)を@に変更してください。

Phone Number+81-3-4589-6500

 

入力後、右下の「Next」をクリックして、次のステップに進みます。

 

7. ネットワーク設定を確認する

 申請する証明書のネットワーク設定を行います。

選択後、右下の「Review」をクリックして、入力・選択した情報に誤りがないか確認してください。

※Cipher Profileはデフォルトで最新のものが選択されます。別のものを設定する必要がある場合は、証明書が展開された後、変更することが可能になります。9.でSubmit直後にも変更可能ですが、変更してしまうとCSRが再発行されてしまうため、証明書を一度展開した後に実施することをお勧めいたします。

 

9. 「Submit」をクリックして、申請を完了する

 

10. ドメイン認証を実施するため、認証用リダイレクト設定を確認する

 a. 「Submitting to CA」のTo-Doをクリックして表示される「View Validation Instrucstions」をクリックし、認証用リダイレクト確認ページに移動する

 b. 「Redirect From」に書かれているURLから「Rediret To」に書かれているURLへのリダイレクトをオリジンサーバもしくはCNAME済みの場合はアカマイプロパティに設定する

※リダイレクトトークン(表示されているパス情報)は、発行から1週間で更新されますので、速やかに設定の実施をお願いいたします。

 

11. サーバにリダイレクトを設定する

 10.で取得したリダイレクトを設定します。リダイレクトは302 Temporaryでご設定ください。

※Subject Alternate Names (SAN)に登録がある場合、登録している数だけリダイレクトを設定していただく必要があります。

 

12. Let's Encryptより証明書が発行される

 リダイレクト設定を実施後、数時間で証明書が発行されます。

 

13. 証明書がアカマイネットワークに展開される

 証明書が発行されると、アカマイネットワークに展開されます。

 展開は、混雑状況等にもよりますが、概ね1時間30分から2時間程度で完了します。完了した際、CPS上のステータスが「Active」になるのと同時に、sf-no-reply(あっとまーく)akamai.comから「Certificate Notification for COMMON NAME: Successfully deployed!」という件名のメールが届きます。

本記事では、新しいCPS(2017年11月リリース)にてThird Party証明書を申請する方法を、紹介させていただきます。

 

1. 「設定」より「Certificate Provisioning System (CPS)」をクリックし、CPSに移動する

 

2. 「Create New Certificate」より、証明書申請ページに移動する

 

3. 証明書の認証タイプにて、今回はSelf-Managed Certificate配下の「Third Party」を選択する

選択後、右下の「Next」をクリックして、次のステップに進みます。

※「Next」をクリックすると、「1. Select Validation Type」と「2. Select Certificate Settings」が完了し、以下の状態になります。

 

4. 証明書のCommon Name、SANs、会社情報を入力する

入力後、右下の「Next」をクリックして、次のステップに進みます。

※CSRに記載される情報(Common NameやOrganization Nameなど)には制限があります。詳細はこちらをご確認ください。

 

5. 申請会社情報を確認する

 4.で入力した会社情報と同じ場合、「Same as certificate company information」にチェックします。

 4.で入力した会社情報と異なる場合、「Same as certificate company information」のチェックを外し、情報を入力してください。

確認後、右下の「Next」をクリックして、次のステップに進みます。

 

6. お客様情報およびアカマイ技術担当者情報を入力する

 ・お客様情報の最下部にある会社情報は、4.と同じ場合、「Same as certificate company information」にチェックします。

  5.と異なる場合、Same as certificate company information」のチェックを外し、情報を入力してください。

 ・アカマイ技術担当者情報には、以下を入力してください。

項目入力していただく情報
First NameJapan
Last NameAkamai
Email Address

ssl-cps-jp(あっとまーく)akamai.com

※(あっとまーく)を@に変更してください。

Phone Number+81-3-4589-6500

 

入力後、右下の「Next」をクリックして、次のステップに進みます。

 

7. ネットワーク設定を確認する

 申請する証明書のネットワーク設定を行います。

選択後、右下の「Review」をクリックして、入力・選択した情報に誤りがないか確認してください。

※Cipher Profileはデフォルトで最新のものが選択されます。別のものを設定する必要がある場合は、証明書が展開された後、変更することが可能になります。9.でSubmit直後にも変更可能ですが、変更してしまうとCSRが再発行されてしまうため、証明書を一度展開した後に実施することをお勧めいたします。

 

8. 「Submit」をクリックして、CSR発行をリクエストする

 

9. CSRダウンロードページに移動する

In Progressにて、「Submitting to CA」にチェックがつき(完了し)「Receiving certificate」がTo-Doとなれば、CSR発行が完了しています。

一番右側のAction部の歯車マークメニュより「Download CSR」をクリックし、CSRダウンロードページに移動します。

※CSRの発行完了までには、数分から1時間程度要します。

 

10. 「Download CSR」よりCSRをダウンロードする

※ダウンロードしたCSRは、こちらのようなWebページでデコードして、期待通り生成されていることをご確認の上、ご使用ください。

 

11. 発行されたサーバ証明書及び信頼チェーンをアップロードする

サーバ証明書が発行されたら信頼チェーンが成立していることを確認の後、アカマイネットワークに展開します。

 a. 「Receiving Certificate」のTo-Doをクリックして表示される「Upload Certificate and Trust Chain」をクリックし、証明書アップロード画面に移動する

 b. サーバ証明書及び信頼チェーンのファイルを選択、もしくは内容をコピー&ペーストして、「Click and Add」をクリックすることにより、アカマイネットワークへの展開を開始する

 

アップロード時に、証明書そのものや信頼チェーンなどに問題がないことを確認しています。

問題があった場合は、ご登録のメールアドレスにその旨がメールで届きますので、ご確認ください。

 

証明書のアカマイネットワークへの展開には、およそ1時間30分から数時間要します。

展開が完了すると、ご登録のメールアドレスにその旨がメールで届きますので、こちらもご確認ください。

本記事では、新しいCPS(2017年11月リリース)にてEV証明書を申請する方法を、紹介させていただきます。

 

1. 「設定」より「Certificate Provisioning System (CPS)」をクリックし、CPSに移動する

 

2. 「Create New Certificate」より、証明書申請ページに移動する

 

3. 証明書の認証タイプにて、今回はAkamai Managed Certificate配下の「Extended Validation (EV)」を選択する

選択後、右下の「Next」をクリックして、次のステップに進みます。

 

4. 申請したい証明書のタイプ及び認証局を選択する

選択後、右下の「Next」をクリックして、次のステップに進みます。

※2018年1月現在、アカマイ経由で発行できるEV証明書の認証局は、Symantecとなります。

 

5. 証明書のCommon Name、SANs、会社情報を入力する

入力後、右下の「Next」をクリックして、次のステップに進みます。

※CSRに記載される情報(Common NameやOrganization Nameなど)には制限があります。詳細はこちらをご確認ください。

 

6. 申請会社情報を確認する

 5.で入力した会社情報と同じ場合、「Same as certificate company information」にチェックします。

 5.で入力した会社情報と異なる場合、「Same as certificate company information」のチェックを外し、情報を入力してください。

確認後、右下の「Next」をクリックして、次のステップに進みます。

 

7. お客様情報およびアカマイ技術担当者情報を入力する

 ・お客様情報の最下部にある会社情報は、5.と同じ場合、「Same as certificate company information」にチェックします。

  5.と異なる場合、Same as certificate company information」のチェックを外し、情報を入力してください。

 ・アカマイ技術担当者情報には、以下を入力してください。

項目入力していただく情報
First NameJapan
Last NameAkamai
Email Address

ssl-cps-jp(あっとまーく)akamai.com

※(あっとまーく)を@に変更してください。

Phone Number+81-3-4589-6500
TitleSolutions Engineer

 

入力後、右下の「Next」をクリックして、次のステップに進みます。

 

8. ネットワーク設定を確認する

 申請する証明書のネットワーク設定を行います。

選択後、右下の「Review」をクリックして、入力・選択した情報に誤りがないか確認してください。

※Cipher Profileはデフォルトで最新のものが選択されます。別のものを設定する必要がある場合は、証明書が展開された後、変更することが可能になります。9.でSubmit直後にも変更可能ですが、変更してしまうとCSRが再発行されてしまうため、証明書を一度展開した後に実施することをお勧めいたします。

 

9. 「Submit」をクリックして、申請を完了する

 

 

この後のDigicert社による認証は、今後公開される「新・CPSでの証明書管理 - Digicert社による認証」をご覧ください。

本投稿では、LDS(Log Delivery Service)の新規設定方法をご説明します。

 

1.はじめに

アカマイ化していないWebサイトは、オリジンサーバでクライアントのアクセスログを収集する事が出来ます。一方、アカマイ化済みWebサイトは、下記の理由により、オリジンサーバでクライアントのアクセスログを収集する事が出来ません。

 

1.オリジンサーバに通信が到達しない

エッジサーバでキャッシュヒットする場合、クライアント~エッジサーバ間で通信が完結する為、通信がオリジンサーバに到達しません。

 

2.オリジンサーバからクライアントのIPアドレスが見えない

エッジサーバでキャッシュヒットしない場合、通信はオリジンサーバまで到着しますが、通信がエッジサーバを経由する際、クライアントのIPアドレスはエッジサーバのIPアドレスに書き換わり、オリジンサーバでクライアントのIPアドレスが見えません。

その為、アカマイではエッジサーバでアクセスログを収集し、お客様にご提供しております。以下、エッジサーバでアクセスログを収集する為のLDSLog Delivery Service)設定方法をご説明します。

 

2.LDS構成図

  • 全エッジサーバで収集されたアクセスログは、ログ収集サーバを経由し、NetStorageもしくはお客様FTPサーバにアップロードされます。
  • FTPを使用せず、Emailでアクセスログを取得する事も出来ます。

 

3.LDS設定方法

以下、LDSの設定方法をご説明します。

 

最初に、LDSを設定したい配信設定にLog Request Detailsの設定を追加し、配信設定をActive化します。Log Request Detailsの設定は、本投稿の【3-1.Log Request Detailsビヘイビアの追加】でご説明します。

その後、LDSの設定を実施します。LDSの設定は、本投稿の【3-2.LDS設定の開始】から【3-8.設定完了】まででご説明します。

 

 

3-1.Log Request Detailsビヘイビアの追加

LDSを設定したい配信設定に、Log Request Detailsビヘイビアを追加して下さい。

以下、各項目の内容についてご紹介します。

Log Host Header:Hostヘッダーのログが必要な場合、Onにして下さい。

 

Log Referer Header:Refererヘッダーのログが必要な場合、Onにして下さい。

 

Log User-Agent Header:User-Agentヘッダーのログが必要な場合、Onにして下さい。

 

Log Accept-Language Header:Accept-Languageヘッダーのログが必要な場合、Onにして下さい。

 

Cookie Mode:以下の3つから選択して下さい。

  •  Don't log any cookies:Cookieのログを取得しません。
  •  Log all cookies:全Cookieのログを取得します。
  •  Log some cookies:一部Cookieのログを取得します。

 

Include Custom Log Field:【3-5.アクセスログ設定】で指定するLog FormatでCustomを使用する場合、Onにして下さい。

 

Custom Log Field:取得するカスタム情報を入力して下さい。変数も使用する事が出来ます。例えば、AK_SCHEMEを入力すると、クライアントのプロトコル(HTTP/HTTPS)をアクセスログに含めます。変数についてはVariable Support(ルナへのログインが必要です)をご確認下さい。

 

Log Request Details設定を終えた配信設定は、LDSでアクセスログを取得開始する前にActive化して下さい。

3-2.LDS設定の開始

以下、LDSの設定方法をご説明します。

ルナ上部のCONFIGUREからLog Deliveryを選択します。

 

3-3.LDS設定を実施するCPコードの確認

アクセスログは一部プロダクト※を除いてCPコード単位で収集される為、設定を実施するCPコードを確認します。数が多い場合はFilterによりCPコードを検索して下さい。

※一部プロダクト:FastDNS/GTM/Enterprise Threat Protector/AnswerXのログを収集する場合、

View byより該当のプロダクトを選択します。

FastDNS:Zone

GTM:Property

ETP:ETP

AnswerX:AnswerX

3-4.LDS設定の新規作成

CPコード確認後、LDSを設定するCPコードの歯車マークを選択して下さい。

その後、画面に出力される「Begin Log Delivery」を選択後、「New」を選択して下さい。

 

3-5.アクセスログ設定

アクセスログの取得開始日/完了日/フォーマット/頻度を指定します。

以下、各項目の内容についてご紹介します。

Start Date:アクセスログ収集を開始する日付を設定します。

 

Indefinite End Date:チェックを入れた場合、アクセスログ収集終了日を設定せず、アクセスログを収集し続けます。アクセスログ収集終了日を設定する場合、チェックを外し、日付を指定して下さい。

 

Log Format:アクセスログのフォーマットを指定します。必要なアクセスログ形式を選択して下さい。Apacheで使用されるCombined形式やIISで使用されるW3C形式に加え、WAFのログなども取得する事が出来ます。選択が出来るアクセスログ形式については、LDS UserGuide(ルナへのログインが必要です)をご確認下さい。

 

Log Identifier String:アクセスログのファイル名の先頭に付与する文字列を入力します。英数字とアンダースコアのみ入力出来ます。

 

Aggregation:ログを収集する頻度を指定します。

  • Aggregate by log arrival time:エッジサーバからログ収集サーバに転送されたアクセスログを、指定したインターバルで送信します。例えば、指定したインターバルが一時間の場合、ログ収集サーバは一時間毎にアクセスログを送信しますが、ログ収集サーバに到着していないアクセスログは、次回以降のインターバルにて送信されます。

 

  • Aggregate by hit time:しきい値で決めた割合のアクセスログがログ収集サーバに集まり次第、アクセスログを送信します。例えば、1/1 0:00(GMT)から1/1 23:59(GMT)までのアクセスログのうち、99.5%のアクセスログが集まり次第、ログ収集サーバはアクセスログを送信します。

 

全ての設定が完了したらNextを選択して下さい。

 

3-6.アクセスログ送信方法の設定

アクセスログの転送方法として、FTP(NetStorageまたはお客様がご用意したFTPサーバ)、もしくはEmailによる送信が選択可能です。

以下、各項目の内容についてご紹介します。

 

FTPの場合:

Machine:アクセスログをアップロードするFTPサーバを入力します。NetStorageもしくはお客様でご用意したFTPサーバを指定して下さい。

 

Login:ユーザを入力します。

 

Password:パスワードを入力します。

 

Directory:ディレクトリを入力します。

 

Approx. Message Size:アクセスログの最大サイズを設定します。ここで設定したサイズに分割され、アクセスログが送信されます。

 

Encording:エンコーディング方式を設定します。下記の何れかを選択します。

  • GZIP 
  • GPG Encrypted(お客様ご自身で公開鍵と秘密鍵を作成し、公開鍵をアップロードして下さい。公開鍵のアップロード完了後、アカマイのアカウントチームが手動で公開鍵を有効化しますので、ルナよりサポートチケットを起票し、GPGの公開鍵をアップロードした旨ご連絡下さい。)

 

ここまでの入力が完了したら、Testボタンを選択し、FTPサーバへの接続が正しく行われる事を確認して下さい。

 

全ての設定が完了したらNextを選択して下さい。

 

Emaiの場合:

Email Address:アクセスログ送信先Emailアドレスを入力して下さい。

 

Approx. Message Size:アクセスログの最大サイズを設定します。ここで設定したサイズに分割され、アクセスログが送信されます。

 

Encording:エンコーディング方式を設定します。下記の何れかを選択します。

  • GZIP & UNENCODED
  • GZIP & MIME BASE 64
  • GPG Encrypted(お客様ご自身で公開鍵と秘密鍵を作成し、公開鍵をアップロードして下さい。公開鍵のアップロード完了後、アカマイのアカウントチームが手動で公開鍵を有効化しますので、ルナよりサポートチケットを起票し、GPGの公開鍵をアップロードした旨ご連絡下さい。)

全ての設定が完了したらNextを選択して下さい。

 

3-7.連絡先の設定

アクセスログの送信が失敗した際に用いるコンタクト先を入力します。

以下、各項目の内容についてご紹介します。

Phone Number:電話番号を入力します。

 

Email Address(es):Emailアドレスを入力します。コンマにより、複数のEmailアドレスを入力する事も可能です。

 

全ての設定が完了したらNextを選択して下さい。

 

3-8.設定完了

 

以上の設定により、設定が完了しました。StatusにActiveと表示されていれば、設定完了です。

 

 

4.LDS設定確認

LDS設定の詳細を確認したい場合、歯車マークを選択後、Viewを選択して下さい。

 

Viewを選択後、LDS設定の詳細が確認出来ます。

 

以上でLDSの新規設定が完了し、設定した開始日よりアクセスログの収集が開始されます。

尚、LDSの設定反映に時間がかかる事が有る為、ログ収集開始日の2日前までにLDSの設定を完了して下さい

 

LDSの設定変更・削除・一時停止・コピーについては別の記事でご紹介します。

こちらの投稿は20171013日の公開から更新されており、変更点は「New」又は「Updated」と記載しています。また、ページの最後に更新履歴を載せております。

 

Google/Symantec SubCA 移行の背景

2017年初頭、Google ChromeチームはTLS サーバ証明書発行の不手際についてSymantec社の調査を開始しました。これまでの間、Google Symantec両社は、GeoTrustRapidSSLThawteブランドを含むSymantec発行の証明書について、業界の信用を取り戻すべく努めています。Akamaiはこれまで同様、証明書のパートナーであるSymantecと緊密に連絡を取り合い、Akamaiをご利用のお客様のニーズを代弁するべく、提案へのフィードバックを行っています。

 

GoogleSymantecによると、Symantec が同社の既存PKIインフラストラクチャから発行した証明書は、20184月および201810月の2段階に分け、Google Chromeブラウザから段階的に無効化されます。これらの後は、Google Chrome(およびその他追随するブラウザ)はこれらの証明書が示すサイト向けの「セキュアパッドロック(鍵マーク)」の表示をいたしません。さらに、「安全でないサイト」の警告をアドレスバーに表示するか、エラーページを表示する可能性もございます。Google Chromeの後続バージョンにてSymantecの既存証明書を継続して信頼させるためには、(遅くとも201712月中には利用可能予定の)同社の新しいPKIインフラストラクチャ上で証明書を更新する必要があります。

 

Akamaiはお客様の円滑な証明書更新のため最善を尽くします。対象となるお客様証明書のほとんどは、Chromeによる措置が行われる前に自動で更新されます。その場合お客様に行っていただくアクションはございませんが、Akamaiが管理するお客様の証明書およびお客様が調達されているサードパーティ証明書の中には、お早めに更新いただく必要があるものがございます。これらについては、弊社が証明書更新のタイミングををChromeの無効化開始日より数ヶ月前に前倒しいたします。 

 

影響を受ける証明書

今後のGoogleSymantecの無効化スケジュールは、Symantecが発行した全ての証明書に影響します。Akamaiのお客様の場合、以下の証明書が含まれます:

  • Akamaiの管理下にある全てのSymantec OV SingleSANWildcardWildcard SAN 証明書。
  • Akamaiの管理下にある全てのGeoTrust OV SingleSANWildcard 証明書。
  • Akamaiの管理下にある全てのSymantec EV Single SAN 証明書。
  • 一部のお客様調達のサードパーティ証明書

 

Akamaiの管理下にある、Comodo およびLet’s Encrypt が発行した証明書は、今回の変更による影響はございません。

 

無効化のスケジュール

Chrome 6620183Beta4月に安定版)では、201661日より前にSymantecが発行した証明書は信頼しません。

  • Akamai経由で発行された現在有効なSymantecおよびGeoTrustブランドのOV証明書は、この無効化による影響はございません。これらのOV証明書は全て201661日より後に発行されています。
  • Akamai経由で発行された現在有効なSymantecブランドのEV証明書は、この無効化による影響はございません。これらのEV証明書は全て201661日より後に発行されています。

 

Chrome 7020189Beta10月に安定版)では、2017121日より前にSymantecが発行した証明書および同社旧来のPKIインフラストラクチャから発行された証明書を信頼しません。

  • Akamai経由で発行された全てのSymantecおよびGeoTrustブランドのOV証明書は、この無効化の対象となります。
  • Akamai経由で発行された全てのSymantecブランドのEV証明書は、この無効化の対象となります。

 

GoogleおよびSymantec は、2017121日以降にSymantecおよびGeoTrustが発行した証明書は、Chromeが予定している全ての後続バージョンにおいて信頼されると述べています。

 

新しい信頼チェーン Updated

GoogleSymantec は、2017121日以降に注文・発行された証明書は、新しいPKIインフラストラクチャ上で発行されると述べています。新しい証明書には、現在取得されるものとは異なる信頼チェーン(中間証明書およびルート証明書)が発行されます。新しい信頼チェーンは既存ブラウザからの認証が続行するため、この変更にお気づきになるエンドユーザは少ないと思われます。GeoTrustSymantecブランドで発行されたOV証明書はRSAECDSA共に“DigiCert Global Root CA”にチェーンします。Symantecから発行されたEV証明書はRSAECDSA共に “DigiCert High Assurance EV Root CA”にチェーンします。どちらのルート証明書もウェブブラウザ及びOSのトラストストアを広くカバーしています。以前の“VeriSign Class 3 Public Primary Certification Authority - G5”にチェーンする証明書を使用するプロパティにアクセスしていたクライアントのほとんどは証明書が更新されると共に新しい信頼チェーンを用いて同じプロパティに接続出来る様になります。

 

Akamaiでは、SSL/TLS certificate chains for Akamai-managed certificatesAkamai経由で発行された証明書のSSL/TLS 証明書チェーン)を公開しております。このリストにはAkamai経由で2017121日以降に注文・発行されたGeoTrustSymantec証明書の新しい信頼チェーンを掲載しております。

 

Symantecからの新しい信頼チェーン提供に伴い、Akamaiは “VeriSign Class 3 Public Primary Certification Authority - G5”ルート証明書(通称 “G5” root証明書)とレガシーの“Class 3 Public Primary Certification Authority”ルート証明書(通称“1k root”証明書)にチェーンする証明書の提供を終了致しました。お客様にはできるだけ早くこのCross-signed 1k root の設定を変更されるようお奨めします。TLSクライアントがDefaultの信頼チェーンをサポートするようアップグレード済みの為、ほとんどのお客様には、Cross-signed 1k rootの必要はありません。CPS内で、証明書の「Default」信頼チェーンを選択することで今すぐ設定の変更が可能です。

 

お客様にとっていただくべきアクション

  • 201661日より前に発行された証明書をお持ちの場合は、20184月までに更新いただく必要があります。該当するお客様には弊社より直接ご連絡し、20181月に対象となる証明書の早期更新を始めます。
  • 201710月より前に発行された現在有効のAkamai経由で発行されたOV証明書は全て、自動的に期限の60日前から更新いたします。つまり、201710月より前に発行された証明書は、全て201810月の無効化前に有効期限を迎えます。既存の証明書は新しい証明書に更新されるまでブラウザでの信頼が続行されます。通常通り、Symantecからの認証のためのEメールおよび電話にご返答いただく以外は、お客様に必要なアクションはございません。
  • その他の、201710月から12月の間にAkamai経由で発行されたOV証明書と全てのEV証明書は201810月までに更新される必要があります。対象となるお客様には20181月より順次Akamaiからご連絡いたします。201810月の無効化前に証明書が更新できるよう、通常の更新日より前に証明書更新を行う予定です。
  • 予定されたSymantec発行の証明書無効化は、GeoTrust,RapidSSLThawteを含む全てのSymantecブランドに適用されます。Akamai Secure CDN上にこれらのブランドのサードパーティ証明書をお持ちのお客様も、この変更による影響を受ける可能性があります。対象のサードパーティ証明書は、2017121日以降に、弊社CPSからCSRを生成しダウンロードいただき、そのCSRSymantecに送付し新しい証明書を取得することにより、証明書の更新が可能です。
  • お客様はいつでも、(Akamai経由で発行しているか、サードパーティかにかかわらず)これらの証明書の早期更新を実施することが可能ですが、証明書がSymantecの新PKIインフラにより発行される2017121日まで、お待ちにいただくことを推奨します。早期更新を実施する場合はCPSにてお持ちの証明書の“Edit and Submit” 操作を行ってください。

 

FAQ(よくある質問)

この変更による、コストや契約への影響はありますか?

現在ご契約の料金は変わりません。また、追加の契約処理も必要ございません。

 

Akamaiはなぜ、証明書発行におけるSymantecとの提携を続けるのですか?

Symantec(今後はDigiCert)はSSL/TLS証明書発行における世界最大手であり、弊社の顧客ベースのニーズに最適であることに変わりがないためです。20164月に発表しましたように、Symantecは、引き続きOV およびEV 証明書発行におけるAkamaiの戦略的パートナーです。

 

SymantecからのOVEV証明書を希望しない場合はどうなりますか?

Let’s EncryptDV SAN証明書を、Akamaiより提供しております。また、お客様がご希望のSSL証明書の種類・認証局を選ぶことができる、サードパーティ証明書もご用意しております。

 

SymantecPKI事業の、DigiCertへの売却は、利用中の証明書にどう影響しますか? Updated

DigiCertの親会社である Thoma BravoSymantec PKI 事業を買収したのは2017 10月(Symantecの会計年度では2018年第3四半期)のことです。現行の計画では、この買収は上記の移行プロセスには影響しない予定です。売却後も、Akamai経由で発行されたOVEV証明書をお持ちのお客様は現在と同じ様に弊社Luna ポータルのCPSをご利用いただけます。GoogleおよびSymantec は、2017121日以降に新しいSymantec PKIインフラストラクチャが発行した証明書は、その有効期限日まで引き続き信頼されると述べています。新しく発行された証明書は既存のDigiCert rootにチェーンします。

  

Google Chrome以外のどのブラウザで証明書が無効化されますか? New

Mozillaの発表によると、FirefoxGoogleChromeについて発表したスケジュールと同様のスケジュールで証明書を無効化します。お客様のプロパティがGoogle Chromユーザをターゲットにしていない場合も、予定されている無効化スケジュール前に更新される事を推奨します。

 

Google Chrome Web Inspector内のJavascriptコンソールが当社のサイトの証明書について警告を表示しています。どうしたらよいですか? New

ほとんどのお客様の証明書は無効化スケジュール前に有効期限を迎え更新されます。新しい発行された証明書はChromeによる無効化外であり、有効期限までご利用頂くことができます。これらの更新された証明書においては、警告は無視して問題ありません。20189月以降に有効期限を迎える証明書については、Akamaiが証明書の更新開始日をChromeの無効化スケジュールの数ヶ月前に前倒しします。これにより、対象の証明書が無効化スケジュールより前に更新される為の時間を作ります。

 

当社のアプリケーションは信頼チェーンの変更に影響を受けやすいのですが、どうしたらよいですか?

Certificate Provisioning System (CPS)の中で、お使いの証明書上でChange Management (“Test on Staging”) ONになっているかをご確認ください。この機能により、お客様は、本番環境に展開する前にStagingにて新しい証明書を検査し試験することができます。Akamaiでは、クライアントアプリケーション内で証明書をピン留めすることはお奨めしません。

 

現在の証明書の更新前に、新しい信頼チェーンを確認できますか?

中間証明書、ルート証明書を含む新しい信頼チェーンはCommunityページのSSL/TLS certificate chains for Akamai-managed certificatesAkamai経由で発行された証明書のSSL/TLS 証明書チェーン)にてご覧いただけます。

 

当社のアプリケーションは現行の“PCA-G5”ルート証明書(“C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5”)を必要とします。 どうすればプロパティにこのルート証明書を使い続けることができますか? New

お客様にはできるだけ早くこの“G5”ルート証明書及び関連する信頼チェーンから設定を変更されるようお奨めします。Symantecは本ルート証明書へチェーンする証明書のパートナ経由での発行を終了しました。Symantecは、Symantecとお客様の直接契約では提供を継続する可能性があります。201712月以降、Akamai経由で発行される証明書について、本ルート証明書を持つ証明書を提供することができません。お客様が本ルート証明書を持つ証明書をSymantecから直接取得する場合、Akamaiの3rd Party証明書サービスをお使い頂くことができます。詳細については貴社アカウントチームまでお問い合わせください。.

 

当社のアプリケーションに、もし、“C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority” ルートで提供された例のような、Cross-signed 1k rootの設定が必要な場合はどうしたらよいですか? Updated

お客様はできるだけ早くこのCross-signed 1k rootの設定を変更されるようお奨めします。Symantecは公式には1k rootオプションのサポートを終了しており、201712月より、Akamai経由で発行された証明書においてこのオプションを提供することができません。もし貴社のWeb資産が引き続き1k root証明書を必要とする場合は、3rd Party証明書サービスを利用した方法について貴社アカウントチームにご相談ください。

 

当社の証明書の“Cross-signed 1k root”オプションがCPS上で有効になっている場合はどうなりますか? New

“Cross-signed 1k root”1k root証明書にチェーンするCross-signed証明書付きのSSL/TLS証明書を発行するレガシーオプションです。これらの証明書は古いもしくは更新できないトラストストアを持つレガシーのデバイスやプラットフォームをサポートします。1k rootのオプションは現在我々の認証局によってサポートされておりませんので、本オプションを有効にしている証明書は次回の証明書発行時にデフォルトの信頼チェーンが発行されます。

 

この変更はOCSP Staplingに影響しますか? New

OCSP Staplingを用い、Akamaiは証明書の有効性と失効の有無を認証局から取得し、その情報をクライアントとAkamaiサーバ間のTLS通信に埋め込みます。この機能はブラウザとクライアントの認証局OCSPサーバへの接続を省き、接続にかかる時間を短縮します。Akamai経由で発行された証明書についてOCSP Staplingのサポートは継続されます。201712月より数週間、OCSP Staplingにサービス断が発生する可能性があります。それ以外の全てのサービスは通常通り継続され、証明書はセキュアな配信にご利用いただけます。我々はSymantec証明書へのOCSP Staplingサービスをできるだけ早く、お客様による対処や変更を必要としない形で再開する所存です。

 

201712月より前に新しいSymantec 証明書を取得できますか?

お客様にはいつでも証明書の更新をいただくことが可能ですが、弊社としては、証明書がSymantecの新PKIインフラにより発行される2017121日までお待ちになることを推奨します。早期更新を実施する場合は、CPSでお持ちの証明書の“Edit and Submit” 操作を行なってください。

 

Akamaiは、なぜ、201712月以降の早期更新を強いらずに、ほとんどの証明書の期限が来て交換されるまで待っているのですか? 

お客様のSymantec 証明書の全てを早期更新することもできますが、弊社はSecure CDN上で数万もの証明書を管理しています。証明書更新日が1年の中で分散されていたほうが、Akamaiのお客様を含めよりよい状態となります。

 

当社の証明書は12月1日に更新中/SANの変更中でした。証明書に影響はありますか? New

お使いの証明書の信頼チェーンをご確認いただき、こちらのCommunityページに記載された新しい信頼チェーンが利用されていない場合は、2018年9月より前に更新される必要があります。Akamaiは証明書の更新開始日をChromeの無効化スケジュールの数ヶ月前に前倒しします。これにより、対象の証明書が無効化スケジュールより前に更新される為の時間を作ります。

 

201712月1日以降に証明書の更新リクエストがSymantecに送信された後、再度OV/EVの認証プロセスに対応する必要がありますか? Updated

証明書の更新時期の正確な認証手順は、業界標準のCA/Browser Forum ガイドラインに沿って、Symantecにより決定されます。SymantecGoogleは、Symantecの旧PKIインフラストラクチャからの(12月1日より前に出されたリクエストの)認証記録を再度利用することはできないと述べています。 

 

現在GeoTrust を利用中です。このGeoTrust 証明書はどうなりますか? Updated

Akamaiを通じて発行された(Symantec ブランドの1つである)GeoTrust証明書をお持ちのお客様は、引き続きGeotrustにて証明書が更新されます。201712月より前に発行されたGeoTrust証明書がChromeブラウザに認証される為には、201810月までに更新を完了する必要がございます。2017年12月以降に発行されたGeoTrust証明書には新しい信頼チェーンとルート証明書が適応されます。新しく発行されたGeoTrust証明書は有効期限を迎えるまで信頼されます。

 

当社のアプリケーションは“GeoTrust Global CA”ルート証明書を必要とします。どうすればこのルート証明書にチェーンする証明書を取得できますか? New

Akamaiでは2017年12月1日以降、“GeoTrust Global CA”ルート証明書にチェーンする証明書を提供することができません。本ルート証明書にチェーンする証明書が必要なお客様はGeotrustに直接ご連絡いただき、弊社の3rd Party証明書サービスを使ってAkamaiネットワーク上にアップロードすることができます。詳細はお客様の担当アカウントチームにお問い合わせください。

 

現在利用しているGeoTrust 証明書をSymantecSSL証明書に変えることはできますか?

新しい認証局(CA)への移行については、お客様の担当アカウントチームにお問い合わせください。

 

Let’s EncryptDV SAN証明書は、この変更による影響はありますか?

これらの変更によるLet’s Encrypt 証明書への影響はございません。

 

当社では今でもAkamai経由で発行されたComodoEV証明書を利用しています。この変更による影響はありますか?

Akamaiが管理するComodo EV の証明書はこれらの変更には影響されません。以前お知らせの通り、既存のComodo 証明書は現在の証明書の期限がくる前にSymantec 証明書へと移行されます。2017121日より前にこの移行が行われた場合、そのSymantec EV証明書は201810月までに再度更新する必要があります。

 

サードパーティ証明書を利用していますが、この変更に影響されますか?

Akamai Secure CDN上に「GeoTrustRapidSSLSymantecThawte」のサードパーティ証明書をお持ちのお客様は、この変更による影響を受ける可能性があります。これらのサードパーティ証明書は、2017121日以降に交換可能です。弊社Certificate Provisioning System (CPS)からCSRを作成してダウンロードいただき、そのCSRSymantecに送って新しい証明書を取得いただくことができます。

 

Akamaiが共有する証明書の信頼チェーンは、変わりますか?

a248.e.akamai.net *.akamaihd.net*.akamaihd-staging.net *.akamaized.net *.akamaized-staging.net」のホスト名に使用される、“a248” 共有証明書の信頼チェーンは、GoogleSymantec両社からの指示に合わせて変更されます。新しい信頼チェーンが利用可能になり次第、Communityページの「SSL/TLS certificate chains for the Akamai shared certificate Akamai共有証明書のSSL/TLS証明書チェーン)」にて新しい証明書の情報を公開します。

 

当社のオリジンサーバにはSymantec発行の証明書があります。Akamaiがこの証明書の信頼をやめるのはいつですか?

Akamaiは、Akamai Secure CDNからオリジンサーバへの接続に関し、これらの証明書の有効期限が切れるまで、Symantec証明書の信頼を続けます。

 

 

本件の英文Akamai Community Postについてはこちらをご覧下さい。

 

この移行についてご不明な点がございましたら、お客様担当のアカウントチーム、または弊社テクニカルサポートまでご連絡ください。

 

 

2018122日更新:

新しい信頼チェーン、“G5”“1k”ルート証明書の終了、DigiCertSymantec PKI事業の買収、Mozillaの無効化プランとOCSP Staplingについて情報を追加。

 

本記事では、新しいCPS(2017年11月リリース)におけるCSR(Certificate Signing Request)情報の制限を、紹介させていただきます。

 

CSRに記載されるCommon NameやOrganization Nameなどには、使用できる文字やその文字数に制限があります。

実際にCPSで発行する前にご確認をお願いいたします。

 

CSR情報使用できる文字使用できる文字数
Common Name

半角英数字、"-" ハイフン、"." ドット

64文字
Organization NameUTF-8文字(文字コードが00からCxで始まるもの)64文字
Organization UnitUTF-8文字(文字コードが00からCxで始まるもの)64文字
LocalityUTF-8文字(文字コードが00からCxで始まるもの)64文字
StateUTF-8文字(文字コードが00からCxで始まるもの)64文字

 

※アカマイ経由でSymantec社、Let's Encryptの証明書を調達する場合、お客様ご自身で証明書を調達する場合、いずれも該当します。

本記事では、新しいCPS(2017年11月リリース)にてOV証明書を申請する方法を、紹介させていただきます。

 

1. 「設定」より「Certificate Provisioning System (CPS)」をクリックし、CPSに移動する

 

2. 「Create New Certificate」より、証明書申請ページに移動する

 

3. 証明書の認証タイプにて、今回はAkamai Managed Certificate配下の「Organization Validation (OV)」を選択する

選択後、右下の「Next」をクリックして、次のステップに進みます。

 

4. 申請したい証明書のタイプ及び認証局を選択する

選択後、右下の「Next」をクリックして、次のステップに進みます。

※2018年1月現在、アカマイ経由で発行できるOV証明書の認証局は、Symantecとなります。

 

5. 証明書のCommon Name、SANs、会社情報を入力する

入力後、右下の「Next」をクリックして、次のステップに進みます。

※CSRに記載される情報(Common NameやOrganization Nameなど)には制限があります。詳細はこちらをご確認ください。

 

6. 申請会社情報を確認する

 5.で入力した会社情報と同じ場合、「Same as certificate company information」にチェックします。

 5.で入力した会社情報と異なる場合、「Same as certificate company information」のチェックを外し、情報を入力してください。

確認後、右下の「Next」をクリックして、次のステップに進みます。

 

7. お客様情報およびアカマイ技術担当者情報を入力する

 ・お客様情報の最下部にある会社情報は、5.と同じ場合、「Same as certificate company information」にチェックします。

  5.と異なる場合、Same as certificate company information」のチェックを外し、情報を入力してください。

 ・アカマイ技術担当者情報には、以下を入力してください。

項目入力していただく情報
First NameJapan
Last NameAkamai
Email Address

ssl-cps-jp(あっとまーく)akamai.com

※(あっとまーく)を@に変更してください。

Phone Number+81-3-4589-6500

 

入力後、右下の「Next」をクリックして、次のステップに進みます。

 

8. ネットワーク設定を確認する

 申請する証明書のネットワーク設定を行います。

選択後、右下の「Review」をクリックして、入力・選択した情報に誤りがないか確認してください。

 ※Certificate ChainのCross-Signed 1k rootオプションは、2018年1月現在EOLとなっており、利用することはできません。

 ※Cipher Profileはデフォルトで最新のものが選択されます。別のものを設定する必要がある場合は、証明書が展開された後、変更することが可能になります。9.でSubmit直後にも変更可能ですが、変更してしまうとCSRが再発行されてしまうため、証明書を一度展開した後に実施することをお勧めいたします。

 

9. 「Submit」をクリックして、申請を完了する

新しいCPS(2017年11月リリース)でも、これまで同様、証明書の申請には証明書のご契約が必要です。

本記事では、CPSにて証明書契約状況を確認する方法を、紹介させていただきます。

 

1. 「設定」より「Certificate Provisioning System (CPS)」をクリックし、CPSに移動する

 

2. 「Create New Certificate」より、証明書申請ページに移動する

 

3. 申請可能な証明書の種類を確認する

上の場合、グレーアウトされていない「Organization Validation (OV)」と「Third Party」を申請することが可能です。

申請可能な証明書の枚数を確認したい場合は、右側の「Select Different Contract」をクリックします。

※ご契約の状況により、「View Contract Details」となっている場合があります。

 

4. より詳細に申請可能な証明書の枚数を確認する

証明書の種類(OV、EVなど)、展開の種類(SNI Onlyなど)ごとにご契約枚数、利用済み枚数、利用可能枚数をご確認いただくことが可能です。

例えば上の表の場合、標準展開のOV証明書(Single, SAN & Wildcard)を4枚とThird Party証明書を1枚申請することが可能となります。

 

ご不明な点があれば、コメントいただければと思います。

今回はmacOSやLinuxに標準インストールされ,コマンドライン上で利用できるHTTPクライアント"curl"を用いてアカマイのデバッグをする方法について説明します.

 

アカマイのデバッグ方法に関しては,こちらの記事でスプーフィング(hostsファイル書き換え)とブラウザを用いた動作確認方法を解説しており,こちらの方が一般的かもしれません.しかし,curlを用いたデバッグ方法は通常のブラウザを用いる方法と比べると下記のようなメリットがあります.

 

  1. terminalから実行できる
  2. スプーフィング(hostsファイル書き換え)が不要
  3. プラグインなしでakamaiデバッグヘッダを確認できる
  4. 処理がバッチ化できテスト自動化が容易
  5. リモートマシン上でのテストが容易(ssh経由などで利用)

 

今回は下記のような環境を想定して,実際にcurlコマンドを用いてアカマイの動作確認をする方法を具体的にみていきたいと思います.

 

 

1. エッジサーバにリクエストを出す

スプーフィングをせずにcurlを用いてステージングテストするには下記のようにcurlコマンドを実行します.

$curl -I -X GET -k -H "Host: www.myexample.com" 'https://www.myexample.com.edgekey-staging.net/foo/bar/index.html'

HTTP/2 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=1
Content-Length: 18477
Content-Type: text/html
Expires: Sat, 05 Aug 2017 00:30:20 GMT
Last-Modified: Tue, 01 Aug 2017 07:11:16 GMT
Server: Apache
Date: Sat, 05 Aug 2017 00:30:19 GMT
Connection: keep-alive
X-Akamai-Staging: ESSL

コマンドオプションの意味は下記の通りです.

  • -I: レスポンスヘッダのみを表示
  • -X GET: リクエストとしてGET Methodを指定
  • -k : SSL handshakeにおいて,SSL証明書のCommon Nameマッチエラーを無視
  • -H "Host: www.myexample.com": hostヘッダにプロパティホスト名を指定する

 

リクエストURIのホスト部分にステージングのエッジホスト名(www.myexample.com.edgekey-staging.net)を指定することで,ステージングエッジサーバへリクエストを送信することが可能になります.ただし,SSL handshakeにおいて,Common Nameミスマッチ(CN=www.myexample.com vs リクエスト=www.myexample.com.edgekey-staging.net)が発生するため,-kオプションでエラー回避を行う必要があります.

 

リクエストの結果をみると,X-Akamai-Staging: ESSL が返ってくるため,ステージングエッジサーバへアクセスができていることを確認できます.

 

上記のURIのホスト名をwww.myexample.com.edgekey.netとすることで,アカマイプロダクションのエッジサーバへリクエストを送信することができます.この方法は直接エッジホスト名を指定しているため,CNAME前であってもアカマイプロダクションのテストが可能です.

 

 

2. アカマイデバッグヘッダを確認する

こちらのブログ記事 Akamai設定の検証やデバッグ方法(Chrome編) にあるとおり,アカマイのエッジサーバはPragmaヘッダを含めてリクエストを出すとレスポンスにデバッグ情報を載せて返してくれます.curlにおいても

  • -H "Pragma: akamai-x-cache-on,akamai-x-cache-remote-on,akamai-x-check-cacheable,akamai-x-get-cache-key,akamai-x-get-extracted-values,akamai-x-get-request-id,akamai-x-serial-no, akamai-x-get-true-cache-key"

オプションを追加することで,アカマイデバッグヘッダを参照することが可能になります.

 

$ curl -I -k -X GET -H "host: www.myexample.com" 'https://www.myexample.com.edgekey-staging.net/foo/bar/index.html' -H "Pragma: akamai-x-cache-on,akamai-x-cache-remote-on,akamai-x-check-cacheable,akamai-x-get-cache-key,akamai-x-get-extracted-values,akamai-x-get-request-id,akamai-x-serial-no, akamai-x-get-true-cache-key"

HTTP/2 200
content-type: text/html
last-modified: Tue, 25 Apr 2017 08:22:18 GMT
accept-ranges: bytes
server: Apache
x-check-cacheable: NO
x-akamai-request-id: 332fc.1254a1
x-akamai-transformed: 9 3538 0 pmb=mRUM,1
date: Wed, 27 Dec 2017 06:22:25 GMT
content-length: 4567
x-cache: TCP_MISS from a23-48-169-52.deploy.akamaitechnologies.com (AkamaiGHost/9.1.4.4-21488373) (-)
x-cache-key: S/D/98765/123456/000/www.myexample.com/space/foo/bar/index.html
x-true-cache-key: /D/000/www.myexample.com/space/foo/bar/index.html
x-akamai-session-info: name=AKA_PM_BASEDIR; value=
x-akamai-session-info: name=AKA_PM_BYPASS_TD; value=true
x-serial: 98765
x-cache-remote: TCP_MISS from a23-48-168-37.deploy.akamaitechnologies.com (AkamaiGHost/9.1.4.4-21488373) (-)
x-akamai-staging: ESSL

上記の通り,デバッグ情報が参照できます.

 

 

3. SSL handshake + 送信ヘッダを確認する

問題切り分けのために,さらに詳細なリクエスト/レスポンスの過程を表示したい場合が往往にしてあります.curlでは-svオプションをつけることで,SSL handshake過程,リクエスト過程,レスポンス過程を参照することができます.

$ curl -I -X GET -k -H "Host: www.myexample.com" https://www.myexample.com.edgekey-staging.net/foo/bar/index.html -sv > /dev/null -H "Pragma: akamai-x-cache-on,akamai-x-cache-remote-on,akamai-x-check-cacheable,akamai-x-get-cache-key,akamai-x-get-extracted-values,akamai-x-get-request-id,akamai-x-serial-no, akamai-x-get-true-cache-key"

*   Trying 104.71.85.161...
* Connected to www.myexample.com.edgekey-staging.net (104.71.85.161) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /usr/local/etc/openssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [102 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2478 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=www.myexample.com
*  start date: Dec  4 17:26:21 2017 GMT
*  expire date: Mar  4 17:26:21 2018 GMT
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x7fb65d80aa00)
} [5 bytes data]


> GET /foo/bar/index.html HTTP/1.1
> Host: www.myexample.com
> User-Agent: curl/7.50.0
> Accept: */*
> Pragma: akamai-x-cache-on,akamai-x-cache-remote-on,akamai-x-check-cacheable,akamai-x-get-cache-key,akamai-x-get-extracted-values,akamai-x-get-request-id,akamai-x-serial-no, akamai-x-get-true-cache-key
>
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
} [5 bytes data]


< HTTP/2 200
< content-type: text/html
< last-modified: Tue, 25 Apr 2017 08:22:18 GMT
< accept-ranges: bytes
< server: Apache
< x-check-cacheable: NO
< x-akamai-request-id: 1ebbab.12dc10
< x-akamai-transformed: 9 3538 0 pmb=mRUM,1
< date: Wed, 27 Dec 2017 06:45:15 GMT
< content-length: 4567
< x-cache: TCP_MISS from a23-48-169-52.deploy.akamaitechnologies.com (AkamaiGHost/9.1.4.4-21488373) (-)
< x-cache-key: S/D/98765/123456/000/www.myexample.com/space/foo/bar/index.html?akamai-transform=9
< x-true-cache-key: /D/000/www.myexample.com/space/foo/bar/index.html
< x-serial: 98765
< x-cache-remote: TCP_MISS from a23-50-62-39.deploy.akamaitechnologies.com (AkamaiGHost/9.1.4.4-21488373) (-)
< x-akamai-staging: ESSL
<
* Excess found in a non pipelined read: excess = 76 url = /foo/bar/index.html (zero-length body)
* Connection #0 to host www.myexample.com.edgekey-staging.net left intact

上記結果の通り,SSL handshake,リクエスト,レスポンスの過程が時系列順で表示されます.これにより,リクエストのどの過程で問題が起きているのかなど,詳細を調べることができます.

 

 

4. まとめ

今回紹介したcurlによるテスト方法は,ブラウザでテストできない場合や,アクセス制限などによってスプーフィングやリクエストヘッダを追加できない場合に非常に重宝します.さらに,テスト自動化などDevOpsを意識したワークフローではほぼ必須になります.今回の紹介したテスト方法をアカマイ化プロセスにおけるデバッグ手法・検証作業効率化のひとつのオプションとして実践されてみてはいかがでしょうか.

2017年11月、新しいCertificate Provisioning System(CPS)がリリースされました。

これに伴い、以下のような変更が発生しています。

1. Luna Control Center上のメニュー

これまでCertificate Provisioning System(CPS)とCertificate Provisioning System(CPS)(Beta)という2つのメニューがありましたが、それぞれ以下のように変更されています。

  • Certificate Provisioning System(CPS) → Certificate Provisioning System(CPS)(Legacy)
  • Certificate Provisioning System(CPS)(Beta) → Certificate Provisioning System(CPS)

※ Certificate Provisioning System(CPS)を選択した場合、新しいUIに遷移しますのでご注意ください。

2. 旧Certificate Provisioning System(CPS)のEnd of Life(EOL)

新しいCertificate Provisioning System(CPS)のリリースに伴い、旧Certificate Provisioning System(CPS)がEOLを迎えます。時期は確定していませんが、2018年第一四半期を予定しています。

 

新しいCertificate Provisioning System(CPS)のリリースに伴い、このコミュニティ上の今後のCPSに関する記事は新しいCertificate Provisioning System(CPS)に合わせた内容となりますので、ご了承ください。

既存の記事の内容についても順次、新しいCertificate Provisioning System(CPS)に合わせてリニューアルしていく予定です。

現在、Akamaiの配信設定を作成/変更するときには主にProperty Managerから実施いただいておりますが、Property Managerがリリースされる前の配信設定エディタ、Configuration Managerは2018年3月迄にEOL(End of Life)となる予定です。(Config Manager final EOL delayed until Q1 2018)

 

※Configuration ManagerのEOLに関する情報はこちら(Configuration Manager Retirement)をご参照下さい。

 

そのため、Configuration Managerで作成された配信設定を参照すると以下のような警告画面が表示されます。本記事ではConfiguration ManagerからProperty ManagerへUpgradeする方法についてご紹介致します。

 

Property Managerへ移行する場合は、警告が表示されている箇所にある「Click here」をクリックします。

 

「Click here」をクリックするとProperty Groupsの画面へ遷移しますので、対象となる配信設定のActionにある「Upgrade」ボタンをクリックします。

 

次に対象となるバージョンとUpgrade typeを選択し、「Upgrade Property」をクリックしてProperty Managerでの配信設定を作成します。

 

Choose a version to upgradeUpgrade元となる対象バージョンを選択します。

Choose an upgrade type:2つのタイプから選択します。

Upgrade in-place同一プロパティ内で版数を上げて新規バージョンを作成する方法です。Congiruration Managerの設定情報をUI上で参照できなくなります。

Upgrade to new property:既存のConfiguration Managerを残し、新しいPropertyをバージョン1として作成する方法です。Property Managerの新しい配信設定をActivateする際、Configuration Managerの設定のProperty Hostname(Digital Property)が自動で取り除かれます。

 

 

Property Managerへ移行した配信設定は、必ずStaging環境にてリグレッションテストを実施し、結果に問題がないことを確認してからProduction環境へ展開下さい。

 

また、お客様のConfiguration Mangerの設定によっては本Upgrade方法を実施いただけない場合もございます。その際はアカウントチームへご連絡下さい。

 

LUNAの表示する言語をEnglishとしております。日本語の場合には表示されるメニュー名が翻訳されていることがあります。

1. はじめに

 

前回の記事では最も典型的なFailover設定であるNetStorageを用いたSorryコンテンツの配信設定について説明しました.これまでいろいろなFailover動作を紹介してきましたので,今回はそれら動作のおさらいとその比較をしてどのような場面でどの設定にすべきかを見ていきたいと思います.また,後半では,前回の記事ではカバーできなかった代替オリジンサーバからSorryコンテンツを配信する設定方法について説明いたします.

 

 

2. Failover時の代替コンテンツ提供方法の比較

 

前回の記事の再掲になりますが,アカマイではFailover時のSorryコンテンツの提供の方法として以下の3つの方式を提供しています.

 

  1. エッジサーバ上に有効期限切れのキャッシュが残っていれば,それを返す(Serve Stale Content)
  2. 別のURLにリダイレクトする(外部サイト)
  3. 代替オリジンサーバからSorryコンテンツを返す
    1. 同一配信設定内でFailoverを設定する(Use alternate hostname in this property) [後述]
    2. Failover用の配信設定を用いる(Use alternate hostname on provider network) [後述]

 

これらの動作の違いについて,もう少し詳しく見てみましょう.それぞれのリクエストの流れは下図の通りになります.

上の図で,オリジンサーバがダウンしてFailoverが動作した後のリクエストの違いについて見ていきましょう.

 

「1.エッジサーバ上に有効期限切れのキャッシュが残っていれば,それを返す(Serve Stale Content)」に関しては,Sorryコンテンツは提供されませんので,説明はこれだけに留めておきます.

 

「2. 別のURLにリダイレクトする(外部サイト)」(以下,リダイレクト)では,Failover時に一度ブラウザにリダイレクトのレスポンスが返り,その後ブラウザが代替ウェブサイトにコンテンツを取得しにいきます.よって,リダイレクト後の代替ウェブサイトはアカマイ化されている必要はありません.また,ブラウザ上では明示的に別のサイトとして扱われるため,アドレスバーにも代替ウェブサイトのURLが表示されることになります(SorryコンテンツのURLがアクセスユーザから見える形になります).当然ですが,代替ウェブサイトはそのドメインがDNSに登録され,一般公開されている必要があります.

 

「3. 代替オリジンサーバからSorryコンテンツを返す」(以下リクリエーション)は,Failover時にアカマイエッジサーバがSorryコンテンツのリクエストをリクリエーション(再生成)し,取得されたSorryコンテンツをブラウザに返します.よって,Failover時においてもブラウザのアドレスバーには通常アクセスと同様のURLが表示されることになります(SorryコンテンツのURLはアクセスユーザからは見えません).また,リダイレクトの場合とは異なり,ブラウザからは一度のリクエスト(元のリクエスト)でSorryコンテンツが返されるため,Sorryコンテンツが表示されるまでの時間が短縮されます.つまり,リクリエーションの場合,リダイレクトに比べて,よりシームレスにSorryコンテンツの配信を行うことが可能になります.

 

このようにリダイレクトとリクリエーションではユーザー体験に影響するため,要件に応じて適宜選択する必要があります.

 

 

3. 代替オリジンサーバを用いたSorryコンテンツ配信の概要

 

前節で説明した「3. 代替オリジンサーバからSorryコンテンツを返す」方式の実装についてさらに詳しく見ていきましょう.この実装方法には下記の2種類があります.

 

  1. 同一配信設定内でFailoverを設定する(Use alternate hostname in this property)
  2. Failover用の配信設定を用いる(Use alternate hostname on provider network)

 

どちらの設定でも代替オリジンサーバとしてNetStorage,もしくは,ユーザーが用意した代替オリジンサーバを用いることができます.前回の記事では,NetStorageを代替オリジンサーバとして「A. 同一配信設定内でFailoverを設定する」方法について解説しました.ただし,上記の2種類の実装方法に関して説明をしてませんでしたので,ここで比較をしてみたいと思います.

 

下図に示した通り,「A. 同一配信設定内でFailoverを設定する」方法では,各配信設定(Property)ごとにFailoverとSorryコンテンツの配信設定を設定するのに対して,「B. Failover用の配信設定を用いる」ではFailover時のSorryコンテンツ配信設定(図中ではProperty X (for Failover))を一つ作成し,それを複数の配信設定で共有することでFailover設定をするという違いがあります.よって,配信設定ごとに,Sorryコンテンツが異なる場合には「同一配信設定内でFailoverを設定する」必要があります. また,配信設定で特にFailover設定を共有化できる場合には「Failover用の配信設定を用いる」ことで設定作業の効率化を図ることができます.

 

 

また,Failover設定についての設定必要項目に関してもいくつかの違いがあります.これについては下記の表にまとめました.

 

A. 同一配信設定内でFailoverを設定する

(Use alternate hostname in this property)

B. Failover用の配信設定を用いる

(Use alternate hostname on provider network)

Failover用配信ホスト名のDNS登録不要

必要

(組み込みコンテンツなしのベースページだけであれば不要)

(SSL配信の場合) Failover用配信ホスト名のSSL証明書設定不要

必要

(組み込みコンテンツなしのベースページだけであれば不要)

Sorryコンテンツの配信設定配信設定ごとに個別設定一括で設定(複数の配信設定で共有)
Sorryコンテンツ内の組み込みコンテンツの指定方法

Failover用パスを決めて,絶対パスで指定

 

e.g.

<img  src="/sorrycontent/sorry.jpg">

Failover用配信ホスト名(Digital Property)で指定

 

e.g.

 <img src="//failover.myexample.com/

sorrycontent/sorry.jpg">

 

 

4. 代替オリジンサーバを用いたSorryコンテンツ配信設定

 (A. 同一配信設定内でFailoverを設定する + ユーザー代替オリジンサーバ)

 

この場合は,前回記事の「A. 同一配信設定内でFailoverを設定する + NetStorageオリジン」の設定方法において,オリジンサーバ設定でNetStorageを指定している部分をユーザーが用意した代替オリジンサーバに変更することで実現可能です.以下では,例として代替オリジンサーバとして"origin-failover-qt246ygk.myexample.com"を使用してSorryコンテンツを配信する設定例について見ていきます.ほどんど前回の設定に同じであるため,差分のみを説明します.

 

4.1 Sorryコンテンツの用意

基本的には前回の記事と同様です.前回の記事ではNetstorage上に配置したSorryコンテンツを今回用いるオリジンサーバ上に配置するのみです.ベースページ(sorry.html)のソースも変更はありません.

 

4.2 Luna上での設定

E. Sorry Contentルール

E-2. Origin Serverビヘイビア

代替オリジンサーバとして"origin-failover-qt246ygk.myexample.com"を指定します.それ以外の項目は代替オリジンサーバの環境に合わせて適宜変更する必要があります.例えば,SSL配信でSorryコンテンツを配信する場合はオリジンサーバ向けのSSL設定(Origin SSL Certificate Verification設定)をする必要があります.

 

上記以外の設定に関しては,前回の記事にある配信設定と同様になります.以上が,ユーザー代替オリジンサーバを用いて同一配信設定内でFailover設定を行う場合の実装方法になります.

 

 

5. 代替オリジンサーバを用いたSorryコンテンツ配信設定

    (B. Failover用の配信設定を用いる + ユーザー代替オリジンサーバ)

 

この場合は,上表で示している通り,Sorryコンテンツ内の組み込みコンテンツをFailover用配信ホスト名(Digital Property)で指定する必要があるため,Sorryコンテンツのベースページ(sorry.html)の内容を変更する必要があります.ここではFailover用配信ホスト名として"failover.myexample.com"を用いることにします.

 

5.1 Sorryコンテンツの用意

sorry.htmlは下記の通り"failover.myexample.com"で指定する必要があります.

<html>
  <head>
    <link rel="stylesheet" type="text/css" href="//failover.myexample.com/sorrycontent/sorry.css">
    <script type="text/javascript"  src="//failover.myexample.com/sorrycontent/sorry.js"></script>
  </head>
  <body>
    <h1>Sorry Page on NetStorage</h1>
    <img src="//failover.myexample.com/sorrycontent/sorry.png">
  </body>
</html>

 

また,Sorryコンテンツのは前節の設定と同様に代替オリジンサーバに配置する必要があります(下図は再掲).

 

5.2 Luna上での設定 - サイト配信設定 (Failoverを起動する側)

A. 配信ホスト名(プロパティホスト名)

Failover用の配信設定は別に作成するため,こちらにはサイト配信用のプロパティホスト名"site.myexample.com"のみ設定します.

 

B. Defaultルール

 

これまでと同様にサイト配信のための基本設定を行います.

 

C. Site Failoverルール

これまでと同様にOHDの設定を行います.

 

D. Faiover Triggerルール

Failoverの条件とその時の動作を規定します.

 

D-2. Site Failoverビヘイビア

Actionの項目で"Use alternate hostname on provider network"を選択します.また,Alternate Hostname on Provider Networkの項目では.Failover用の配信ホスト名である"failover.myexample.com"を指定します.これによって,Failover発生時にアカマイエッジサーバ上の"failover.myexample.com"の配信設定が参照されることになります.

 

 

以上がサイト配信設定になります.これまでのFailover設定にはあったSorryコンテンツ配信のためのルール("Sorry Cotentn", "Sorry Base Page"ルール)は後述のFailover用の配信設定内で設定されることになります.

 

 

5.3 Luna上での設定 - Failover用の配信設定 (Sorryコンテンツを配信する側)

Failover時にSorryコンテンツを配信するための配信設定になります.これを通常のサイト配信設定とは別に作成します.Luna上での配信設定のメイン画面の上部から見ていきましょう.

X. 配信ホスト名(プロパティホスト名)

上記の通り,Failover用のプロパティホスト名である"failover.myexample.com"を設定します.Sorryページの組み込みコンテンツはこの配信ホスト名でエッジサーバにアクセスすることになるため,サイト公開前にこの配信ホスト名をDNS登録(CNAME)する必要があります.また,同様の理由でSSL配信の場合にはSSL証明書の取得が必要になります.

 

Y. Defaultルール

 

DefaultルールではSorryコンテンツを配信するためのオリジンサーバの設定や各種キャッシュ,パス設定を行います.この配信設定はFailover時にしかアクセスが来ることがないため,これまでの設定であったような通常のサイト用コンテンツとFailover用コンテンツとを分離するためのマッチ条件などが不要になっています.

 

Z. Sorry Base Pageルール

こちらはSorryコンテンツのベースページ(sorry.html)をレスポンスコード503かつクライアント側でのキャッシュを許可しないための設定になります.この部分に関しては,これまでの設定と同様になります.

 

以上が,ユーザー代替オリジンサーバを用いてFailover用の配信設定によってSorryコンテンツを配信する場合の実装方法になります.

 

 

6. むすび

 

今回はFailoverに関しての一連の記事のまとめとして,Failover時のアカマイの動作の方式について比較し,利用用途に応じてどのようにFailoverの機能を使うべきかについて解説しました.また,後半では前回カバーできなかった代替オリジンサーバを用いたSorryコンテンツ配信設定について解説しました.異常系であるFailover動作は,ウェブサイトが正常に動作している間は全く隠れて見えない機能です.しかし,システム障害が発生した時であっても,サービスを継続するための最低限のコンテンツを配信することでビジネスインパクトを最小限に抑えることを可能にする価値のある機能です.これを機にFailoverの導入や設定の見直しの検討をされてみてはどうでしょうか.

 

注意: LUNAの表示する言語をEnglishとしております.日本語の場合には表示されるメニュー名が翻訳されていることがあります.

Pragmaヘッダに特定の値を含めてAkamaiサーバへリクエストを行うと様々なデバッグ情報が取得できます。(参考:Akamai設定の検証やデバッグ方法(デバッグヘッダ編))。これらのデバッグ情報を第三者に知られないために、今回はテンプレートルールからデバッグヘッダの表示を限定する方法についてご紹介します。

 

対象の配信設定に対してProperty Managerから設定変更を行います。「Edit New Version」から新しいバージョンを作成し、「Add Rule」をクリックします。

 

左の検索窓に「debug」と入力すると、Remove Debug Infoというルールが表示されますので、Insert Ruleをクリックします。

 

新しくRemove Debug Infoルールが追加されました。こちらのルールはリクエストのPragmaヘッダに特定のキーワードがあればPragmaヘッダを削除してリクエストする動作となります。

 

 

Criteriaの2つ目に書いてある「X-Akamai-Debug」の部分を、別のカスタム値に変更します。今回の例では「ASecureValue12345」と入力しました。

 

設定変更したバージョンをSaveして、AkamaiのStaging環境ネットワークに展開します。展開完了後、ブラウザのデベロッパーツール等でリクエストおよびレスポンスヘッダを確認します。Pragmaヘッダにデバッグ用のパラメータを入れても、Akamaiのデバッグヘッダが応答されないことが分かります。ブラウザ上で特定のヘッダを送信する方法はこちらの記事で紹介しております。(Akamai設定の検証やデバッグ方法(Chrome編)Akamai設定の検証やデバッグ方法(Firefox編))

 

続いて、リクエストヘッダに先ほど設定したカスタムヘッダ(ASecureValue12345: true)を追加してリクエストをします。今度はデバッグヘッダが応答されて、デバッグ情報を取得することができます。

 

Staging環境にて全てのテストを完了し、問題ないことを確認できればProduction環境に設定を展開します。設定が反映されましたら、Akamaiデバッグヘッダの表示が制限されるようになります。

 

LUNAの表示する言語をEnglishとしております。日本語の場合には表示されるメニュー名が翻訳されていることがあります。

これらの記事(Akamai設定の検証やデバッグ方法(Chrome編)Akamai設定の検証やデバッグ方法(Firefox編))にてご紹介している通り、Pragmaヘッダに以下パラメータを付与してリクエストを行うと、Akamaiのサーバからデバッグヘッダが応答されます。今回はその中でもデバッグに有用なヘッダについてご紹介します。

 

akamai-x-cache-on,akamai-x-cache-remote-on,akamai-x-check-cacheable,akamai-x-get-cache-key,akamai-x-get-extracted-values,akamai-x-get-request-id,akamai-x-serial-no, akamai-x-get-true-cache-key

 

X-Cache:Akamaiサーバのキャッシュに関連する動作と、その動作がどのAkamaiサーバによって応答されたかを示します。

例)TCP_MEM_HIT from a23-15-12-111.deploy.akamaitechnologies.com (AkamaiGHost/9.0.0.2-20192836) (-)

※from以降にあるハイフンで区切られている数字は、ドットに置き換えた場合のIPアドレスと一致します。(a23-15-12-111.deploy.akamaitechnologies.comの場合、IPアドレスは23.15.12.111となります。)

 

キャッシュに関連する動作としては以下にご紹介します。

TCP_HIT : Akamaiサーバのキャッシュ(ディスク)からコンテンツが配信された意味となります。
TCP_MEM_HIT : Akamaiサーバのキャッシュ(メモリ)からコンテンツが配信された意味となります。
TCP_MISS : Akamaiサーバにキャッシュが存在せず、オリジンサーバから取得されたコンテンツが配信された意味となります。
TCP_REFRESH_HIT : Akamaiサーバにキャッシュは存在しているが有効期限が切れているため、オリジンサーバへIf-Modified-Sinceリクエストを行い、HTTPステータスコード304「Not Modified」の応答を受け取った後にキャッシュからコンテンツが配信された意味となります。
TCP_REFRESH_MISS : Akamaiサーバにキャッシュは存在しているが有効期限が切れているため、オリジンサーバへIf-Modified-Sinceリクエストを行い、オリジンサーバから取得された新しいコンテンツが配信された意味となります。
TCP_REFRESH_FAIL_HIT : Akamaiサーバにキャッシュは存在しているが有効期限が切れているためオリジンサーバへIf-Modified-Sinceリクエストを行ったものの、何らかの理由でオリジンからコンテンツを取得できず、結果キャッシュからコンテンツが配信された意味となります。
TCP_IMS_HIT : クライアントからIF-Modified-Sinceリクエストを受け取り、AkamaiサーバからHTTPステータスコード304「Not Modified」が応答された意味となります。
TCP_NEGATIVE_HIT : オリジンからHTTPステータスコード404「Not Found」や504「Gateway Timeout」のように正常なコンテンツを配信できなかったケースがキャッシュされており、そのキャッシュが配信された意味となります。このようなキャッシュ時間は「Cache HTTP Error Response」のBehaviorで設定可能です。

なお、X-Cache-RemoteヘッダはTiered DistributionのようなAkamaiサーバを複数経由した場合の経由先サーバに関する同等の情報を示します。

 

X-Cache-KeyCache Key(キャッシュ識別子)に加えて、TTLやCPコード等を含みます。

例)/L/12345/123/1d/origin-www.example.com/index.html

 

こちらの例ではキャッシュの設定が1日で設定されているということ意味になります。1dの箇所が000であればキャッシュしない設定という意味になります。なお、この値はキャッシュの設定やオリジンのレスポンスヘッダによっては実際のキャッシュの有効期限と異なる動作となる場合があります。またTTL(1d)の前にある数字がCPコードになります。上の例では123が割り当てられたCPコードとなります。


X-True-Cache-Key:Cache Keyを示します。

X-Check-Cacheable:Akamaiでキャッシュ対象のコンテンツか否かをYESかNOで示します。(参考 : キャッシュ対象コンテンツの確認について

X-Akamai-Request-ID:リクエストIDはAkamaiの各サーバが払い出すユニークなIDとなります。Akamaiのサポートチームへトラブル等の原因調査を依頼するとき、こちらのリクエストIDとAkamaiサーバのIPアドレスをお伝え下さい。

これまでImage Managerの設定(Image Managerの設定方法について(配信設定編) 、Image Managerの設定方法について(Policy Manager編))についてご紹介しました。今回はImage Manager設定後に必要となる動作確認方法についてご紹介します。まず動作確認を行う上で非常に便利なChromeブラウザの拡張機能Piezをご紹介します。

 

Piezは以下のページから取得できます。

 

インストール後にはPiezアイコンが表示されていることを確認します。

 

PiezアイコンをクリックしてImage Manager(Advanced)を選択します。これで事前準備が完了です。

 

それではデベロッパーツールを表示します。デフォルト設定ではWindowsの場合はF12キーを、Macの場合はCommand+Option+Iキーを押すとデベロッパーツールが表示されます。デベロッパーツールが表示されましたらPiezセクションを選択します。

 

実際にImage Managerを利用しているサイトへアクセスするとブラウザが取得した画像情報が表示されます。

 

Piezは複数項目から構成されるため、各項目について確認していきます。一番上の項目では読み込みを行った該当ページに含まれる画像に対して、全体でどれぐらい容量を削減できたか確認できます。以下の例では16個の最適化された画像が配信され、画像最適化前と比較すると91%(3.96MiB)も容量が削減されたことが分かります。

 

Optimized Offline Detailsの項目ではImage Managerにて最適化画像が配信された画像情報を確認できます。それぞれの意味については以下にご紹介します。

Transformed Image Type:画像変換後のファイル形式

※配信設定側のBehavior「Image Optimization Settings」の「Use Best File Type」をOnにした場合各ブラウザ毎の最適な画像フォーマットが配信されます(参考:Image Managerの設定方法について(配信設定編)

Original Width:画像変換前の横幅[ピクセル]

Pixel Density:ピクセル密度

File Chosen:適用されたImage Managerのファイル名

※ファイル名は、例「.auto.2.960.chrome」のように左から「ポリシー名(.autoの場合はデフォルトポリシー).ポリシーのバージョン.適用された画像の横幅(ピクセル単位).対応ブラウザ」で構成されます

Encoding Quality:画像変換後の画像品質レベル

※Image ManagerのPolicy Managerで設定するDerivative Image Qualityで設定する箇所に該当します(参考:Image Managerの設定方法について(Policy Manager編)

Original Size:画像変換前のファイルサイズ[Bytes]

Transformed Size:画像変換後のファイルサイズ[Bytes]

%Bytes Change:画像変換前後におけるファイルサイズの変化割合[%]

 

なお、URLの部分をクリックすると実際の画像を確認できます。「Click The Image To Toggle」をクリックすると矢印の箇所にある通り、変換前と変換後の画像比較をできますので、画像品質が劣化していないかを確認できます。

 

Optimized Realtime Detailsではファイルサイズの変化量を確認できます。こちらの項目は表示されない場合もあります。

 

最後に表示されている項目、Non Image Manager ImagesがImage Managerの対象とならない画像情報が表示されます。配信設定側でImage Managerの対象としていないパスや拡張子はこちらの項目に表示されます。

 

このようにPiezを利用することで、Image Managerがどのように動作しているかを詳しく確認できるようになります。ぜひImage Managerをご利用頂く場合はPiezを使って動作確認を試してみて下さい。