Let’s Encrypt、商用およびプライベート認証局、自己署名SSL証明書の比較

SSL暗号化でより多くのWebトラフィックを保護するというプッシュは、適切な証明書を取得するためのソリューションを必要とするサービスとユースケースの数が増えていることを意味します。 パブリックWebサイト、イントラネットトラフィック、またはWebアプリのステージングサーバーのいずれであっても、データを保護し、ユーザーの最新のセキュリティ期待を満たすには証明書が必要です。

SSL接続の主な利点は、privacyとdata integrityを中心に展開します。 暗号化により盗聴が防止されるため、接続はプライベートです。 データの整合性は、正しいサーバーに接続している（詐欺師ではない）ことを暗号で確認し、送信中に個々のメッセージが改ざんされていないことを確認することで保証されます。

SSL証明書を取得する方法はいくつかあり、予算、対象ユーザー、およびその他のいくつかの要因に応じて、商用認証局、新しい自動化された無料の認証局、自己署名証明書、および独自のプライベート認証局。 これらのオプションの比較を実行し、それぞれを使用するのが最適な場合について説明します。

始める前に、SSLセキュリティについて説明するときに使用する一般的な用語をいくつか定義します。

商用認証局では、DV、OV、およびEV証明書を購入できます。 特定の制限付きの無料のドメイン検証証明書を提供するものもあります（たとえば、ワイルドカードは使用できません）。

ほとんどのブラウザでは、ほとんどの商用認証局がデフォルトで信頼されています。 更新プロセスは通常手動で行われるため、証明書の有効期限を書き留め、期限内に更新するように注意する必要があります。

従来、商用CAは、ほとんどの主要なブラウザが信頼する証明書を取得するための唯一の本当の選択肢でした。 これは、Let’s Encryptのような新しい自動認証機関で変更されました。 それでも、商用CAがEV証明書を取得する唯一の方法であり、ほとんどのブラウザーで自動的に信頼されるワイルドカード証明書を取得する唯一の方法です。 自動化されたLet's Encryptクライアントを実行できないデバイスの証明書が必要な場合にも適しています（ソフトウェアの非互換性、または低電力の組み込みデバイスであるため）。

商業認証局は、多くの場合、追加のサポート契約、保証、および認証のオプションを提供します。これは、一部の企業および業界にとって重要です。

Let's Encryptは、無料のドメイン検証済み証明書をリクエストおよび更新する自動化メカニズムを提供します。 サービスと対話して証明書を自動的に取得および更新するための標準プロトコル（ACME）を作成しました。 公式のACMEクライアントはCertbotと呼ばれますが、多くの代替クライアントが存在します。

証明書の暗号化の有効期間を短くして、自動更新を促し、侵害された証明書が攻撃者に悪用される可能性を減らします。

公開されていて、それを指す有効なドメイン名を持つサーバーがある場合は、Let's Encryptが適切なオプションです。 Encryptのサーバーは、ウェブサーバーにアクセスするか、パブリックDNSレコードを取得して、ドメインを制御していることを確認する必要があります。したがって、ローカルネットワークのファイアウォールの背後にあるプライベートサーバーで使用するのは少し難しいかもしれません。 ただし、Let's EncryptのDNSベースの認証チャレンジを使用しても可能です。

Let's Encryptは、ベアIPアドレスの証明書を提供しません。

EV証明書またはワイルドカード証明書が必要な場合、Let’s Encryptは選択できません。 Let's Encryptでは最大100個のホスト名を使用して証明書を作成できるため、ユースケースに実際にワイルドカードは必要なく、既存のすべてのサブドメインをカバーする証明書が必要な場合があります。

それでも、Let’s Encrypt APIのレート制限により、多数のサブドメイン、または動的に作成できる動的サブドメインがある場合、Let’s Encryptは適切ではない可能性があります。

独自の秘密キーで署名されたSSL証明書を使用して、認証局の必要性を完全に回避することができます。 これは自己署名証明書と呼ばれ、テスト用または限られた数の技術に精通したユーザーが使用するためにWebアプリをセットアップするときに非常に一般的に推奨されます。

自己署名証明書は、OpenSSLライブラリに付属のopensslコマンドを使用して作成できます。 チュートリアルOpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRsで、必要な正確なコマンドとOpenSSLの背景を見つけることができます。

自己署名証明書は信頼できるCAによって署名されていないため、証明書を信頼できるものとして手動でマークする必要があります。このプロセスはブラウザとオペレーティングシステムごとに異なります。 その後、証明書は通常のCA署名付き証明書のように機能します。

自己署名証明書は、少数のクライアントの信頼を手動で管理する必要がある場合に1回限りの使用に適しています。手動での努力なしでは失効または更新できないという事実を気にしないでください。 多くの場合、これは開発やテストの目的、またはごく少数の人しか使用しない自己ホスト型のWebアプリには十分です。

独自のプライベート認証局を作成し、それを使用して証明書に署名することができます。 ユーザーは、証明書のいずれかが信頼される前に、プライベートCAを手動でインストールして信頼する必要があります。

自己署名証明書と同様に、OpenSSLライブラリに付属のコマンドラインツールを使用してプライベートCAを作成できますが、プロセスを簡単にするためにいくつかの代替インターフェイスが開発されています。 tinyCAはこのプロセスのグラフィカルインターフェイスであり、camanはコマンドラインプログラムです。 どちらもCAの作成を簡単にし、証明書の発行、更新、失効を容易にします。

作成する証明書が複数あり、ユーザー用にCAを手動で配布およびインストールできる場合は、プライベートCAが適切なオプションです。 これはおそらく、CAを適切にインストールできる組織または技術に精通したユーザーの小さなグループ内での内部使用に制限されます。 大規模なIT部門には、多くの場合、ユーザーにCAを自動的に展開する手段があり、このソリューションをより魅力的にしています。

各証明書を手動で信頼済みとしてマークする必要がある自己署名証明書とは異なり、プライベートCAをインストールする必要があるのは1回だけです。 そのCAから発行されたすべての証明書は、その信頼を継承します。

欠点の1つは、CAの実行に多少のオーバーヘッドがあることです。また、安全な方法で設定および保守する方法をある程度知っている必要があります。

適切な失効が使用のために重要である場合、証明書失効リスト用のHTTPサーバー、またはOCSPレスポンダーも維持する必要があります。

SSL証明書を取得または作成するためのいくつかの異なるオプションを確認しました。 状況に最も適した方法であれば、SSL保護を追加することで、サービスとユーザーのデータ、プライバシー、セキュリティを保護することができます。

SSLとこれまでに説明したオプションについてさらに詳しく知りたい場合は、次のリンクが役立ちます。