サブジェクト識別名（サブジェクトDN）は、相対識別名（RDN）の順序付けられたシーケンスであり、各RDNは、属性値アサーション（AVA）の順序付けられていないセットです。AVAは、「CN=yourname」や「O=yourorganization」のようなものです（ただし、証明書にはそのように格納されていません）。
ほとんどの場合、RDNごとにAVAは1つしかないため、奇妙な場合を除いて、これをたとえばサブジェクトDNのCN RDN（または、そうでない場合は「フィールド」と呼ぶこともできます）と呼んでもかまいません。具体的すぎる必要があります）。サブジェクトDNを読み取り可能な文字列にシリアル化するための複数の標準があります。特に、左から右または右から左、またはE=vs emailAddress=、コマまたはスラッシュの区切り文字です。最初に、ツールが文字列表現ではなくOID（オブジェクト識別子）からそれらを読み取れることを確認する必要があります。
多くの場合、シーケンスは国、組織、組織単位、一般名、およびおそらく電子メールになります（ただし、電子メールアドレスは、標準使用）。
一般に、CAは、サブジェクトDNの構造、およびサブジェクト代替名の拡張子を使用するかどうかに関して、自由に実行できます。これらのことは、各CAポリシー（非常に長い技術的および法的文書になる可能性があります）によって規制される傾向があります。このドメインにすべてに適合する1つのサイズはありません。
クライアント証明書を受け入れる前に、クライアントのポリシーに同意することを確認する必要があります。CA証明書を信頼すると、PKIモデルは、その後のきめ細かい選択を行うのが困難になるようなものになります。
信頼できるCAのリストは、プラットフォームと構成によって異なります。デフォルトでは、OSX上のJavaのトラストストアには約150のCA証明書がありますが、他のプラットフォームでは約70のCA証明書があると思います。これらの数値は大幅に異なる可能性があります。
とにかく、クライアント証明書を受け入れたい場合は、多かれ少なかれそれらがどこから来たのかを知る必要があるので、非常に多くの場合、それを信頼できるCAの小さなサブセットがあります。（ポリシードキュメントに基づいて）慎重に手動で選択した後、クライアント証明書認証のために信頼できるCAを構成することを強くお勧めします。
実際には、クライアントが証明書を任意のサーバーにランダムに送信する理由がわかりません。クライアント証明書のPKIは、閉じた管理ドメイン内、または確立されたフェデレーション内でより適切に機能する傾向があります。この場合、ユーザーとユーザーはそれらの組織に属し、どのCAを期待するかがわかります。さらに、LDAPサーバーなど、他の場所からさらに属性をフェッチしながら、ユーザーを認証するためのクライアント証明書の使用を制限することをお勧めします。通常、クライアント証明書は1年以上個人に発行されますが、個人に関する情報（組織単位でさえ）は実際には変更される場合があります。CAを使用する場合、またはCAを独自に設定する場合は、これらすべてを考慮する必要があります。