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

1.はじめに

アカマイの配信設定を作成する際にご利用頂くProperty Managerには、アカマイのエッジサーバ上でのキャッシュに関する設定を決めるCaching Behaviorがあります。こちらのBehaviorでは、キャッシュする・しないといった基本的な挙動から、細かいオプションまで設定する事ができます。そこで本投稿では、Caching Behaviorの解説を行います。

 

2.Caching Behaviorの解説

Caching Behaviorには、6つのオプションが有り、2つの種類に大別できます。

 

 

最初の3つのオプション(Cache/No Store/Bypass Cache)はエッジサーバでキャッシュを制御するオプションです。エッジサーバでキャッシュのTTLや、キャッシュをしない設定をする事ができます。

 

最後の3つのオプション(Honor Origin Cache Control and Expires/Honor Origin Cache Control/Honor Origin Expires)はオリジンサーバのレスポンスヘッダに設定されているキャッシュ設定を優先するオプションです。

このオプションでは、エッジサーバでキャッシュのTTLを設定しつつ、オリジンサーバからCache ControlヘッダやExpiresヘッダが返却された場合、オリジンサーバの値を優先します。以下、それぞれのオプションについて解説します。

 

 

2-1.Cache

このオプションを選択すると、コンテンツをエッジサーバでキャッシュします。

 

設定例:

オプション:

Force Revalidation of Stale Objects

エッジサーバがオリジンサーバにStale Object(TTLが期限切れとなったコンテンツ)の有効性を再確認する際の挙動を設定します。 

   Serve stale if unable to validate

   コンテンツの有効性を再確認出来なかった場合、エッジサーバはStale Objectをクライアントに返却します。

   Always revalidate with origin

   コンテンツの有効性を再確認出来なかった場合、エッジサーバはクライアントにエラーを返却します。

 

Max-age:コンテンツのTTLを設定します。

 

2-2.No Store

このオプションを選択すると、エッジサーバはコンテンツをキャッシュしません。また、もしエッジサーバにコンテンツのキャッシュが有った場合、キャッシュを削除します。

設定例:

 

 

2-3.Bypass Cache

このオプションを選択すると、エッジサーバは自身が持つキャッシュをバイパスし、オリジンサーバに対してリクエストを送信します。No Storeと違い、もしエッジサーバにコンテンツのキャッシュが有った場合、キャッシュを削除しません。

設定例:

 

 

Bypass Cacheの使用例を、同一URL且つログイン/未ログインでコンテンツ内容が変わるWebサイトを例に説明します。

通常、この例のようにログインユーザ固有の情報が出力されるコンテンツはキャッシュが出来ません。

何故なら、ログインユーザ固有の情報がキャッシュされ、他のユーザに見えてしまう可能性が有るからです。

 

このような通常キャッシュできないと想定されるコンテンツも、条件とBypass Cacheを組み合わせて使用すれば、キャッシュ出来る可能性がある為、キャッシュ効率を上げる事が出来ます。下記は設定の一例です。

 

 

以上、配信設定でキャッシュ制御する方法を解説しました。次に、オリジンサーバのレスポンスヘッダでキャッシュ制御する方法を解説します。

 

 

2-4.Honor Origin Cache Control and Expires

2-5.Honor Origin Cache Control

2-6.Honor Origin Expires

このオプションを選択すると、エッジサーバで設定したキャッシュ設定よりも、オリジンサーバで設定したキャッシュ設定を優先します。優先するヘッダにより、オプションを選択して下さい。

設定例:

オプション:

