PAやPrisma Accessで使う証明書の種類とその設定場所

はじめに

弊社の次世代ファイアウォール製品(PA-Series) やPrisma Accessを管理・設定していると、証明書を要求される場面がたくさんあります。ただ、ひとくちに「証明書」といっても、その種類はさまざま。どの種類の証明書をどこに設定するの? と悩むことも多いのではないでしょうか。

そこで今月は、PAやPrisma Accessと関連する証明書の設定を少し深掘りして紹介します。

PAやPrisma Accessで「証明書」を使う場面はおおよそ以下の5つです。

1. 外部ダイナミックリスト(EDL)の証明書プロファイル (Certificate Profile)に使う
2. SSL/TLS サービスのプロファイルに使う
3. クライアント認証の証明書プロファイルに使う
4. マシン認証の証明書プロファイルに使う
5. SSL/TLS通信の復号に使う

以降、「証明書」と「SSL/TLS」の暗号技術についてざっと紹介してから、PAやPrisma Accessでは上記5つの場面でどの種類の証明書を使うのかを解説します。

1. SSL/TLS暗号と公開鍵証明書

皆さんは「証明書」と聞いて何を思い浮かべるでしょうか。たとえば運転免許証など、偽造しにくい模様が入った特殊な紙に、「鈴木花子さんが普通乗用車を運転できることを証明します」などという文言が印刷されて、公安委員会など公的機関が発行している物理的な証明書を思い浮かべる方が多いかもしれません。

電子の世界であるインターネットの場合、その黎明期には平文での通信が一般的でした。しかしインターネットの私的・商業的利用が認められ、そうしたかたちでの利用が盛んになってくると、通信内容の秘匿や相手がたしかに本人であることの確認、通信内容の改ざん防止が重要になってきました。

そんななか、1994年に当時Webブラウザーで大きなシェアをもっていたNetscape Communicationsが、SSL (Secure Sockets Layer) という通信プロトコルを開発し、同社のWebブラウザー、Netscape Navigatorに実装しました。このプロトコルは通信内容の秘匿や本人性確認、通信内容の改ざん防止を行い、「無料」で誰もが利用できるオープンなプロトコルとして広く普及しました。

SSL/TLSで使われる暗号化方式は、PKI (公開鍵基盤 Public Key Infrastructure)をベースにしています。PKIは「対称暗号方式(暗号鍵と復号鍵が同一)」と「非対称暗号方式(暗号化鍵と復号鍵が異なる)」とを組み合わせることで両暗号方式の短所を補いあって暗号強度と暗号化速度を両立しています。

この両暗号方式の短所とは何でしょうか。

「対称暗号」は、暗号化と復号に使う鍵が「共通」です。ここから「共通鍵暗号」と呼ばれることもあります。たとえばパスワードを設定した暗号化ZIPファイルはこの方式を使っていて、暗号化と解凍のパスワードが同じです。

暗号化の鍵は、対象暗号でも非対称暗号でも、第三者には絶対に秘密にする必要があります。なぜなら鍵さえ手に入れば、ZIPファイルを手に入れた第三者でも復号できるからです。鍵を通信者間でやりとりすることを「鍵交換」と呼びますが、対称暗号は非対称暗号とくらべ、この鍵交換を安全に行いにくくなっています。なぜなら、なんらかの方法で共通鍵を相手に渡す必要があるからです。ですが、暗号化の実行速度は非対称暗号のそれよりも速いという長所もあります。

「非対称暗号」は、暗号化用の鍵と復号用の鍵が別々です。公開する鍵と手元だけにおく秘密鍵を1組のペアとして使うことから、「公開鍵暗号」とも呼ばれます。この鍵のペアは数学的な「計算の複雑さ」に基づいて生成します。鍵ペアのうち、公開鍵の方は誰に見られてもよく、秘密鍵は交換せずに手元で秘密にしておきます。秘密鍵は相手に渡す必要がないことから、共通鍵とくらべ、鍵を安全に保管できます。しかしながら暗号化の速度が対称暗号と比べて遅いという短所があります。

PKIにもとづくSSL/TLSは、この対称鍵暗号と非対称鍵暗号の「いいとこ取り」をしています。SSL/TLSは、通信開始時に対称暗号用の共通鍵を動的に生成し、この共通鍵を公開鍵と秘密鍵の鍵ペアを使う非対称暗号で安全に交換します。交換後は処理速度に優れる対称暗号方式を使い、交換した共通鍵で通信内容を暗号化します。

