証明書およびプライベート キー

証明機関

Enterprise Server に付属の DemoCA 証明機関は、本番環境では使用しないでください。DemoCA の本番環境での使用はサポートされていません。組織または商用の CA を使用してください。

Microsoft Windows Server には、組織の CA 用に、適切な証明書を作成し、グループ ポリシーに基づいて必要なルート証明書および中間証明書を Windows クライアント システムに配布するために使用できる CA ロールが用意されています。Windows を広く使用している組織では、これを使用すれば簡単ですが、適切な証明書が作成されるように構成するためにある程度の調査が必要になります。Linux および UNIX では、さまざまなオープンソースの CA パッケージを利用できます。

証明書の検証の種類

CA から発行された証明書の場合、証明書を要求している当事者の ID を次の 3 つの方法のいずれかで検証できます。

組織検証 (OV)

OV 証明書は、組織内で発行されるため、(理論的には) 組織のチャネルを使用して要求が認証されます。OV 証明書が商用 CA から発行される場合は、身元の証明と承認を提供する要求元組織からの公式声明に基づきます。

ドメイン検証 (DV)

DV 証明書は、通常は自動化されたプロセスを通じて、特定の完全修飾ドメイン名に対して生成され、ドメイン内の特定の DNS エントリをチェックすることによって要求が検証されます。DV 証明書は、ユーザーがドメインの DNS を管理していれば、そのドメインを事実上所有することになるため、ドメイン内のシステムに対する DV 証明書を付与することが適切であるという理論に基づくものです。これは、Let's Encrypt で使用されるアプローチです。

拡張検証 (EV)

EV 証明書は、証明書要求を検証するために追加の手順が実行された証明書です。通常、これには発行元 CA のスタッフによる追加の手続きと確認が含まれます。EV 証明書は、負担が非常に大きいことから業界でも議論になっており、セキュリティ対策としての追加効果はほとんどないと話す評論家もいます。EV 証明書を提供しているサイトについて、それをユーザーに通知するブラウザーがほとんどでしたが、少なくとも Chrome ではもう中止しています。

証明書の検証の種類は、Enterprise Server のコンポーネントに対してはどれでもかまいません。EV 証明書を使用しても Enterprise Server では大きな利点はないと予想されます。

証明書のプロパティ

組織で独自の証明書を生成する場合は、その内容とオプションに応じたベスト プラクティスに従っていることを確認することが重要です。外部 CA を使用する場合も、CA に提供する証明書署名要求 (CSR) やその他の資料で、必ず適切なパラメーターを指定する必要があります。Micro Focus では、次のことをお勧めしています。

名前

サーバー証明書をはじめ、ホスト名、完全修飾ドメイン名 (FQDN)、IP アドレスなどのネットワーク名でコンピューターを識別する証明書では、それらの名前をサブジェクト代替名 (SAN) 拡張でリストする必要があります。人やアプリケーションなどの他のエンティティを識別する証明書では、サブジェクト識別名 (サブジェクト DN) と適切なコンポーネントを使用する必要があります。

コンピューターの証明書では、以前はサブジェクト DN の共通名 (CN) コンポーネントにホスト名または FQDN を含めていましたが、現在は PKIX および CA/BF 基本要件で SAN を使用するように求められており、これらに準拠する実装では、ピアから受け取る証明書の検証で CN を使用することは許可されていません。サブジェクトまたは発行者の名前に CN を使用することは CA/BF では非推奨になっています。

サーバーの証明書または CSR を生成するときは、サーバーへの接続に使用する名前ごとに SAN を指定します。つまり、通常は、サーバーの正規名の FQDN とホスト名単体の両方の形式の SAN を指定し、クライアントが使用するエイリアスがサーバーにある場合は、それらの SAN (FQDN とホスト名単体の両方の形式) も指定します。システムの IP アドレスが固定で、クライアントでホスト名を解決しなくてもそのアドレスを使用して直接接続できる場合は、そのアドレスの SAN も含めることができます。

たとえば、エンタープライズ サーバー インスタンスをドメイン corpdom.com の corpserv という名前のシステムで実行しているとします。便宜上、組織ではこのシステムに esserv というエイリアスを付けています。永続的なアドレスとして、IPv4 アドレス 10.2.5.18 と IPv6 アドレス fd0f:14d7:e62c:1234::0005:0012 が割り当てられています。このようなサーバーの場合、次のサブジェクト代替名を使用して証明書を要求できます。

• DNS:corpserv
• DNS:corpserv.corpdom.com
• DNS:esserv
• DNS:esserv.corpdom.com
• IP:10.2.5.18
• IP:fd0f:14d7:e62c:1234::0005:0012

これにより、このコンピューターを適切かつ一意に識別する証明書を作成し、クライアントが TLS を使用して接続を試行するときに使用すると考えられるすべての名前に対応できます。

注: Chrome ブラウザーなどの一部のクライアントでは、サーバー証明書を検証するときに SAN が必要になりました。

ワイルドカード

Micro Focus では、ワイルドカード証明書は Enterprise Server で使用しないことをお勧めします。そのような証明書ではプライベート キーを制御できないことに関するリスクがあるためです。