Caching Option

    Honor Origin Cache Control and Expires

       Cache ControlヘッダとExpiresヘッダの両方を優先する場合、選択して下さい。

   (オリジンサーバから両ヘッダが送信された場合、Cache Controlヘッダが優先されます。参考KB

    Honor Origin Cache Control

       Cache Controlヘッダのみ優先する場合、選択して下さい。

    Honor Origin Expires

       Expiresヘッダのみ優先する場合、選択して下さい。

 

Force Revalidation of Stale Objects

エッジサーバがオリジンサーバにStale Objectの有効性を再確認する際の挙動を設定します。 

      Serve stale if unable to validate

      コンテンツの有効性を再確認出来なかった場合、エッジサーバはStale Objectクライアントに返却します。

    Always revalidate with origin

      コンテンツの有効性を再確認出来なかった場合、エッジサーバはクライアントにエラーを返却します。

 

Default Max-age

オリジンサーバがCache ControlヘッダもしくはExpiresヘッダを返却しなかった場合のコンテンツのTTLを設定します。

 

Honor Private?

オリジンサーバからCache Control:privateが返却された場合のエッジサーバの挙動を設定します。

      Yesエッジサーバはコンテンツをエッジサーバでキャッシュしません。

      No:エッジサーバはCache Control:privateを無視します。

 

Honor Must-Revalidate?

オリジンサーバからCache Control:must-revalidateが返却された場合のエッジサーバの挙動を設定します。

 Yes:エッジサーバはStale Objectの有効性を必ず再確認します。

    有効性を再確認出来なかった場合、エッジサーバはクライアントにエラーを返却します。

    このオプションを選択し、且つオリジンサーバがCache Control:must-revalidateを返却した場合、

 「Force Revalidation of Stale Objects」の設定は無視されます。

 

 No:エッジサーバはCache Control:must-revalidateを無視します。このオプションを選択した場合、

    Stale Objectの扱いは「Force Revalidation of Stale Objects」で決定します。

 

 

3.0秒TTLについての補足

CacheオプションのMax-ageや、Honor OriginオプションのDefault Max-ageの値として、「0」を設定する事もできます。

設定例:

 

 

0秒に設定した場合、エッジサーバはリクエスト毎にオリジンサーバへコンテンツの有効性を確認します。毎回オリジンサーバへリクエストを送信する点ではNo Storeと同じですが、0秒に設定した場合はリクエストにIf-Modified-SinceヘッダやIf-None-Matchヘッダを使用する点がNo Storeと異なります。If-Modified-SinceヘッダやIf-None-Matchヘッダをヘッダを使用すると、オリジンサーバはコンテンツの更新が無かった際に304 not modifiedを返却する(HTTPボディは返却しない)為、オリジンサーバの負荷はNo Storeと比べて抑えられます。

 

尚、エッジサーバはデフォルトでIf-Modified-Sinceヘッダにてコンテンツの有効性を確認します。

ETagでも有効性を確認したい場合は、配信設定でValidate Entity Tag (ETag) Behaviorを有効にして下さい。

設定例:

 

 

4.Caching Behaviorを上書きするEdge-Controlヘッダ

以上がCaching Behaviorの解説となりますが、上記で設定したCaching Behaviorの設定を上書きするオリジンサーバから明示的に送るレスポンスヘッダ、「Edge-Controlヘッダ」を使用してキャッシュを制御する事もできます。

Edge-Controlヘッダには関しては弊社KnowledgeBaseや、Edge Server HTTP Header Handling もご参照下さい。

 

 

5.おわりに

以上がCaching Behaviorの解説となります。アカマイ上でキャッシュの識別子となるCache Keyや、ブラウザ向けのキャッシュ制御を行うBehaviorであるDownstream Cacheabilityについては別の記事で解説します。

本記事では、アカマイプロダクションネットワークに適用する前にアカマイステージングネットワークで確認するための新しいCPS (2017年11月リリース) の設定について紹介させていただきます。

 

証明書の更新やSANの追加、暗号プロファイルの変更等の際、配信設定と同じように、アカマイステージングネットワークにのみ適用することが可能です。

 

以下の手順でアカマイステージング環境へのみへ適用することができます。

 

1. 「展開前に常にステージングでテストする」の「いいえ」となっているところをクリックする

 ※「展開前に常にステージングでテストする」が既に「はい」になっている場合は、この手順は不要です。

 

2. 現れた画面で証明書のテストを「はい」に変更して、「送信」をクリックする

 

3. アカマイネットワークへの適用を実施する

 ※適用の完了までには、通常2時間程度要します。

 ※Third Partyとしてではなく、アカマイ経由でDV/OV/EV証明書をご利用の場合、発行された証明書がアカマイネットワークへ自動的に展開・適用されます。証明書発行前の変更実施を推奨いたします。

 

アカマイステージングネットワークに適用された設定/証明書をテストする際は、テストする端末にてSpoofingを行う必要があります。

その方法は、以下の記事をご参照ください。

 Staging環境での動作検証手順について

 

テストが完了し、アカマイプロダクションネットワークへ適用する際は、以下のようにアクションメニュの「ステージングの証明書をプロダクションに展開」クリックします。

適用の完了までには、通常2時間程度要します。

このアカマイステージングネットワークにのみ適用された変更は、証明書更新時における旧証明書有効期限の7日前には強制的にアカマイプロダクションネットワークに適用されますので、ご注意ください。

本記事では、新しいCPS (2017年11月リリース) にて、暗号プロファイルを変更する方法を紹介させていただきます。

 

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

 

2. SANを追加する証明書レコードのアクション(右端)の歯車マークより「展開設定の表示と編集」をクリックする

 

3. 「暗号プロファイルの選択」の右にある「編集」をクリックする

 

4. 以下のステップで暗号プロファイルを変更する

4-1. 「必要な暗号」と「優先する暗号」をそれぞれプルダウンから選択する

 ※SSLハンドシェイクを行う際、まず最初に"優先する暗号"から利用するCipherの選択を試みますが、利用できるものがなかった場合に"必要な暗号"のCipherから選択を試みます。特に要件がない場合は、"必要な暗号"と"優先する暗号"は同一にしておくことが推奨されます。

 ※最新の暗号プロファイルは、こちらの記事にてご確認ください。

4-2. 右上の「更新」をクリックし、情報を保存する

 

5. 最下部の「送信」ボタンをクリックし、新しい暗号プロファイルの適用を開始する

 ※アカマイネットワークへの展開には、通常2時間程度要します。

本記事では、新しいCPS (2017年11月リリース) にて、既存証明書へSAN (Subject Alternate Name) を追加する方法を紹介させていただきます。

 

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

 

2. SANを追加する証明書レコードのアクション(右端)の歯車マークより「証明書の表示と編集」をクリックする

 

3. 「証明書情報の入力」の「編集」をクリックする

 

4. 以下のステップでSAN情報を追加する

4-1. 「SAN (オプション)」のテキストボックスに追加したいSAN情報を入力する

4-2. 「CSRにSANを含める」にチェックが入っていることを確認する

  ※チェックが入っていない場合、チェックを入れてください。

4-3. 右上の「更新」をクリックし、情報を保存する

 

5. 最下部の「送信」ボタンをクリックし、SAN追加作業を完了する

 

この後の流れは、新規で証明書を取得する流れと同じです。

本記事では、新しいCPS201711月リリース)にてThird Party証明書を更新する方法を、紹介させていただきます。

