SSLは公開鍵証明書に基づく認証を提供する。認証に使用する署名アルゴリズムの選択肢は以下のとおりである。
SSLの各バージョンで使用できる署名アルゴリズム （× = 未対応、○ = 選択可能、◎ = 実装必須）アルゴリズムSSL 2.0SSL 3.0TLS 1.0TLS 1.1
RSA○○○◎
DSA×○◎○
SSLでは通常、サーバだけが証明書を提示し、クライアントがその正当性を確認する。クライアント認証はオプションとなっており、必要な場合にはサーバがクライアントに対して証明書の提示を求める。
なりすましを防ぐために、証明書には認証局 (CA; Certification Authority) による電子署名が必要となる。またサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。この確認を行わない場合、攻撃者はサーバAの管理者でなくても、自分が管理するサーバBの正当な証明書を取得して、その証明書を使ってサーバAを名乗ることができてしまう。
証明書に関する問題は、#証明書の正当性の節を参照せよ。
なお証明書には有効期限が設定されている。暗号理論およびコンピュータの計算能力は日々進歩しており、現在安全とみなされる技術であっても長年にわたって安全性を保てる保証はない。また暗号技術の制約上、莫大な計算能力をつぎ込んで解読を続ければ、いつか暗号は解読されると考えるべきである。このため、一定期間ごとに証明書を再発行し、鍵を変更するとともに必要に応じて使用するアルゴリズムも更新している。
SSLの各レコードには、データのハッシュ値が付加されている。改竄されたデータはハッシュ値と一致しなくなるため、受信者は改竄を検出できる。各レコードにはシーケンス番号が振られており、このシーケンス番号も含めてハッシュ値が算出されているため、一部のレコードを重複して送りつける形のリプレイ攻撃も検出できる。また、（アプリケーション層プロトコルによる代替手段がない限り）通信の終了を知らせるレコードを送り合うことになっており、これが送られないうちに接続が切断された場合は、強制切断攻撃による介入を受けたと判断することができる。
ハッシュ関数の選択肢は以下のとおりである。
SSLの各バージョンで使用できるハッシュ関数 （× = 未対応、○ = 選択可能、◎ = 実装必須）アルゴリズムSSL 2.0SSL 3.0TLS 1.0TLS 1.1
MD5○○○○
SHA-1×○◎◎
SSLは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。
既存のアプリケーション層プロトコルでSSLを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにSSLのネゴシエーションを開始し、SSL接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でSSLへの切り替えを指示する方式である。
前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、既存のポート番号とは別にSSL対応用のポート番号が必要となる。実態としては、SSLの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。
前者の方式のもうひとつの問題点として、名前ベースのバーチャルホストを提供できないという点がある。なぜなら、証明書の検証はSSLネゴシエーションの一部として実施されるが、この時点ではアプリケーション層の通信が開始されていないためサーバはホスト名を知らず、証明書を使い分けることができないためである。
例外として、発行先ホスト名にワイルドカードを含めた1種類の証明書で対応できる場合は、証明書を使い分ける必要がないので、名前ベースのバーチャルホストを提供できる。またIPアドレスベースのバーチャルホストであれば、SSLネゴシエーションの時点でIPアドレスは既知なので、問題はない。
SSLを導入さえすればセキュリティーが確保できるという認識は誤っている。SSL通信は、平文での通信に比べて余分な計算機能力を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、SSLが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。Mozilla Firefoxにおける南京錠アイコンの例
特にWorld Wide Webでは、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信でSSLが使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに南京錠の絵を表示したり、アドレスバーの色を変化させたりして、利用者に情報を提供している。
また実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため、SSLを使用していても、システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある。このような場合もダイアログメッセージなどを使って利用者に警告すべきである。
SSLは公開鍵証明書を用いて認証を行い、なりすましを極力排除しようとする。しかしシステムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではない。
電子証明書には認証局による電子署名が与えられる。その署名の正当性を評価するためには認証局の証明書が必要であり、最終的にはルート証明書と呼ばれる一群の証明書に行きつく。各システムは、認証局の証明書として信用できるルート証明書を、あらかじめ保持している。認証局は自身の秘密鍵を厳重に秘匿し、また証明書の発行にあたっては正当なサーバ管理者かどうか確認することが求められる。これらが保証されない認証局のルート証明書を組み込むことは、SSLにおける認証機能を破綻させることになる。仮に認証局自体は安全でも、入手したルート証明書が本当に意図する認証局のものかどうか判断することは難しいという点も注意すべきである。
SSLで認証を行うためには、認証局の署名に加えて、証明書の発行先を確認する必要がある。確認しない場合、サーバAの管理権限を持たない者がサーバBとして正当な証明書を取得し、その証明書を使ってサーバAを名乗ることができてしまう。SSL用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。
現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。ある著名なセキュリティ研究者はこのような証明書を、オレオレ詐欺をもじって「オレオレ証明書」と呼んで批判している[6]。
この検証は、システムに指示された接続先のホスト名と実際に接続した先のホスト名が一致することを検証しているのであり、利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある。
例として、利用者が意図する接続先であるサーバAがホスト名www.example.comでサービスを提供しており、攻撃者はサーバBおよびホスト名www.example.orgを取得している場合を考える。仮に攻撃者がDNS偽装に成功して、www.example.comへの接続をサーバBに導くことができたとしても、www.example.comのサーバ証明書を入手できないので、SSL接続を提供することはできない。しかし攻撃者も、www.example.orgのサーバ証明書を入手することはできる。したがって、サーバAに接続しようとしている利用者を、www.example.comではなくwww.example.orgへ接続させることができれば、クライアントからは正当な証明書を持ったサーバとしか見えない。
上記のような例も考慮した上で、利用者が意図している接続先かどうかを判断するためには、以下の2つの条件を満たす必要がある。
利用者は意図する接続先の正しいホスト名を知っている。