ただし、コンピューターの演算能力は日々向上していて、「計算の複雑さ」に依存する暗号の強度は時とともに下がります。また、暗号化のしくみ自体に脆弱性が見つかることや、新たな攻撃手法が考案されて「危殆化する(compromised)」(安全性が保証できなくなる)こともあります。SSL/TLSはその後のバージョン更新で危殆化への対策をしており、本稿執筆現在はSSL3.0をベースにIETFが作成した「TLS」とよばれる暗号方式の利用(バージョン 1.3)が主流になっています(そのため、本稿では「SSL/TLS」とまとめて呼んでいます)。

ではこの非対称暗号(公開鍵暗号)で作成した「公開鍵」が、たしかに意図した通信相手のものであることを私たちはどうやって確認すればよいのでしょうか。攻撃者があなたの通信相手になりすまして「これが私の公開鍵です」と騙そうとしてきたらそれを防ぐ手立てはあるのでしょうか。

それをしてくれるのが「公開鍵証明書」 (単に「証明書」と呼ばれる)です。

たとえば、物理的な運転免許証で「公安委員会」が「この普通自動車免許証は鈴木花子さんのものです」と「署名」することで証明してくれるように、インターネットでは日々、認証局が「署名」した「(公開鍵)証明書」が、通信内容の秘匿や本人性の確認、通信内容の改ざん防止に使われています。そして運転免許証でいう「公安委員会」にあたる第三者機関が「認証局 (Certificate Authority: CAと呼ばれることが多い)」と呼ばれる機関です。

2. 証明書の種類と署名

証明書の種類をその目的別に分けると次の2種類に分かれます。

1. サーバー証明書: サーバーの認証に用いる証明書。接続先となるサーバーが証明書に記載されている特定のドメインであることを保証する
2. クライアント証明書: クライアントの認証に用いる証明書。接続元のクライアントがサーバーへの接続を許可された正規の利用者であることを保証する

なお、認証局(CA)は階層構造をとっているので、証明書の種類は階層別に3種類に分けることもできます。

1. ルート証明書: 階層構造の最上位の証明書。CAが自分自身に対して発行する
2. 中間証明書: 階層構造の最上位・最下位以外の証明書。「ルート証明書」を持つCAが別のCAに対して発行する
3. エンドエンティティ証明書: 階層構造の最下位の証明書。サーバー証明書やクライアント証明書はここに含まれる

「なぜ認証局が階層構造になっているのか」についてはこちらのブログが非常にわかりやすいので興味があれば参考にしてください。

たとえば www.paloaltonetworks.com で Web サービスを提供している Web サーバーが、本当にパロアルトネットワークスが管理しているサーバーであることを知りたいとします。これはこの Web サーバーが提示するサーバー証明書(=エンドエンティティ証明書)を見ることで確認できます。Webブラウザーのアドレス欄で鍵のアイコンをクリックしてみてください。

Safariで確認する場合はアドレス欄のFQDN (paloaltonetworks.comと表示されている)のすぐ左に鍵のアイコンがありますのでこのアイコンをクリックします。

Webブラウザー上に「www.paloaltonetworks.comへの接続は暗号化されています。」というダイアログが表示されますので [証明書を表示]を押してみます。

すると、次のように階層化された証明書が表示されます。なお、表示される内容は使っているWebブラウザーの種類やアクセスした時期、OSなどで異なるので、図とまったく同じにはなりません。

ここでは「*.paloaltonetworks.com」の名前を持つサーバー証明書(エンドエンティティ証明書)が、1つ上の階層にある「DigiCert TLS RSA SHA256 2020 CA1」という中間証明書の署名により、「この Web サーバーは名乗っている通りの正当なドメインのものです」と保証してもらっています。そしてこの「DigiCert TLS RSA SHA256 2020 CA1」もその上位にあるルート証明書の「DigiCert Global Root CA」の署名により、名乗っている通りの正当なエンティティであることを保証してもらっています。このWebブラウザーはあらかじめルート証明書の「DigiCert Global Root CA」を内部に保持して(=信頼して)いるので、この信頼の連鎖によって全体を「信頼できる通信」とみなします。

なお、これらの証明書は「何らかの」認証局によって署名されているかどうかで相手を信頼すべきかどうかを決めています。公的機関でなくてもかまいませんし、誰でも認証局を運営できます。たとえば企業がみずから認証局となって自身に「署名」すれば、組織内でも認証局を運用できます。Webブラウザーに組み込まれているルート証明書も、そのWebブラウザーが、認証局の信頼性にもとづいて恣意的に選定しています。