1.
有効期限の60日前にCPSより自動的にCSRが発行され、証明書の「管理者の連絡先情報」に登録のメールアドレス宛に
CPSsf-no-reply@akamai.com)より自動メール[件名:Certificate Notification for コモンネーム: Renewal started]が送付されます

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


3. 証明書のスロット番号を確認します
 コモンネームが同名または酷似している証明書におけるミス防止のため、必ずスロット番号(slot)を基準に作業を実施ください。

方法① CPSで証明書のスロット番号(slot)を確認します

方法② nslookup / digコマンドでDNSを正引きして確認します
Windows
の場合:プログラムよりコマンドプロンプト(Command Prompt)を起動しnslookupと入力します
        nslookup (common name)

 
Macの場合:アプリケーションのユーティリティよりターミナルを起動しdigと入力します
      dig (common name)


4. 検索ボックスに3.で確認したスロット番号を入力し、「処理中」タブより該当証明書を表示させます
 ③のギアアイコンをクリックし、「証明書の表示と編集」より現在の証明書の
情報を確認します。


5. 情報の変更が必要な場合は、該当セクションの「編集」をクリックして編集画面へ移動します
 情報の変更が不要な場合は7.へ進みます

 

6. 情報の修正後、更新をクリックします

 ページ最下部の「送信」ボタンをクリックすると、変更後の情報で新たなCSRが発行されます

 