アルゴリズムおよびキーのサイズ

それぞれの証明書に署名アルゴリズムおよびパブリック キーがあります。署名アルゴリズムは最新の強力なアルゴリズムでなければなりません。たとえば、MD5 ハッシュを使用した署名アルゴリズムは、多くの実装で許可されなくなりました。キーは十分に強力でなければなりません。たとえば、現在の CA/BF の要件では、RSA キーについて 2048 ビット以上と規定されています。

有効期間

いずれの証明書にも、有効期間の開始日時と終了日時を示す 2 つのフィールドがあります。現在、CA/BF の要件では、エンティティ (サーバー、クライアント、ユーザーなど) の証明書の有効期間が合計で 398 日までに制限されています。一部のブラウザーや他のピアで、これが強制される場合があります。現時点では、Chrome は組織の CA から発行された証明書についてはこの要件を無視していますが、有効期限が 1 年強の証明書を発行し、毎年更新するようにスケジュールすることがベスト プラクティスとなります。

シリアル番号

CA が発行するすべての証明書には、一意のシリアル番号が必要です。CA/BF では、シリアル番号について、少なくとも 64 ビットにするように求めています。これが、商用 CA から発行される証明書のシリアル番号が非常に長い理由です (たとえば、www.microfocus.com の現在の証明書は 09:4a:51:9b:32:a5:b4:00:38:14:c5:ef:29:bf:8d:48 です)。最近の CA ソフトウェアであれば、この形式のシリアル番号を生成できるようになっているはずです。一部のブラウザーや他のピアで、この要件を満たすシリアル番号が要求される場合があります。

基本制約

基本制約拡張機能については、すべてのエンティティ証明書 (サーバー証明書、およびその他の CA のルート証明書と中間証明書を除く証明書) で CA フラグを false に設定します。これは標準ではオプションですが、推奨されるものです。

キー使用法と拡張キー使用法

ベスト プラクティスは、ユース ケースを可能な限り絞って証明書を発行し、そのユース ケースに合わせて各証明書を設定することです。たとえば、サーバー証明書の場合、キー使用法を「デジタル証明書」および「キーの暗号化」に設定し、拡張キー使用法を「TLS Web サーバー認証」に設定します。

CA/BF のルールでは、キー使用法はオプションであり、拡張キー使用法は必須です。

CRL 配布ポイントと機関情報アクセス

これらの拡張機能は、証明書失効情報を扱います。証明書失効に関する処理にはさまざまな問題があり、利用できるメカニズム (証明書失効リスト (CRL) およびオンライン証明書ステータス プロトコル (OCSP)) もうまく機能しないため、組織の CA の多くでは失効を実装または使用しておらず、多くのアプリケーションでは失効の確認をスキップしています。現在、Enterprise Server のコンポーネントで失効の確認を行っているものはありません。

ただし、業界において失効に役割があることに変わりはなく、CA/BF には失効に関する特定の要件があります。

CRL 配布ポイント拡張機能は、CA/BF 基本要件でオプションになっており、省略してかまいません。

機関情報アクセス拡張機能は、CA/BF 基本要件で必須になっており、OCSP レスポンダーの URL を含める必要があります。さらに、AIA 拡張機能については、証明書チェーンのルート証明書を取得するための URL を含めるように規定されています。現在、少なくとも組織の CA については、すべてのブラウザーがこの要件の違反を無視しているようですが、これは変更される可能性があります。

機関キー識別子 (AKID) とサブジェクト キー識別子 (SKID)

AKID および SKID 拡張機能は、証明書のパブリック キー (SKID) とそれに署名した証明書のパブリック キー (AKID) を一意に識別します。これにより、証明書を検証するアプリケーションでトラスト アンカー (通常はルート証明書) までの証明書チェーンを構築しやすくなります。CA/BF では AKID 拡張機能が必須とされていますが、両方を提供することをお勧めします。

証明書ポリシー拡張機能

証明書ポリシー拡張機能は CA/BF で必須とされています。現在のところ、この要件を適用しているブラウザーやその他のクライアントを Micro Focus では確認できていません。

キーの衛生状態

キーの衛生状態とは、プライベート キーが適切に使用された状態を指します。プライベート キーは、テスト目的でのみ使用される場合でも、非常に機密性の高いデータです。

次のシナリオについて考えてみます。

• TLS でのテスト用に、組織でテスト システム用のキー ペアとシステム用の証明書を作成します。
• 便宜上、組織の CA を使用して証明書を発行します。これにより、この証明書が組織内のブラウザー (適切なトラスト アンカーを持つブラウザー) で信頼されます。
• 攻撃者は内部ネットワークに侵入し、(サーバーから) 証明書を取得し、(適切に保護されていないため) プライベート キーを取得します。
• 攻撃者は偽のサーバーを用意し、DNS キャッシュ ポイズニングや別の手法を使用してトラフィックを偽のサーバーにリダイレクトします。
• その後、攻撃者はソーシャル エンジニアリングやその他の手法を使用して従業員をだまし、偽のサーバーに接続させて、資格情報などの機密データを送信させます。証明書が組織の CA によって署名されているため、ブラウザーに警告は表示されません。