なお、クライアント証明書は、SSL/TLSのネゴシエーション時に、サーバー側からの要求に応じてそのクライアントが正当な利用者であることを証明するという用途で使われます。サーバー証明書の使用目的は「サーバーの正当性の証明」で、たとえばSubject名は「www.paloaltonetworks.com」のようなFQDN(完全修飾ドメイン名)です。これに対し、クライアント証明書の使用目的は、接続元のクライアント(コンピューターやユーザー)の正当性の証明で、たとえばSubject名がユーザー名やLDAPの識別名(DN)です。こうした細かな違いはありますが、証明書としての本質は、サーバー証明書もクライアント証明書も同じです。

3. PAやPrisma Accessで利用する証明書の種類

ここまで、SSL/TLS暗号、公開鍵証明書のしくみ、証明書の種類と認証局(CA)による署名の関係を順に説明してきました。ここからは、PAやPrisma Accessが使う証明書の種類やその場面について解説します。

1. 外部ダイナミックリスト (EDL: external dynamic list)の証明書プロファイルに使う

EDL (外部ダイナミックリスト)とは、弊社が維持管理しているSoftware-as-a-Service (SaaS)アプリケーション エンドポイントのリストです。各SaaSアプリケーション プロバイダーは、それぞれに自社のエンドポイントについてのフィードURLを公開していますので、弊社はその公開フィードURLに新たなエンドポイントが追加されたかどうかを毎日チェックして外部ダイナミックリスト (EDL) に反映しています。

このEDLで使う証明書プロファイルにはCAが発行するルート証明書を使います。このルート証明書により、EDLの配布元HTTPSサーバーのサーバー証明書が信頼されたCAによって発行されているかどうかを確認しています。

このEDLや後で説明するクライアント証明書認証で使う証明書プロファイルには、CAのルート証明書をインポートします。なお、ルート証明書では鍵が提供されないので鍵はインポートしません。

2. SSL/TLSサービスのプロファイルに使う

PAやPrisma Accessでは、Web (HTTPS)サービスを提供してクライアントからの接続を待ち受けることがあります。たとえば、認証ポータル(Authentication Portal)やキャプティブポータル(Captive Portal)、GlobalProtectポータルなどがそうしたサービスの例です。

これらのWebサービスでは「SSL/TLSサービスプロファイル」を使います。SSL/TLSサービスプロファイルとは、サーバー証明書と、許可したいプロトコルやそのバージョンの情報を設定を組み合わせて保存した内容を指しています。

SSL/TLS サービスプロファイルを設定するには、サーバー証明書と秘密鍵を、PEM形式またはPKCS12形式で用意してインポートします。

3. クライアント認証の証明書プロファイルに使う

GlobalProtectポータルやゲートウェイなどには、許可したクライアント(=コンピューターやユーザー)だけをアクセスさせることができます。この機能を利用する場合、クライアント証明書によるクライアント認証(Client Authentication)を行えます。

クライアント認証で指定した認証局が署名したクライアント証明書のみを使うには、証明書プロファイルにクライアント証明書の発行(署名)元として信頼する認証局のルート証明書を設定しておきます。

4. コンピューター認証の証明書プロファイルに使う

HIP(ホスト情報プロファイル)の確認や、Windows Pre-Logon (ユーザーがWindowsコンピューターにログインする「前」にコンピューター認証を行う)でクライアント証明書の1種であるコンピューター証明書による認証を行う場合は、その証明書の発行(署名)元として、信頼する認証局のルート証明書を設定しておきます。

5. SSL/TLS通信の復号に使う

SSL/TLSで行われている通信を復号する場合、オリジナルのSSL/TLSサーバー証明書のSubject情報にもとづいてSSL/TLSサーバー証明書が作成されます。このとき、その署名にはルート証明書が使われます。

この署名を行うには、「証明書」と「鍵」の両方を設定する必要があります。PEM形式の鍵と証明書(.PEM)か、PKCS12形式 (.pfx/.pkcs12)をインポートできます。

おわりに

本稿は「証明書」と「SSL/TLS」の暗号技術についてざっと紹介してから、PAやPrisma Accessでは上記5つの場面でどの種類の証明書を使うのかを解説しました。

証明書は、目的別に分けるとサーバー証明書とクライアント証明書の2種類がありました。階層別に分けると、ルート証明書、中間証明書、エンドエンティティ証明書の3種類がありました。

PAやPrisma Accessには証明書を設定する箇所が多数あって、利用する証明書の種類もさまざまですが、整理すれば上記 5 つの設定のいずれかにあたります。