7. CSRをダウンロードする表示が出ます

 「CSRのダウンロード」をクリックするか、「完了」をクリックし下記のとおりダウンロードページへ移動します。



8. CSR をダウンロードするか、クリップボードにコピーします

 

9. 認証局に8.でダウンロードしたCSRを送付しサーバ証明書を発行します
サーバ証明書を発行の上、必要に応じて中間証明書、クロスルート証明書、ルート証明書を取得します。

10. Certificate Key Matcherで、8.でダウンロードしたCSRと9.で取得したサーバ証明書がマッチするかを確認します
 Certificate Key Matcher:https://www.sslshopper.com/certificate-key-matcher.html 

11. 発行された証明書をCertificate Decoderにかけ、正しくチェーンしているかを確認します

 Certificate Decoder: https://www.sslshopper.com/certificate-decoder.html 

サーバ証明書のIssuer(発行者)は、中間証明書のコモンネーム:コモンネーム②です。
中間証明書のIssuerは、クロスルート証明書のコモンネーム:コモンネーム③です。
クロスルート証明書のIssuerは、ルート証明書のコモンネーム:コモンネーム④です。
チェーンが正しく繋がっていない場合は、各証明書が正しいものかご確認ください。

 

12. SSL Checkerで「e(スロット番号).b.akamaiedge.net」と入力し、現行の証明書のチェーンを表示させます
 SSL Checker:https://cryptoreport.websecurity.symantec.com/checker/
11.でCertificate Decoderに表示させたサーバ証明書情報と比較し、相違がないか確認します。
 コモンネーム、SAN、会社名、部署名、住の記載を照合
※CPS内の登録情報に変更を加えCSRを再発行した場合、現行の証明書と新たに発行した証明書の内容は異なります。
11.でCertificate Decoderに表示させた信頼チェーンとSSL Checkerの信頼チェーンを比較し、相違がないか確認します。
証明書の用途や認証局が提供する信頼チェーンの変更により、署名アルゴリズムが現行の証明書から変更となる場合は、新しい証明書の署名アルゴリズムがお客様の意図・想定通りかご確認ください。


「表示されている構成」=「現在CPSにアップロードされている証明書」ですので、こちらのツールで中間証明書、クロスルート証明書、ルート証明書の展開が確認され今後も必要がある場合、同様に展開します。
誤って不要な証明書をアップロードしないようご注意ください。

(※)ルート証明書はRoot Certificateと表示されます。ルート証明書はコモンネームとIssuer(発行者)が同一ですので、他の証明書と判別できます。

 

13. 「証明書と信頼チェーンのアップロード」よりアップロード画面へ移動します

 

14. 取得したサーバ証明書を下段の枠内にコピー&ペーストします
 PEMファイルをアップロードする場合は上段の点線枠内にドラッグ&ドロップ、または参照よりアップロードします。

 

15. 取得した中間証明書/クロスルート証明書を下段の枠内にコピー&ペーストします
 PEMファイルをアップロードする場合は上段の点線枠内にドラッグ&ドロップ、または参照よりアップロードします。
 ※アップロード前に、ルート証明書へ正しくチェーンできることを必ずご確認ください。
  尚、プライベート認証局で発行した証明書をご利用の場合はルート証明書をアップロードします。

 「確認して追加」をクリックし証明書をアップロードします。

 

16. アップロードした証明書についてCPSより警告が出た場合、「処理中」タブの「To Do」が青く表示されます
 証明書の「管理者の連絡先情報」に登録のメールアドレス宛にCPSsf-no-reply@akamai.com)より自動メール
[件名:Certificate Notification for コモンネーム: Warning messages for your certificate]が送付されます。
警告はCSRと証明書の差異です。To Do」より警告内容を確認し、問題がない内容(大文字小文字の違いやスペース、カンマの有無)であれば「OK」をクリックし警告を承認します

 

