TLS には、サーバーが証明書を使用してクライアントを認証する機能が含まれています。これは、対称認証またはクライアント認証と呼ばれます。対称認証は、ユーザーへの個人証明書の発行が複雑であるため、パブリック HTTPS Web サイトで使用されることはほとんどなく、組織内のさまざまな TLS アプリケーションで使用される方が一般的です。
サーバー証明書はサーバー ホスト マシンを識別するものと想定されるのに対し (通常はドメイン名で識別)、クライアント証明書が識別する対象は PKIX で指定されていません。この対象には以下が含まれます。
CICS Web インターフェイス、DCAS、ELF (DCAS および TN3270 マクロを使用してユーザーを自動的にサインインさせる TN3270 高速ログイン機能) などの機能で対称認証を使用する場合、対称認証の使用を拡大することを検討できます。たとえば、クライアント証明書をユーザーに発行している場合は、ユーザーが他の TLS 対応リスナーでもクライアント証明書を要求するように設定することで、それらのリスナーに攻撃者が接続するのを難しくすることができます。
サーバーまたはクライアントの証明書を構成するときは、エンティティ証明書 (サーバーまたはクライアントを識別する証明書) だけでなく、全体の証明書チェーンを指定することが推奨されます。チェーンには、エンティティ証明書、その署名に使用された証明書、その証明書の署名に使用された証明書のように、一連の証明書が含まれます。
CA のベスト プラクティスは、ルート証明書ではなく中間証明書でエンティティ証明書に署名することです。CA には、複数の中間体に加え、複数レベルの中間体 (ルートで署名された中間体で署名された別の中間体をエンティティ証明書の署名に使用) がある場合があります。これにはいくつかの理由がありますが、ほとんどは CA のセキュリティに関するもので、CA が侵害された場合の影響を軽減するための措置です。
クライアントが常にすべての中間体を利用できるとは限らないため (ルートのみをトラスト アンカーとして使用している場合など)、適用規格では、少なくともエンティティ証明書とルートに到達するために必要な中間体を含むチェーンをサーバーから送信するように求めています。
ルート自体の送信は任意です。PKIX および CA/BF 基本要件では、トラスト アンカー (ルートを含む) の配信に信頼できる帯域外メカニズムを使用するように PKIX で規定されていることを除き、この点には言及していません。ただし、これは、サーバーがルートを送信してはならないという意味ではありません。RFC 6066 (TLS 拡張) および RFC 8446 (TLSv1.3) では、どちらにもチェーンにルートを含めなくてもよいと記載されています。認識されていないルートをクライアントで自動的に信頼してはなりませんが、ユーザーに要求することは可能であり、サーバーのチェーンにルートがあると問題の判別に役立つことがあります。ルートを含めると、TLS ハンドシェイクのサイズが大きくなるため (証明書のネットワーク上でのサイズは数キロバイト)、パフォーマンスがわずかに低下します。
Enterprise Server では、必要なすべての証明書を単一のファイルに含めてから、それを証明書ファイルとして構成することにより、リスナーから単一の証明書ではなくチェーンを送信できます。PEM および PKCS#12 (または PFX) ファイル形式では、複数の証明書を保持できます。PEM の場合は、証明書ファイルを 1 つのファイルに単純に連結します。PKCS#12 の場合は、OpenSSL ユーティリティなどのツールを使用して複数の証明書を含むファイルを作成できます。