現在、Enterprise Server でサポートされているのはプライベート キーをキー ファイルに格納することだけであるため、プライベート キーを保護するには、それらのファイルの内容とファイル自体を保護する必要があります。

Micro Focus では、暗号化されたキー ファイルを使用することをお勧めします。PEM、PKCS#8、PKCS#12 などのほとんどのキー ファイル形式は、キー データの暗号化をサポートしています。ファイルを暗号化すれば、攻撃者がキーのロックを解除するために必要なパスフレーズを (ブルート フォースなどで) 推測するか、別のソースから取得しなければならなくなります。これにより、攻撃者の作業が増えます。

キー ファイルに対する権限は限定して設定します。理想的には、ファイルシステムの権限に関するトピックで説明したように、Enterprise Server を専用のユーザー アカウントで実行し、そのアカウントにのみプライベート キー ファイルへの読み取りアクセスを付与します。これはキーが暗号化されていない場合に特に重要ですが、いずれの場合にも推奨される方法です。

プライベート キーへのアクセスは、業務で必要な従業員のみに制限します。Micro Focus とも共有しないでください。Micro Focus のカスタマー ケア、Professional Services、またはプリセールスから証明書のコピーを求められた場合、それについては提供して問題ありません。ただし、プライベート キーは含めないでください。Micro Focus では、プライベート キーが証明書のパブリック キーと一致することを確認するためにプライベート キーに関する情報 (RSA キーのモジュラスなど) を要求する場合がありますが、その情報も提供して問題ありません。Micro Focus がプライベート キー自体を要求することはありません。

CA のルート証明書および中間証明書に対応するプライベート キーは、特に機密性が高くなります。業界のベスト プラクティスとして、CA のルートのプライベート キーはリムーバブル メディア以外には格納しないでください。リムーバブル メディアまたはハードウェア セキュリティ モジュール (HSM) にのみ格納し、新しいルート証明書または中間証明書を生成する場合にのみ接続します。

キーの管理とパスフレーズの提供

プライベート キーが侵害された場合、そのキー ペアを使用するすべての証明書を直ちに取り消す必要があります。新しいキー ペアを生成し、証明書を再発行して交換してください。

特定のキー ペアを複数の証明書に使用できます。管理するキーのセットが多くなるか、キーが侵害された場合に取り消して再発行する必要がある証明書が多くなるか、それぞれの判断でどちらかを選択します。

前のセクションで示したように、Micro Focus ではキー ファイル内のキーを暗号化することを推奨しています。キーを暗号化することの欠点は、プロセスで最初にキーを使用するときに、キーのロックを解除するためのパスフレーズを提供する必要があることです。Enterprise Server の場合、通常はリージョンの起動時に提供することになります。MFDS、ESCWA、およびその他のケースについては、以下で説明します。

キーのパスフレーズを提供する方法はいくつかあります。

• エンタープライズ サーバー リージョンの起動後に手動で入力します。TLS 対応リスナーを起動するように求められた場合、キー ファイルのパスフレーズが他の方法で提供されていないと、リスナーは「start pending」状態になります。その後、ESCWA および MFDS でリンクされた Web フォームを使用してパスフレーズを入力すると起動を完了できます。これにより、格納されたパスフレーズが攻撃者に特定されることを回避できます。ただし、サーバーの起動時にこの手動の手順が必要になることに注意してください。
• mf-server.dat ファイルに含めます。この場合、mf-server.dat に対して制限付きのファイル権限を設定することが重要です。リリース 8.0 以降では、mf-server.dat ファイルを使用して、Enterprise Server コンテナー機能で格納されたパスフレーズを指定することもできます。
• ESCERTPAS ユーザー出口を使用してパスフレーズを提供します。ESCERTPAS は、CICS Web インターフェイスおよび CICS Web サービスの機能のパスフレーズを提供するためのものと説明されていますが、Enterprise Server の通常のリスナーにも使用できます。ESCERTPAS の利点は、パスフレーズを取得するための操作を原則として出口ですべて実行できることです。サンプルの終了プログラムではパスフレーズがそのままハードコーディングされていますが、実装ではより安全なメカニズムを使用してパスフレーズを取得できます。

Enterprise Server の今後のリリースでは、パスフレーズやキーの記憶域オプションの追加サポートを予定しています。たとえば、Enterprise Server のコンテナー機能、Windows の証明書とキー ストア、OpenSSL PKCS#11 インターフェイスを使用した HSM の使用などが追加される可能性があります。

MFDS および ESCWA の場合、キーのパスフレーズは構成で指定するか、コンテナー機能で管理します。

MFCC を使用するクライアントの場合、キーのパスフレーズをプログラムで提供できますが、このオプションをサポートするクライアントはほとんどありません。代わりに、直接またはコンテナーを使用して mf-client.dat ファイルでキーを指定できます。

Fileshare や Mainframe Access クライアントなど、CCI を直接使用するクライアントとサーバーでは、CCI の machinename 文字列の一部としてパスフレーズを提供できます。

詳細については、製品ヘルプを参照してください。