17.「展開前に常にステージングでテストする」が「はい」になっている場合、証明書はステージングへのみ展開されますので、証明書をプロダクションに展開する必要があります
 「展開前に常にステージングでテストする」が「いいえ」になっている場合、18.へ進みます
 ※有効期限の7日前になっても作業が実施されない場合、自動的にプロダクションネットワークに展開されますので
ご注意ください。
 「To Do」より「この証明書の保留中の変更を確認する」をクリックし次のステップへ進みます。

 

18. ステージングに展開されている現在の「証明書情報」と「展開情報」を確認し、相違や修正点がある場合は「変更の拒否」をクリックします
 ※変更の拒否をすると発行された証明書は展開されず、再度更新プロセスが開始し新しいCSRが発行されます。

  現行の証明書の有効期限切れにご注意ください。
 「証明書情報」と「展開情報」の内容に相違や修正点が無い場合は「プロダクションに展開」をクリックします。

 

19. CPSにて証明書の展開が開始され、プロダクションへの展開が完了すると証明書の「管理者の連絡先情報」に登録のメールアドレス宛にCPSsf-no-reply@akamai.com)より自動メール[件名:Certificate Notification for コモンネーム:Successfully deployed! ]が送付されます

 更新が完了すると対象の証明書情報の表示が「処理中」タブから消え、「アクティブ」タブのプロダクションネットワーク欄に更新後の証明書有効期限が表示されます。

本記事では、新しいCPS201711月リリース)にてアカマイ経由で発行される証明書を更新する方法を、紹介させていただきます。

1.
有効期限の60日前にCPSより認証局へ証明書更新が申請され、証明書の「管理者の連絡先情報」に登録のメールアドレス宛にCPSsf-no-reply@akamai.com)より自動メール件名:Certificate Notification for コモンネーム: Renewal startedが送付されます

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

 

3. 証明書のスロット番号を確認します
 コモンネームが同名または酷似している証明書におけるミス防止のため、必ずスロット番号を基準に作業を実施ください。

方法① CPSで証明書のスロット番号(Slot)を確認します

 
方法② nslookup / digコマンドでDNSを正引きして確認します
Windows
の場合:プログラムよりコマンドプロンプト(Command Prompt)を起動しnslookupと入力します
        nslookup (common name)


Mac
の場合:アプリケーションのユーティリティよりターミナルを起動しdigと入力します
      dig (common name)


4. 検索ボックスに3.で確認したスロット番号を入力し、「処理中」タブより該当証明書を表示させます
 ③のギアアイコンをクリックし、「証明書の表示と編集」より現在の証明書の
情報を確認します。


5. 情報の変更が必要な場合は、該当セクションの「編集」をクリックして編集画面へ移動します
 情報の変更が不要な場合は7.へ進みます

 

6. 情報の修正後、更新をクリックします

 ページ最下部の「送信」ボタンをクリックすると、変更が認証局に送信され証明書の再申請ができます。


7. 認証局より、電話やメールにて認証が行われます
 証明書が発行されると認証局からメールが送付されます。
 証明書更新開始から1週間経っても認証局から上記メールが届かない場合は、下記ポストをご参照の上、認証局へご連絡ください。
 Certificate Provisioning System(CPS)での証明書管理 - 証明書申請とSymantec社への確認編
 証明書発行完了メール:2018年4月現在サンプル

