公開鍵証明書とは、公開鍵とその所有者の名前、所属、メールアドレス等の情報を組み合わせたデータに第三者である認証局が電子署名したものです。認証局はその証明書データが本人のものであることを確認し、証明書の正しさを保証します。
　認証局が電子署名をつけることを、証明書を発行すると言います。
　利用者は、証明書データを認証局に提出し、自分の証明書を取得、公開することにより、初めて、暗号メールの送受信が可能となります。
　認証局へ認証データを送ることを、証明書署名要求(Certificate Signing Request)と呼びます。
　この方式は、階層構造になるので、最上位の認証局をルート認証局と言います。
ルート認証局　−　認証局　−　ユーザ　のような、階層を持った信頼関係を構築するので、これを認証パスあるいは証明パス（Certificate Chain）といいます。
　ルート認証局は自身の私有鍵によって電子署名することによって、公開鍵証明書を作成します。このような証明書を自己署名の証明書などとも言います。
　利用者はルート認証局の証明書を絶対的に信用することにより、この信頼関係は成り立ちます。ユーザはルート認証局の証明書には慎重にならなければなりません。

　電子メールやWebブラウザなどのアプリーケーションソフトウエアでは下の図のように、証明書から公開鍵を取り出し、電子署名の検証や暗号化に使っているわけです。

　なお、公開鍵証明書はISO/IECで規定されているX.509仕様に基づいています。

　X.509 V3 拡張項目は、以下のような構造になっていて、証明書には複数の項目を入れることができます。

　拡張項目では、公開鍵の用途を規定したり、次節でのべるCRLがどこから入手できるのかなどが示されています。

　�Aと�Bに示されている日付が、CRLの有効期間を示します。�Bの示す時点で新しい、CRLが発行されます。したがって、ユーザは常に有効なCRLを入手する必要があります。
　ただし、現在、CRLの配送に関して、明確な仕様はなく、S/MIMEをサポートしたメーラの場合、ほとんどが、証明書に同封されているCRLのみをあてにしています。
　現実的な解決方法としては、ディレクトリサービスにユーザの個人情報とともに、証明書を登録しておき、CRLが発生した都度、サーバ側で、同期をとり、常に最新の証明書のステータスを保持しておくことが考えられています。
　その場合、ユーザは、署名付きのメールを受け取るごとに、署名をした人の証明書が有効であるか、ディレクトリサーバに問い合わせることになります。
　あるいは、電子署名をしたメールを送ってくる人たちの証明書の有効性を、�Bの時点で、ディレクトリサーバーに問い合わせて確認しておくになります。

S/MIMEで用いられるCRLはX.509に基づいています。