Let's Encryptの無料SSL以外のSSL証明書を使用する理由はありますか？
Let's Encrypt は無料のSSL証明書を提供しています。他の有料の証明書と比較して、マイナス面はありますか。 AWS Certificate Manager ？
証明書の寿命
安全保障
寿命が短いほど良いです。失効はほとんど理論的なものであるため、実際にはそれを信頼することはできません（パブリックPKIエコシステムの大きな弱点）。
管理
自動化なし：寿命が長いほど便利です。何らかの理由で証明書管理を自動化できない場合、LEは実現できない可能性があります
自動化の場合：寿命は重要ではありません。
エンドユーザーの印象
エンドユーザーは、何らかの方法で考えを持っている可能性は低いです。
検証のレベル
安全保障
Letsencryptは、DVレベルの検証のみを提供します。
証明書を購入すると、支払ったものを何でも入手できます（LEと同じレベルのアサーションで、DVから開始）。
DV =ドメイン名制御のみが検証されます。
OV =所有者エンティティ（組織）情報がさらに検証されます。
EV = OVのより完全なバージョン。これは伝統的に「緑のバー」で授与されていました（しかし「緑のバー」は間もなく廃止されるようです）。
管理
LEを使用する場合、実行する作業は必要な自動化をセットアップすることです（このコンテキストでは、ドメイン制御を証明するため）。作業量は環境によって異なります。
証明書を購入する場合、DV/OV/EVレベルは、証明書を取得するために必要な手動作業の量を定義します。 DVの場合、通常は、何かを支払い、コピー/貼り付けするか、何かをクリックするウィザードを通過します。OVとEVの場合、IDを確認するための追加の手順を実行するために個別に連絡する必要があることにかなりの信頼を置くことができます。
エンドユーザーの印象
エンドユーザーは、証明書の内容を実際に見ない傾向があることを除いて、おそらく現在のEVの「グリーンバー」（廃止予定）を認識しています。
ただし、理論的には、制御エンティティに関する情報が記載された証明書の方が明らかに役立ちます。しかし、ブラウザ（または他のクライアントアプリケーション）は、一般的なユーザーに影響を与える前に、実際にこれを便利な方法で表示する必要があります。
Installation
安全保障
秘密鍵などを公開する方法で、物事を誤って行う可能性があります。 LEを使用すると、提供されるツールは合理的な慣行に基づいて設定されます。
彼らが何をしているかを知っている人と一緒に、手動のステップも明らかに安全に行うことができます。
管理
LEはすべてのプロセスを自動化することを非常に意図しており、そのサービスは完全にAPIベースであり、短い寿命はすべてが自動化を中心とする方法を反映しています。
証明書を購入する場合、APIを通常の顧客に提供するCA（現時点では実際にはそうではありません）であっても、DV以外のものを適切に自動化することは困難であり、DVを使用すると、LEが提供するものと本質的に同じものに料金を支払うことになります。
OVレベルまたはEVレベルの場合は、プロセスを部分的にしか自動化できない可能性があります。
エンドユーザーの印象
インストールが正しく行われた場合、エンドユーザーは明らかにそれがどのように行われたかを知りません。自動化されたプロセスを使用すると、混乱を招く可能性が低くなります（たとえば、更新を忘れたり、更新時にインストールが正しく行われなかったり）。
全体
OV/EV証明書が必要な場合、証明書管理を自動化していない場合、またはHTTPS以外のコンテキストで証明書を使用したい場合は、証明書を購入する従来の方法が特に便利です。
純粋に技術的な観点から：
- 証明書が3か月間のみ有効であること。変更管理手順とインフラストラクチャによっては、メンテナンスが面倒な場合があります。
- Let's Encrypt証明書の目的は限られています。メール、コード署名、タイムスタンプには使用できません。
確認する：openssl x509 -in cert.pem -noout -textX509v3拡張キーの使用法：
TLS Webサーバー認証、TLS Webクライアント認証
エンドユーザーの観点から：
- Extended Validation がないことは、特定のWebブラウザーに「緑色のバーがない」ことを意味します。
- ただし、 2018年9月にChromeは緑色のバーが段階的に廃止されます 小さな鍵のアイコンが優先され、最終的に特別なインジケーターはなくなり、代わりに安全でないページの警告のみが表示されます。
ここで、Let's Encryptに対して使用された引数にいくつかの対抗ポイントを提供したいと思います。
短い寿命
はい、よくある質問で説明されているように、有効期間は短いです： https://letsencrypt.org/2015/11/09/why-90-days.html ページを引用するには：
これらは、鍵の侵害および誤発行による損傷を制限します。盗まれた鍵と誤って発行された証明書は、より短い期間有効です。
これらは自動化を促進しますが、これは使いやすさにとって絶対に不可欠です。 Web全体をHTTPSに移行する場合、システム管理者が手動で更新を処理することは期待できません。発行と更新が自動化されると、有効期間が短くても、有効期間が長くなるほど便利ではありません。
EVの欠如
EVサポートの予定はありません。推論（ https://community.letsencrypt.org/t/plans-for-extended-validation/409 から）は次のとおりです。
EVプロセスは常に人間の努力を要し、誰かに支払う必要があるため、Let’s EncryptがEVをサポートしないことを期待しています。私たちのモデルは無料で証明書を発行することです。これにはEVと互換性がないように見えるレベルの自動化が必要です。
さらに、このブログポスト（ https://stripe.ian.sh/ ）のように、EVが有害であると信じている人もいます。
たとえば、ジェームズバートンは最近、彼の会社「ID確認済み」のEV証明書を取得しました。残念ながら、ユーザーはこれらのエンティティのニュアンスに対処するための準備が整っていないだけであり、これはフィッシングの重要なベクトルを作成します。
この典型的な実例はsslstripです。正当に購入された証明書を持つホモグラフサイトは、EVが現在十分な防御を提供していない現実の攻撃です。
検討する価値のある欠点の2つのグループがあります。
1。Let's Encryptサービスを使用することの欠点
Let's Encryptでは、正確な名前、またはワイルドカードを要求する場合は（サブ）ドメインがパブリックインターネットDNSに存在する必要があります。 example.comに対する制御を証明したとしても、Let's Encryptはsome.other.name.in.example.comの証明書を公開DNSで確認せずに発行しません。名前が付けられたマシンは、パブリックアドレスレコードを持っている必要はありません。ファイアウォールで保護されていたり、物理的に切断されていたりする可能性がありますが、パブリックDNS名が存在する必要があります。
暗号化しましょう90日間の証明書の有効期間は、誰もそのための時間がないため、自動化する必要があることを意味します。これは実際、サービスの目的です。多くのより困難なタスクを自動化している間に手動で行うのではなく、この重要な作業を自動化することを目指しています。ただし、何らかの理由で自動化できない場合はマイナスです。ツール、アプライアンス、または自動化をブロックするものがある場合は、商用SSL証明書のコストを、それらのツール/アプライアンス/コスト計画の進行中のコストの一部として考慮してください。これを自動化する新しいツール/アプライアンス/ etceteraの価格設定で商用証明書を購入する必要がないことから節約を相殺します（Let's Encryptを使用するかどうかにかかわらず）
Let's Encryptの制御自動化の証明は、組織の規則に適合しない場合があります。たとえば、Apacheの再構成は許可されているが、会社のドメイン名のSSL証明書を取得すべきではない従業員がいる場合、Let's Encryptはあまり適していません。この場合、それらを使用しないのはWrong Thing（TM）であることに注意してください。CAAを使用して、ドメインのLet's Encryptを明示的に無効にする必要があります。
Let's Encryptのポリシーで拒否された場合、唯一の「控訴裁判所」は、パブリックフォーラムで質問し、スタッフの1人が先に進む道を提供できることを願っています。たとえば、サイトにDNS名があり、システムが大手銀行やGoogleなどの特定の有名な物件と「紛らわしいほど類似している」と判断した場合に、これが発生する可能性があります。賢明な理由から、この点に関する各パブリックCAの正確なポリシーは公開されていないので、要求して「ポリシー禁止...」という応答を受け取ったときにLet's Encrypt証明書を取得できないことに気付くだけです。
2。Let's Encrypt証明書自体の欠点
Let's Encrypt証明書は、現在ISRG（Let's Encryptサービスを提供する慈善団体）を通じて主要なWebブラウザーによって信頼されていますが、古いシステムは、IdenTrustを介してLet's Encryptを信頼しています。これでほとんどの人に仕事ができますが、世界で最も広く信頼されているルートではありません。たとえば、放棄されたニンテンドーWiiUコンソールにはWebブラウザーがあり、明らかにニンテンドーはWiiUのアップデートを出荷しないため、ブラウザーは放棄され、Let's Encryptを信頼しません。
Let's EncryptはWeb PKIの証明書のみを発行します-SSL/TLSプロトコルを使用するインターネット名を持つサーバー。つまり、これは明らかにWebであり、IMAP、SMTP、いくつかの種類のVPNサーバー、何十ものものですが、すべてではありません。特に、Let's Encryptは、S/MIME（送信中のメールだけでなく、保存されている電子メールを暗号化する方法）や、コード署名やドキュメント署名に証明書を提供していません。証明書の「ワンストップショップ」が必要な場合、これはLet's Encryptを使用しない十分な理由かもしれません。
Web PKIでも、Let's Encryptは「DV」証明書のみを提供します。つまり、FQDN以外の自分または組織に関する詳細は証明書に記載されていません。 CSRに書き込んでも、破棄されるだけです。これは、一部の専門アプリケーションのブロッカーになる可能性があります。
Let's Encryptの自動化とは、他に何も持てない理由がなくても、自動化が許可するものによって厳密に制約されていることを意味します。新しいタイプの公開鍵、新しいX.509拡張機能、その他の追加機能は、独自のタイムラインでLet's Encryptによって明示的に有効にする必要があります。もちろん、寄付は歓迎されますが、必要な機能を得るために追加料金を支払うことはできません。
それにもかかわらず、ほとんどすべての人にとって、ほとんど常に、Let's Encryptは、TLSサーバーに証明書を置くのに最適な最初の選択肢です。 Let's Encryptを使用するという想定から始めて、この決定に取り組むための賢明な方法です
web以外の証明書が必要でない限り、realの欠点はありませんが、確かにperceivedもの。問題は認識されているだけですが、Webサイトの所有者は、対処する以外に選択肢がない場合があります（ビジネス上の関心が中指の表示を禁止している場合）。
単一の最大の欠点は、当面、サイトがやや劣る、おそらく危険と表示されることです。他のいくつかのサイトが持っていること。そのバッジはどういう意味ですか？何も、本当に。しかし、それはあなたのサイトが「安全」であるsuggestを行います（一部のブラウザはその正確なWordさえ使用します）。悲しいかな、ユーザーは人々であり、人々は愚かです。ブラウザが安全だと言っていないからといって、どちらか一方がサイトを信頼できないものと見なします（影響を理解せずに）。
これらの顧客/訪問者を無視することが有効な可能性であれば、問題ありません。ビジネス的にそれを行う余裕がない場合、あなたはお金を使う必要があります。他のオプションはありません。
もう1つの認識されている問題は、証明書の有効期間に関する問題です。しかし、それは実際には利点であり、欠点ではありません。有効期間が短いほど、サーバー側とクライアント側の両方で、証明書をより頻繁に更新する必要があります。
サーバー側に関しては、これはcronジョブで発生するため、実際には少ない手間と通常よりも信頼性が高い。忘れられない方法、遅れる方法、誤って何かをする方法、管理者アカウントでログインする必要はありません（... 2回以上）。クライアント側ではどうでしょう。ブラウザーは常に証明書を更新します。大したことではありません。ユーザーはそれが起こることすら知らない。 2年ごとではなく3か月ごとに更新すると、トラフィックが少し増えますが、真剣に...それは問題ではありません。
雇用主にLets Encryptから一部離れることを強制したもの、APIレート制限を追加します。ライフタイムが短く、ワイルドカードがサポートされていないため、通常の自動操作（自動更新など）中にレート制限に近づくことは非常に簡単です。新しいサブドメインを追加しようとすると、レート制限を超えてしまう可能性があります。LEには、一度ヒットした制限を手動で上書きする方法がありません。古い証明書をバックアップしない場合（LEが想定しているような自動化されたクラウドタイプのマイクロサービス環境では誰がバックアップするのでしょうか）、LEは証明書を再発行しないため、影響を受けるすべてのサイトがオフラインになります。
私たちが何が起こったのかを理解したとき、「ああ$＃！＃」の瞬間があり、その後に生産サイトをオンラインに戻すために緊急の商業証明書の要求がありました。より合理的な1年の寿命を持つもの。 LEが適切なワイルドカードサポートを実装するまでは（そしてそれでも）、その提供には非常に注意が必要です。
Tl; dr：LEワイルドカード+ APIの制限により、「個人のホームページ」よりも複雑なものを管理することが予期せず困難になり、途中でセキュリティの実践が不十分になっています。