サーバー証明書やクライアント証明書を利用することで、認証を実施することができますが、実際どのように認証を実施するかをこの記事で説明します。認証のための証明書の検証にはアプリケーションによりいくつかの方法がありますが、一般的と思われる検証方法を説明します。
証明書の検証には、はじめに認証対象の証明書（エンドエンティティ証明書）を確認し、その中の一項目である「Issuer」に記載された発行者の証明書を確認します。主な確認内容は次のとおりです。
- エンドエンティティ証明書の「サブジェクト」のDN(Distinguished Name)を確認する。サーバー証明書の場合、CNがドメイン名に一致するかを確認する。
- 有効期限が切れていないかことを確認する。
- 証明書の鍵の用途を確認する。
- 証明書のExtentions領域内に記載されている証明書の鍵の用途が、実際の使用用途と一致しているかを確認する。
- CRLやOCSPを使って、証明書が失効していないことを確認する。
確認した証明書が信頼する証明書でなければ、更にその発行者の証明書を確認します。この操作をルート証明書か、信頼する証明書にたどり着くまで繰り返します。エンドエンティティ証明書から信頼する証明書まで、証明書チェーンに沿って各証明書の内容を確認していきます。主な確認内容は次の通りです。
- 証明書のチェーンが成立していることを確認する。具体的には、 証明書に埋め込まれた公開鍵を使って一つ下の階層の証明書のディジタル署名を復号化したデータが、一つ下の階層の証明書の「Certificate Signature Algorithm」と「Certificate Signature Value」をのぞいた部分のハッシュ値と一致することを確認します。
- 有効期限が切れていないことを確認する。
- CRLやOCSPを使って、証明書が失効していないことを確認する 。
証明書の信頼性について
証明書は認証機能を実現するために使用されますが、証明書の検証は、証明書に記載されている組織名と実在する組織との対応が十分確認されていることを保証するものではないという問題があります。
例えば、サブジェクトの組織(O)にA社と記載されていたとして、本当にその証明書がA社に対して発行されたものであるかどうか（そもそもA社が本当に実在するかどうか等）は、SSLにおける証明書検証では確認されません。その確認は、当該証明書の発行者である認証局をクライアントが信じるかどうかによります。
デジサート（旧 ベリサイン）※では認証のレベルによって証明書にClass 1、2、3を用意しており、数字が大きいほど入念な確認を実施しています。言い換えると、数字が小さいほど確認が簡素です。例えば、Class 1では、発行対象の認証として主に発行対象者名と電子メールアドレスによる確認しか実施していません。
※ベリサインが展開していたSSL/TLS証明書事業はシマンテックに買収され、さらにそのシマンテックの同事業はデジサート(DigiCert)が2017年10月に買収しています。
このように、認証局や証明書の種類によって確認の内容や細かさが異なり、利用者は一概にその証明書を信頼しても良いのか判断しずらい面があります。認証局の確認内容が簡易である場合、悪意のある（身元が定かではない）サーバー管理者が簡単にサーバー証明書を取得し、SSL通信を利用することで利用者を安心させ、重要な情報を入力させるといった問題（フィッシングサイト等）も起こることがあります。