SSL（Secure Sockets Layer）とTLS（Transport Layer Security）は、インターネット通信、特にWebブラウジングのセキュリティを確保するためのシステムです。具体的には、暗号化によって機密性（プライバシー）と認証（認可）を実現します。
SSLには3つの主要なバージョンがあり、4番目のバージョンはTLSバージョン1に名称が変更されました。SSLとTLSは、公開鍵暗号化と復号、シンプルな識別情報、そして信頼関係に基づいています。これら3つの要素を組み合わせることで、SSL/TLSは幅広いインターネット通信の保護に適しています。
フィッシング詐欺や個人情報の盗難についてご心配な方（そして、誰もがある程度はそうあるべきです）にとって、この記事はオンライン犯罪者から身を守るための重要な対策の一つを理解するのに役立つでしょう。ウェブサイト管理者の方にとって、SSL/TLSと証明書の取り扱いに関する情報は、プライバシーとセキュリティの確保だけでなく、独自のデジタル証明書を購入することが適切か、あるいは購入する価値があるかを判断する上でも役立つでしょう。証明書とは、本質的に、サイトが正当であり、正当な組織の管理下にあることを信頼できる機関が電子的に保証するものです。
SSL/TLS接続を確立するには、一方または両方の通信相手が証明書を持っている必要があります。証明書には、有効期間の開始日と終了日、認証されたエンティティの名称、そして有効性を証明するデジタル「署名」が含まれています。この識別機能に加えて、証明書は暗号化に使用される「秘密鍵」とも結び付けられています（下記参照）。HTTPS通信（暗号化されたWebブラウジング。URLが「https」で始まることで示される）では、サーバーが常に証明書を提供します。クライアントも証明書を提供する場合がありますが、クライアント証明書はまだ一般的ではありません。
公開鍵暗号：概要— 通常の（対称）暗号化は、鍵（パスワード）を用いてテキストを数学的に意味不明な文字列に変換することで機能します。このプロセスを逆順に処理し、元のテキストを復元するには、同じパスワードを使用する必要があります。しかし、対称暗号化では、通信相手がパスワードと暗号化/復号化アルゴリズムの両方を知り、パスワードを他の人に知られないようにする必要があります。これは明らかに拡張性に欠けます。通信相手となるすべての個人や組織を訪問し、新しい秘密のパスワードを作成し、その相手とのみ通信を行うのは不可能です。
この方法で、銀行、オンラインベンダー、コミュニティサイトごとに固有の秘密のパスワードを設定し、追跡することは非常に困難です。
一方、公開鍵暗号（「秘密鍵暗号」とも呼ばれる）では、「秘密鍵」と「公開鍵」と呼ばれる鍵のペアを使用し、それぞれの鍵は互いに反転することができます。つまり、公開鍵で暗号化されたデータは対応する秘密鍵でのみ復号化でき、秘密鍵で暗号化されたデータは対応する公開鍵でのみ復号化できます。これは対称鍵暗号に精通している人にとっては奇妙な概念ですが、ペア鍵はプライバシーと識別に関するいくつかの問題を解決するため、非常に有用であることが証明されています。
秘密鍵を所有することで、本人確認を「証明」できます。原則として、秘密鍵の作成者のみがその秘密鍵で暗号化および復号化できます（秘密鍵は共有されることはありません）。非常に単純化した例として、シティバンクの顧客が自分の秘密鍵を使って口座番号を暗号化し、www.citibank.com に送信するとします。シティバンクがその顧客の公開鍵をファイルに保存し、口座にリンクさせていれば、復号化に成功すれば、暗号化された口座番号を送信した人物が本人であることを強く保証できます。秘密鍵は、紙にインクで署名するよりもはるかに盗難や偽造が困難です。さらに、デジタル署名はインターネット上で瞬時に機能します。
デジタル署名には、非常に珍しい特性が一つあります。秘密は頻繁に使用すると漏洩してしまう傾向がありますが、デジタル署名（そして一般的に秘密鍵）は使用されるにつれて価値が高まり、信頼性が高まります。公開鍵の用語では、これを「信頼」と呼びます。秘密鍵は、ある秘密鍵が実際に特定の人物に対応しているかどうか誰も知らないため、最初は信頼がありません。そして、信頼は様々な方法で獲得することができます。
- 盲信:「私の個人用ウェブメール サーバーに侵入しようとする人は誰もいないでしょう。」
- 保証：私があなたの鍵を保証すれば、人々は私かあなたを信頼して、他の人の鍵を識別できるでしょう（この「信頼の網」がPGPの基盤です）。通常、人々は鍵全体ではなく「指紋」と呼ばれる鍵を交換します。これは、公開鍵が長い数字であり、正確に書き写すのが難しいためです。一方、指紋は短く使いやすく、対応する鍵を効果的に識別できます。
- 帯域外検証: 銀行は、ATM カードや小切手に公開鍵の指紋を載せたり、指紋の記録を読み取るだけの 800 番電話番号を提供したりすることができます。
- 経験: 銀行の Web サイトを通じて送金を正常に実行できた場合、その経験によってその Web サイトに対する信頼が高まります。
- 個人認証：あなたが直接鍵の指紋を見せてくれた場合、私はその鍵に大きな信頼を置くことができます。このような鍵交換のたびに、交換される鍵に価値が付加されます。個人認証は、帯域外認証の特殊なケースです。主に電子的なコミュニティでは、人々がお互いを一目見ただけでは認識できないこともあり、認証は困難になることがあります。
実際には、口座番号を送信することは暗号化の適切な使い方とは言えません。なぜなら、攻撃者が暗号化された「暗号文」（傍受される可能性があると想定する必要があります。通信を盗聴できないと分かっていれば、暗号化は必要ありません！）と暗号化されていない「平文」の両方を知っていれば、両者の相関関係を見つけて暗号を解読できる可能性があるからです。実際の暗号化では、「既知平文」攻撃から身を守るために、多くの乱数と使い捨ての鍵が使用される傾向があります。
残念ながら、秘密鍵/公開鍵の暗号化と復号化の実際のプロセスは遅く、公開鍵暗号化の非対称アルゴリズムを支える特殊な数学のため、従来の単一鍵アルゴリズムよりも計算がはるかに困難です。ほとんどの公開鍵暗号化システム（SSL/TLSを含む）は、実際には交換されるデータを対称暗号化で暗号化しており、これは高速で効率的です。非対称暗号化は、有効期間の短い対称鍵の交換用に予約されています。おまけに、この組み合わせにより、単一の鍵で暗号化された大量のデータが分析対象とならず、暗号解読が困難になります。対称鍵は短期間のみ使用され、その後破棄されますが、非対称鍵は
ユーザーデータではなく、対称鍵の交換にのみ使用されます。
理想的かつ単純化された例を想像してください。
- Citibank と私はそれぞれ独自の秘密鍵/公開鍵のペアを作成し、お互いに使用したり、他の人と通信したりすることができます。
- 新しい銀行口座を開設し、シティバンクと公開鍵を交換します（手書きの署名に加えて、あるいは署名の代わりに）。なお、私たちは秘密鍵を他人に渡すことはありません。秘密鍵を持つことは、限定的な委任状とみなされる可能性があります。
- Web ブラウザで www.citibank.com にアクセスします。
- Citibank の Web サーバーは、0 から 2^1024-1 (「1024 ビットの数値」) までの非常に大きな数値をランダムに生成します。これを「randomServerKey」と呼びます。
- Citibank は randomServerKey を私の公開鍵で暗号化し、ブラウザに送信します。
- ブラウザは私の秘密鍵を使用して randomServerKey を復号化します。
- ブラウザは別の 1024 ビットの乱数を生成し、それを Citibank の公開鍵で暗号化して、Citibank に送信します (これを「randomClientKey」と呼びます)。
- これで、Citibank の Web サーバーと私のブラウザーの両方が 2 つの秘密の番号を知っていることになります (他の誰も、たとえ通信を盗聴していたとしても、秘密を解読して発見するための秘密鍵を持っていないため、この番号を知ることはできません)。そこで、randomServerKey と randomClientKey と追加のランダム データを組み合わせて、短期間のみ有効な「sessionKey」を作成できます。
- どちらかが相手に情報（URL、口座番号、金額、Web ページ全体など）を送信するたびに、送信前に AES-128（128 ビット ブロックの Advanced Encryption Standard）などの対称暗号化を使用して sessionKey で暗号化します。受信者は sessionKey で AES-128 を使用して復号化します。
- 私のブラウザとシティバンクのウェブサーバーは、2分ごとに鍵交換手順を自動的に繰り返し、新しいセッション鍵を生成します。これにより、暗号解読者が1つのセッション鍵から大量の暗号化データを解析する必要がなくなり、大量の暗号文を解析する復号攻撃に対抗できます。
使用後にセッション キーを破棄し、すべての通信に同じ秘密キーを再利用することで、任意の数の異なる Web サイトで同じ手順を安全に使用できることを覚えておくことが重要です。
前述の通り、これはオンライン銀行口座開設の仕組みを理想的に表現した例です。銀行と顧客は、新規口座開設時に実際に公開鍵を交換するのではなく、パスワードや、場合によってはスクラッチ式のパスワードシートや「ハードトークン」と呼ばれる物理的なパスワード生成器（SecurIDキーフォブなどがその例です）といった他の方法に頼っています。将来的には、口座開設時に公開鍵を交換することで、強力な暗号認証と安全な通信が実現する可能性があります。銀行は現在、相互にこうした取り組みを行っていますが、一般的には顧客に対しては行いません。
公開鍵と秘密鍵のペアは、どのようにして私を特定するのでしょうか？誰でも鍵のセットを生成し、望むようなアイデンティティを主張することができます。証明書はこの疑問に答える一つの方法です。証明書は、1) 識別情報、2) 公開鍵、3) 外部保証という3つの要素を組み合わせています。これらの要素を組み合わせることで、鍵が現実世界でどのように役立つのかを見てみましょう。
誰を信頼しますか？公開鍵は実際には大きな数字に過ぎないことを念頭に置いて、公開鍵を人間や企業とどのように結び付けることができるでしょうか？証明書を作成し、それがローマ教皇の所有物だと主張することは可能ですが、そのためには何らかのクロスチェックが必要です。SSL/TLSは、信頼できる証明機関を通してこの処理を行います。信頼できる機関が特定の証明書を保証すれば、信頼できます。すべてのWebブラウザには、信頼できる「ルート」SSL/TLS証明書のバンドルが付属しており、これらのルート証明書によって署名されたすべての証明書は、ブラウザによって信頼されます。
さらに、これらの証明書を所有する組織（「証明機関」または「CA」と呼ばれる）は、他の企業に信頼を委任し、「中間」証明書に署名させる場合があります。これらの証明書は、さらに別の証明書への署名を委任されます。この信頼の階層構造は「証明書チェーン」と呼ばれます。ブラウザが信頼するCAによって（直接的または間接的に）認証されたWebサイトのみにアクセスする限り、この点について心配する必要はありません。しかし、その枠を越えようとすると、状況はより複雑になります。
もちろん、CAは信頼を確立する唯一の方法ではありません。特に、PGP/GPG（Pretty Good Privacy/GNU Privacy Guard、公開鍵暗号の一般的なツール）は「信頼の輪」という概念を採用しており、商業的な権威ではなく、人々が互いの公開鍵に署名することで成り立っています。
サーファーのためのSSL — 現実世界では、SSL/TLSが使用される理由は2つあります。プライバシーとアイデンティティの確保です。第一に、SSL/TLSは犯罪者による電子通信の傍受、特にメール、PayPal、銀行口座などへのアクセスを可能にするパスワードの窃取を防ぐのに役立ちます。第二に、SSL/TLS証明書は、ブラウザのロックアイコンでブランド化されたWebサイトが正当で信頼できるものであることをかなり確実に保証します。
ウェブサイトで機密情報を入力する際は、クレジットカード番号、電話番号、自宅住所、あるいは匿名のはずの愚痴など、URLに「https」が含まれているか確認し、証明書の有効期限切れ、誤った名前、あるいは信頼できない証明書に関する警告を真剣に受け止めてください。ブラウザでサイトに関する警告が表示された場合は、その内容をよく読み、別のサイトに移動すべきか、それとも注意深く確認しながらサイトを進むべきかを判断してください。
残念ながら、SSL/TLSで保護されたWebサイトを攻撃する方法は、実際に暗号化を解読するよりも簡単です。例えば、正規の人気サイトと紛らわしい名前（外国語のアルファベットを使うと、見た目では正規の名前と区別がつかない場合もあります）を持つ新しいサイトを作成したり、Webページに鍵アイコンを表示したりすることです。ブラウザはHTML表示領域の外側に鍵アイコンを表示することになっているため、ページのHTML領域内に鍵アイコンが表示されるのは、ブラウザが実際に信頼できるサイトであることを保証しているのではなく、そのサイトを信頼させようとする誰かによるデザイン要素です。人々は鍵アイコンの位置が間違っていることに気づかず、盲目的にサイトを信頼してしまうことがあります。そして、その後すぐに不満を抱くことになることがよくあります。
Web サイトの SSL/TLS 証明書の詳細を表示するには、Web ブラウザでそのサイトにアクセスし (SSL/TLS Web サイトの URL は “https://” で始まります)、ロック アイコンをクリックします (Safari では右上隅、Firefox と Internet Explorer では右下隅に表示されます)。たとえば、Apple の https://store.apple.com/ 証明書は “VeriSign Trust Network” によって発行され “VeriSign, Inc.” によって署名されています。この VeriSign 証明書は、VeriSign の “Class 3 Public Primary Certification Authority” によって署名されています。“Class 3” ルート証明書は、現在使用されているほとんどのブラウザで信頼されています。Mac OS X では、この証明書はキーチェーン アクセスの “X509Anchors” キーチェーンで確認できます (SSL/TLS 証明書は
X.509 デジタル証明書標準に基づいています)。Firefox は Apple キーチェーンを使用しないため、X.509 ルート証明書のバンドルをアプリケーション パッケージに保存します。 Class 3 証明書が組み込まれているため、Safari および Firefox のユーザーには、https://store.apple.com/ など、Class 3 証明書によって承認された SSL/TLS サイトを使用するときに、恐ろしい警告ではなくロック アイコンが表示されます。
SSL/TLS はウェブサイトのセキュリティ保護に限定されません。メール通信でもセキュリティを確保するために暗号化を使用することができ、SSL/TLS はこれを実現するより簡単な方法の一つです。しかし残念ながら、SSL/TLS のサポート状況は国によって大きく異なり、サーバ間の SMTP 接続が暗号化されることはほとんどありません。一方、Apple Mail、Apple の .Mac メールサービス、Mac OS X Server はすべてセキュア IMAP で SSL/TLS をサポートしていますが、残念ながら .Mac はウェブメールでは SSL/TLS をサポートしていません。メールアカウントでメールのチェックに SSL/TLS を使用するように設定するには、「環境設定」を開き、「アカウント」をクリックして目的のアカウントを選択し、「詳細」タブをクリックして「SSL を使用」にチェックを入れます。メールサーバが専用の IMAP/SSL または POP/SSL ポート（Mac.com など）で動作している場合は、適切なポート番号
（IMAP/SSL の場合は 993、POP/SSL の場合は 995）を入力します。メール送信を暗号化するには、「アカウント情報」タブをクリックし、「送信メールサーバ（SMTP）」の下にある「サーバ設定」ボタンをクリックし、「Secure Sockets Layer（SSL）を使用」にチェックを入れます。 SMTP に特別なポートが必要な場合、おそらく 587 です (これは Mac.com で機能します)。
サイトの証明書を取得する— 安全なWebサイトを構築するには、まず公開鍵と秘密鍵のペアを作成する必要があります。秘密鍵は秘密に保ち、決して他人と共有しないでください。次に、公開鍵とサイトのドメイン名や所有者などの識別情報を組み合わせて、「証明書署名要求」（CSR）を作成します。CSR自体は暗号化には使用できませんが、CSRに署名するプロセスによってX.509証明書が作成されます。この証明書は、サイトとその信頼性の主張（署名）を識別し、サイトの公開鍵と秘密鍵（通常は別のファイルに保存されます）を結び付けます。
CA（通常は民間のセキュリティ会社）がCSRを受け取ると、そのCSRを審査し、リクエストが適切かどうかを判断します。フォーマットは適切ですか？リクエストを送信した顧客は、そのドメイン名のリクエストを行う権限を持ち、財務状況が良好ですか？リクエストがCAのチェック（組織によって大きく異なります）をすべて通過した場合、CAは発行日や有効期限（古い証明書が長期間使用されないようにし、CAが支払いを受け続けることを保証する）などの追加情報を組み込み、CSRデータ、CAデータ、顧客が提供した公開鍵のすべてに署名して証明書を作成します。そして、リクエスト送信者が使用する特定のソフトウェア向けにフォーマットされた証明書を顧客に返送します。Mac
OS X Serverのコンポーネント（具体的には、付属のApache Webサーバ、CyrusおよびPostfixメールサーバ、Jabberチャットサーバ）はすべて同じ証明書フォーマットを使用しており、証明書を共有できます。もちろん、証明書は特定の公開鍵に基づいているため、対応する秘密鍵（CSRで作成される）がなければ役に立ちません。
CAは証明書所有者の身元を保証するため、証明書リクエストの詳細について厳しい審査を受ける傾向があります。氏名のスペルミスは証明書の発行を遅らせる可能性があり、異なる会社名で証明書をリクエストする場合はさらに面倒な場合があります。
人々はWebサイトの識別と機密性保護のために署名付き証明書を信頼しているため、SSL/TLS鍵（秘密鍵）は秘密かつ安全に保管する必要があります。鍵が破壊された場合、最悪の場合でも数百ドルの損失を被り、新しいCSR、秘密鍵、証明書を処理している間、オフラインになる可能性があります。最悪の場合、悪意のある人物（クラッカー、FBI捜査官、またはあなたの元恋人）がSSL/TLS証明書と秘密鍵のコピーを入手した場合、本物のサイトになりすましたり、そのサイトに送信された安全とされるすべての通信を解読したりすることが可能になります。これはフィッシング詐欺師にとってはまさに夢のような状況です。このような機密データの保護方法を規定した米国連邦規格（FIPS 140）があり、
改ざん防止ハードウェアとマルチパーティ認証について規定されていますが、ほとんどの人は、再起動後にSSL/TLSサービスを開始するために入力する必要があるパスワードで秘密鍵を保護するか、暗号化されていない鍵を含むコンピュータを保護するだけで秘密鍵を保護しています。これにより、再起動後のコンピュータは、人間の介入なしにSSL/TLSサービス（HTTPS Webサイトを含む）の提供を再開できます。これは、SSL/TLS を初めて導入するときに考慮することが重要であり、証明機関の場合はさらに重要です。
秘密鍵の盗難は非常に複雑になります。車や家の鍵を紛失したら面倒ですが、鍵の交換は簡単です。SSL/TLS の場合、これに相当するのは証明書の失効です。鍵ペアが侵害されたことを識別し、他の人に使用しないよう通知します。残念ながら、失効はいくつかの理由から非常に難しい問題です。まず、失効は証明書の署名と同じくらい慎重に管理する必要があります。競合他社が Amazon の SSL/TLS 証明書を失効できるとしたら、それは容認できません。さらに、秘密鍵は厳しく制限されているため、鍵の唯一のコピーを含むコンピュータが盗難に遭ったらどうなるでしょうか？最後に、SSL/TLS の設計では適時性について何ら想定も要求もしていませんが、証明書が
侵害された場合、誰かが盗まれた証明書と鍵を使って不正行為を行う前に失効が行われるべきです。結果として、失効システムは数多く存在するものの、ほとんど使われていません。
証明機関について— 証明機関は、各リクエストが証明書に記載されている当事者からのものであること、その組織がドメインの正当な所有権を有していること、そしてリクエスト元がリクエストを行う権限を有していることを検証する責任を負います。検証に必要な事項や検証方法は、証明機関によって大きく異なります。
CAは数多く存在しますが、新しいCAとの連携は、より確立された認証局を利用する場合と比べて問題が多くあります。ここで言う「より確立された」とは、より多くのブラウザにバンドルされていることを意味します。ブラウザが未知の証明書を持つサイトに接続すると、セキュリティが保証されないという、意図的に恐ろしい警告が表示されるからです。しかし、ウェブサイトを初めて訪れたユーザーにとって、特にオンライン販売を行っている場合は、このような警告を目にしたくありません。これは、自己署名証明書、大学や企業などのプライベートCAが社内用に署名した証明書、そしてユーザーのブラウザにまだバンドルされていない新興の商用CAが署名した証明書にも同様に当てはまります。
MicrosoftはInternet Explorer 7で、「高保証」SSL/TLS証明書に「Extended Validation（EV）」を導入しました。EV証明書のCSRとウェブサイトすべてに追加のチェックを義務付けることで、CAとCAポリシーのやや混沌とした範囲に一貫性を持たせようとしています。MozillaはFirefoxがEV証明書をサポートすると発表しており、Safariもサポートする見込みです。これらの証明書は当然ながら高価です。EV証明書は特にCAにとって歓迎すべきものであり、競争の激化により下落傾向にあった証明書価格を再び引き上げる機会となるからです。
価格は認証局によって大きく異なります。VeriSign は最大手かつ最も高額な認証局の 1 つで、1 年間有効な 128 ビット証明書の料金は 1,000 ドル、EV 付きでは 1,500 ドルです。Thawte が VeriSign の価格を下回り、市場シェアを脅かしたため、VeriSign は Thawte を買収し、より安価な証明書のブランドを維持しました。Thawte は 1 年間有効な 128 ビット証明書を 700 ドルまたは 900 ドル (EV 付きまたはなし) で請求しますが、Thawte 証明書のインストール手順は、中間証明書もインストールする必要があるため複雑です。これは、
より安価な Thawte 証明書が VeriSign ブランドの証明書ほど機能的にならないよう VeriSign が阻止しようとしているように見えます。最近、GeoTrust が 1 年間有効な 128 ビット証明書を 180 ドルで提供し、VeriSign の人気と価格を脅かしたとき、VeriSign は同じことを繰り返して GeoTrust を買収し、VeriSign EV 証明書を大幅に下回る価格設定を阻止しました。ただし、RapidSSL など、62 ドルしかかからないより安価なオプションも存在します。
証明書は非常に高価なため、CAは有効期間の長い証明書や複数購入に対して様々な割引を提供しており、更新費用は通常、新規証明書よりも安価です。ほとんどのCAは、証明書の有効期限が切れる前に更新するようユーザーに通知する（そして更新費用を支払う）ことに熱心に取り組んでいますが、未使用期間を更新済みの証明書に繰り越すことにも積極的に取り組んでいるため、早期更新によるペナルティはありません。更新が遅れると、Webサイトの訪問者に期限切れの証明書を信頼するかどうかを尋ねられるため、非常に恥ずかしい思いをする可能性があります。証明書の有効期限をカレンダーに記録しておくことで、こうした問題を回避できます。
すべてのCAは、信頼できる証明書を発行するためにCSRに署名するという基本的なサービスを提供していますが、CAの評判、認証プロセスの複雑さ、証明書のインストールと使用の容易さ、認証サイトへのアクセスにおけるユーザーの利便性、CAのポリシーなど、様々な要素が存在します。多くのCAは、価格を正当化するために、VeriSignのSecured Sealプログラムのように、認証する証明書（および関連するWebサイト）の整合性を保証するサービスを提供しています。
どのような種類の証明書を使用すべきでしょうか？ 公開されている電子商取引サイトや、その他の機密性の高い情報を扱うサイトでは、128ビットの商用証明書を使用する必要があります。どの証明書を購入すべきかはサイトによって異なりますが、主な差別化要因は訪問者の信頼性（EV証明書、確立されたルートキーなど）と管理者の使いやすさにあります。一方、実際の署名プロセスはすべてのCAで暗号学的に同等です。秘密鍵と公開鍵は自分で用意することを忘れないでください。認証局は証明書の所有者を保証しますが、暗号化レベルには関与しません。すべての128ビットSSL/TLS証明書は暗号学的に
同等ですが、ブラウザによってEVサイトの扱いが異なります。
商用 CA の代替手段— 証明書の署名に年間最大 1,500 ドルを CA に支払う代わりに、他の方法があります。まず、新しい CSR を作成し、それを使用して自身に署名します。このような「自己署名証明書」は、第三者による真正性の保証はありませんが、適切な署名を持つ「本物の」証明書と全く同じ暗号化を提供します。ホスト名が 1 つまたは 2 つ（証明書はホスト名に紐付けられているため）の場合や、消費者の信頼が重要でないサイトでは、自己署名証明書の使用が適しています。数百ドルの費用が無駄になる可能性のある個人サイトに最適です。訪問者に SSL/TLS アクセスを提供していないサイトでも、管理アクセス（
ブログの更新、オンライン統計の確認など）のセキュリティ保護には、自己署名証明書が最適です。
大学や企業のようにサイトが多数ある場合は、独自の CA を作成し、それを使用して個々の証明書に署名することで、CA の費用を一切回避する方が合理的です。欠点は、サイトの訪問者がブラウザーから表示される正当なセキュリティ警告に対処し、プライベート CA 証明書を手動で信頼する必要があることです。プライベート CA の対処手順はブラウザーによって異なります。また、犯罪者が他のユーザーと同様に簡単に CA を偽装できるため、一部のブラウザーでは、新しいプライベート CA を信頼することを意図的に困難にしています。ただし、ユーザーは一度 CA を信頼すれば、信頼できない証明書の警告に再び対処する必要はありません (コンピューターやブラウザーを変更する場合を除きます。その場合は、このプロセス
を繰り返す必要があります)。
この方法を選択する場合は、まずルート証明書の鍵の電子的および物理的なセキュリティ、特にバックアップやスタッフの離職について真剣に検討する必要があります。幸いなことに、CAであることは技術的には証明書の自己署名よりもはるかに複雑ではありません。ただし、ルート証明書のインストールをユーザー側で支援することは、一部のブラウザでは自己署名証明書を単純に信頼するよりも意図的に複雑になっています。
独自のプライベートCAの構築には費用はかかりません。無料のOpenSSLですべてを実行できます。必要なのは、手順を習得するための時間と、すべての子証明書のセキュリティの要となるルート鍵を保護するためのセキュリティ対策だけです。詳細はこの記事では扱いませんが、開始するためのオンラインリソースがいくつかあり、手順を自動化して非常に効率的に合理化できます。
OpenSSLには、これらのタスクを自動化するPerlスクリプトCA.plが含まれています。これは効果的ですが、完璧ではありません。CA.plと手動の手順に満足できなかったため、新しい証明書の作成と署名を行うcert.commandと、既存の証明書に署名を行うsign.commandという2つのシンプルなスクリプトを作成しました。どちらのスクリプトでも、ホスト名を2回入力し、ルートキーのパスフレーズを入力して、Returnキーを何度も押すだけで、残りの作業は自動化されます。
結論：SSL/TLSは、インターネット上のWeb通信やメール通信を安全にする唯一の方法ではありませんが、クレジットカード番号、オンラインバンキングセッション、メールなど、何百万人もの人々のために日々、非常に重要な役割を果たしています。一般ユーザーにとって、URLに鍵アイコンと「https」が表示されることは、SSL/TLSが安全を守ってくれているという安心感につながります。管理者にとって、SSL/TLSを支える技術は確かに暗号化技術（ロケット科学のソフトウェア版）の領域に属しますが、実装にかかるコストと労力は、Webサーバーを運用できる人なら誰でも容易に実行できる範囲です。
[クリス・ペッパーはニューヨーク市在住のUnixシステム管理者です。彼は、Mac OS Xが自分が扱うUnixシステムにとってこれほど優れた管理ワークステーションになったことに、今でも感激しています。クリスの署名欄には「Webを1ページずつ編集する」と書かれています。この記事で取り上げられた問題に頭を悩ませた後、クリスはOpenSSLのCA.plスクリプト（Mac OS Xに付属）を使ってSSL/TLS証明書を管理する方法について、追加の記事を執筆しました。また、プライベートCAの運用を支援するダブルクリック可能なスクリプトも2つ開発しました。]