① メールサンプル:Geotrust
 [送信元:sslorders@geotrust.com
 [件名:コモンネームTrue Business ID Order: XXXXXXX Complete]

② メールサンプル:Symantec
 [送信元:isporders@symantec.com
 [件名:
Your Secure Site Pro Certificate has been issued

8.
発行された証明書についてCPSより警告が出た場合、「処理中」タブの「To Do」が青く表示されます
 証明書の「管理者の連絡先情報」に登録のメールアドレス宛にCPSsf-no-reply@akamai.com)より自動メール[件名:Certificate Notification for コモンネーム: Warning messages for your certificate]が送付されます。
 警告はCSRと証明書の差異です。To Do」より警告内容を確認し、問題がない内容(大文字小文字の違いや住所の変更など)であれば「OK」をクリックし警告を承認します

 

9.「展開前に常にステージングでテストする」が「はい」になっている場合、発行された証明書はステージングへのみ展開されますので、証明書をプロダクションに展開する必要があります
 「展開前に常にステージングでテストする」が「いいえ」になっている場合、11. へ進みます
 ※有効期限の7日前になっても作業が実施されない場合、自動的にプロダクションネットワークに展開されますのでご注意ください。
 「To Do」より「この証明書の保留中の変更を確認する」をクリックし次のステップへ進みます。

 

10. ステージングに展開されている現在の「証明書情報」と「展開情報」を確認し、相違や修正点がある場合は「変更の拒否」をクリックします
 ※変更の拒否をすると発行された証明書は展開されず、再度更新プロセスが開始しますので、現行の証明書の有効期限切れにご注意ください。
 「証明書情報」と「展開情報」の内容に相違や修正点が無い場合は「プロダクションに展開」をクリックします。

 

11. 証明書の展開が開始します
   プロダクションへの展開が完了すると証明書の「管理者の連絡先情報」に登録のメールアドレス宛にCPSsf-no-reply@akamai.com)より自動メール[件名: Certificate Notification for コモンネーム: Successfully 
deployed!]が送付されます

 更新が完了すると対象の証明書情報の表示が「処理中」タブから消え、「アクティブ」タブのプロダクショネットワーク欄に更新後の証明書有効期限が表示されます。

ウェブサイトからブラウザにHTTPSのみでアクセスしてもらうよう宣言し、HTTPでアクセスされないようにする方法としてHTTP Strict Transport Security (HSTS)があります。HSTSはRFC6797にて規定されており、HTTPで起こり得るセキュリティリスクを軽減できます。HSTSはStrict-Transport-Securityヘッダにてポリシーを決定することができます。今回は、そのHSTSをアカマイで実装する方法についてご紹介します。

 

まず貴社の配信設定からEdit New Versionを行います。Property ManagerのProperty Configuration Settingsにある「Add Rule」からHTTP Strict Transport Security (HSTS)のテンプレートルールを追加します。

 

本Behaviorの項目を確認していきます。

 

Max-Age : HTTPSのみでアクセスする期間を指定します。Strict-Transport-Securityのヘッダ内の"max-age"の値となります。

Include all subdomains : サブドメインを含める場合にチェックします。Strict-Transport-Securityのヘッダ内に"includeSubDomains"が追加されます。

Preload : Preloadリスト(HSTS Preload List Submission)に登録する際に利用します。チェック した場合、Strict-Transport-Securityのヘッダ内に"preload"が追加されます。

Redirect all HTTP requests to HTTPS : チェックした場合、HTTPでリクエストがあった場合にHTTPSへリダイレクトする設定が有効になります。

 

 

これらの項目を設定すればHSTSの準備が完了となりますので、配信設定をStaging環境へ配信設定を展開します。

Staging環境でテストをすると以下のようにStrict-Transport-Securityヘッダを確認することができます。

 

再度、明示的にブラウザ上でHTTPでアクセスしようとするとブラウザ内にてHTTPSへリダイレクトされ、HTTPではアクセスできないことを確認できます。

 

Staging環境でも問題ないことを確認できれば、Production環境にも配信設定を展開をして、HSTSの設定が完了となります。

 

なお、アカマイのキャッシュ識別子であるキャッシュキーは同じパスであってもHTTPとHTTPSで異なるものとなりますので、HSTS有効化のタイミングによっては一時的にオフロード率が低下することがあります。そのため、HTTPSのアクセスが元々ある前提で、HSTSを設定することを推奨致します。アカマイのセキュア化についてはこちらのブログ(セキュア配信に向けた手順について)でご紹介しております。

 

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

本記事では、新しい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枚申請することが可能となります。

 

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