SSL証明書の支払いが必要なのはなぜですか？
ほとんどの用途では、それらを支払う正当な理由はありません。
例外の概要については、一番下を参照してください。
一歩後退して、証明書の機能と大まかな方法を説明しましょう。
一般に「証明書」と呼ばれるものは、2つのリンクされた部分で構成されています。
- 証明書の 適切な公開鍵と（例えば、ドメイン名などの）いくつかの識別が含まれ、。
- 秘密鍵ホルダー（とのみ保持者）がデジタルで、彼らは上記の証明書を使用して検証することができるような方法でメッセージに署名することができます。
の証明書がyourdomain.com必要な場合：
- プライベート/パブリックキーペアを作成し、プライベート部分をプライベートのままにします。
- 掲載のための証明書を作成するために、信頼できる第三者（「CrediCorp」）を
yourdomain.com公開鍵と。
- あなたがコントロールするCrediCorpに何らかの方法で証明してください
yourdomain.com。
- 秘密鍵と取得した証明書をサーバーに配置し、それらを使用するようにWebサーバーを構成します。
次に、Aliceがにアクセスするyourdomain.comと、ブラウザはWebサーバーから証明書を取得し、秘密鍵で署名されたメッセージを受け取ります。次に、彼女のブラウザは3つのことを確認します。
- 署名されたメッセージが証明書によって検証できること（対応する秘密キーのみで署名されている
yourdomain.com必要がある場合）
- 証明書のドメインが、ブラウザーがアクセスしようとしているドメインであること（
yourdomain.com）。
- 証明書がCrediCorpからのものであること。
これら三つの組み合わせは、彼女が実際に話していることを保証アリスyourdomain.comはなく、いくつかの詐欺師に... アリスはCrediCorpを信頼していることを提供します。
（この真正性を機密性に変えるための暗号ブードゥー教のダンスもあります。）
どのようにないアリスはCrediCorpを信頼しますか？
ここが本当の核心です。要するに、ある時点でCrediCorpが「おい、証明書を作成する」と言った。多くの規則に従って多くの努力を払った後、彼らは何人かの人々にCrediCorpは確かに信頼できるものであり、証明書を正しく発行するだけだと確信させることができました。
特に、彼らはFirefoxなどのメーカーを納得させることができました。その結果、CrediCorpはFirefoxのAリストに登録され、その証明書はデフォルトでFirefoxによって信頼されています。実際、AliceはFirefoxを信頼し、FirefoxはCrediCorpを信頼し、CrediCorpはあなたがコントロールしたと主張したときに（検証後に）あなたを信頼しますyourdomain.com。それはほとんどチェーンのようなものです。
しかし、Firefoxはの証明書を発行するためにCrediCorpを信頼するだけでなくyourdomain.com、あらゆるドメインのCrediCorp証明書を信頼します。また、Firefox はどのドメインでも ShabbyCorpを信頼しています。
これには結果があります。誰かがShabbyCorpに自分が制御していると納得させた場合yourdomain.com（ShabbyCorpはあまり徹底的ではないため）、yourdomain.com対応する秘密キーを使用してShabbyCorp証明書を取得できます。そして、その証明書を使用すると、Webサーバーになりすますことができます。結局のところ、yourdomain.comFirefoxによって信頼されている証明書（およびキー）があります！
CrediCorpおよびShabbyCorpは、認証局、略してCA と呼ばれるものです。現実の世界では、ComodoSSLとLet's EncryptはCAの例です。しかし、もっとたくさんあります。この記事の執筆時点では、Firefoxは154のCAを信頼しています。
おっ しかし、それは私の質問にどのように答えますか？
私はええと、それに到達しています...
つまりね。上記で説明した仕組みは、すべての証明書に適用されます。Webサイト用の正しい信頼できる証明書があれば、それは機能します。ブランドA証明書とブランドB証明書には特別なことはありません。それらはすべて同じCA要件と同じ暗号演算の対象です。
そして、たとえあなたがCrediCorpの方が好きであっても（ご存知のように、彼らは信じられないほど聞こえるだけです）、それらを使用しても、本当に助けにはなりません。攻撃者がShabbyCorpを説得してサイトの証明書を提供できる場合、攻撃者はその証明書を使用して、どこで入手したかに関係なく、サイトになりすますことができます。
FirefoxがShabbyCorpを信頼している限り、訪問者は違いを見ることはありません。（はい、訪問者は証明書を取得し、そこを掘り下げて、だれが発行したかを確認できます。しかし、だれがそれを行いますか？）なぜそうなのか、それは恐ろしいことであり、おそらくこのスキーム全体に対する人々の最大の批判でしょう。それでも、それは我々が立ち往生しているものです。
ポイントは、CAが「良い」証明書を発行することを信頼していない場合、証明書を他の場所で取得してもあまり役に立ちません。
ガッチャ、すべてが等しく運命づけられています。警告はありませんか？
Weeeelllll ...
最後のセクションで作成したポイントを削除することから始めましょう。現在では、DNS-CAA を使用して、選択したCAのみにドメインをロックすることが可能です。あなたがComodoを信頼し、他のCAを信頼しないと仮定すると、Comodo以外のすべてのCAにドメインの証明書を発行しないよう要求することができます。理論的には。（DNS-CAAはブラウザによってチェックされず、CAの発行によってのみチェックされるため、侵害されたCAはこのセーフガードを無視できます。）
あなたがそのトラブルを喜んで経験するなら、質問は次のようになります：Let's Encryptは実際には信頼性が低いのですか？または安全性が低い？信頼性は難しいものですが、それをどのように定量化しますか？私が言えるのは、Let's Encryptが他のCAよりも信頼できるという認識です。検証のセキュリティに関しては、商用CAが行うことと非常に似ています（とにかくDV証明書の場合）。この質問も参照してください。
価値があるのは、このサイトの一部であるStackExchangeネットワークが現在Let's Encrypt証明書を使用していることです。ほとんどの人はこれに気付かないでしょう。もし気付いたなら、それが彼らにとって大きな意味があるのかどうか、私は心から疑います。
証明書を有効にするには、発行元のCA がソフトウェアベンダーによって信頼されている必要があります。そうでない場合、証明書は役に立ちません。私はFirefoxを例として使用しましたが、実際には、少なくとも最新バージョンのFirefox、Chrome、Windows、Mac OS X、iOS、AndroidでCAを信頼するようにしたいと考えています。そして、数十人の小さなプレーヤー。考慮する価値のあるCA（ComodoSSLやLet's Encryptを含む）は、これらすべてのエンティティによって信頼されています。
CAが誤動作したり、信頼できないと判明した場合、証明書所有者の日を台無しにするのに十分な速さで、さまざまなトラストストアから削除されます。私が知っている2つの注目すべき例は、DigiNotarとStartCom / WoSignです（記事をチェックしてください。信頼のダイナミクスに関する興味深い洞察を提供します！）。したがって、Let's Encryptが台無しになるか、何らかの理由でドロップされると思われる場合、それらを使用しないと、その特定のフォールアウトに巻き込まれるのを防ぐことができます。
証明書は、暗号数学の魔法を使用します。問題は、どの 暗号数学の魔法ですか？弱い魔法の場合はどうなりますか？これは実際に懸念事項であり、CAもこれをアップグレードする際に足を引っ張ることを示しています。幸いなことに、ブラウザベンダーは、証明書を受け入れるための最小値をここに設定することにより、この余裕を取り戻しました。たとえば、RSA-1024またはSHA-1を使用する証明書は現在ほとんどのブラウザで拒否されているため、実際に機能する証明書はこれらの非推奨の暗号プリミティブを使用しません。結論としては、CA（Let's Encryptを含む）がこの部分を失望させることはもう非常に困難です。
以前、私は多かれ少なかれ、すべての証明書が平等に作成されると言いました。私は嘘をついた、そうではない。特に、これまで私が議論したのは「ドメイン検証（DV）証明書」で、これは大部分のWebサイトで使用されています。これらは、ブラウザがURLバーに表示されるドメインと実際に通信しているという確実性の尺度を提供します。また、「Organization Validated（OV）」および「Extended Validation（EV）」証明書もあります。これらの証明書には、CAによるより詳細なチェックが必要です。特に、somebank.com実際にSomeBank、Inc.であることを証明できる場合にのみ、/ SomeBank Inc.のEV証明書を取得できる必要があります。
EV証明書は取得するのにはるかに費用がかかり（球場：年間数百ユーロ/米ドル）、ブラウザに緑色のURLバーまたは南京錠が表示され、「SomeBank、Inc.」と表示される場合があります。同じように。DV証明書とは異なり、彼らはWebサイトが実際に誰に属しているかもしれないかについてのいくつかのアイデアも提供します。利点は、彼らはより合法的に見えるかもしれません。残念なことに、ユーザーはめったに注意を払わないため、その有効性は限られています。
偽造されたDV証明書を持つ攻撃者は、EV証明書が提供する余分な視覚的な手がかりがなくても、サイトになりすますことができ、ユーザーは一般的に区別に気付きません。逆に、誤解を招くEV証明書を取得して、フィッシングを容易にすることもできます。その結果、ChromeとFirefoxの両方がEV証明書に視覚的なうなずきをドロップし、一部の人々は完全になくなると信じています。
あなたが銀行の場合、おそらく今のところまだEV証明書が必要です。そうでなければ、それほどではありません。ただし、EV が必要な場合は、Let's Encryptは適切ではありません。EV証明書を提供しないからです。
証明書は限られた期間のみ有効です。典型的な商用CAからの証明書は1年間有効である傾向がありますが、3か月から3年まで何でも見ました。Let's Encrypt証明書は90日間有効です。これはその範囲の短い側にあるため、頻繁に更新する必要があります。Let's Encryptユーザーの場合、これは通常、証明書が60日ごとに置き換えられるように自動化されています。
広く利用可能なソフトウェアを使用して更新を自動化できることは、証明書が期限切れになることよりも実際には快適ですか？CAでのログインは何ですか？これはどのように再び機能しますか？ほとんどの小規模サイトが商用CAで終わるように見える儀式。
以前は、私たち全員が信頼しなければならないCAが非常に多いことを怖いと言いました。ただし、トラストストアから1つのCAを削除しても、ユーザーへの影響は限られているという意味で、多くのCAを持つことは利点です。特に、単一のCAを削除しても、その1つのCAによって発行された証明書にのみ影響します。誰もが単一のCAを使用することになった場合（一部の人々はLet's Encryptで起こるかもしれないと恐れている）、そこにすべての信頼を集中し、その断片化の利点を失います。
そして最後に、商用サポートや100万ドルのSSL保証など、有料のCAが提供するその他の利点があります。私はこれらの両方の側面にほとんど信仰を持ちませんが、それらはLet's Encryptが提供しないものです。
頭が痛い...質問がありましたか？
快適に感じるものを使用してください！DV証明書の場合、実際にさまざまなCAを区別するものはほとんどありません。Let's Encryptを専門的にも個人的にも使用していますが、満足しています。
Let's Encryptを避けるために考えられる4つの潜在的な理由は本当にあります。
- EV（またはOV）証明書が必要な場合。
- 証明書の更新を自動化できない、またはしたくない場合、3か月の証明書の有効期限は短すぎます。
- Let's Encryptを信頼していない場合（ただし、DNS-CAAなどの他の手段も検討する必要があります。ブラウザでLet's Encryptもブラックリストに登録する必要があります）。
- Let's Encryptが何らかの理由で中止またはブラウザから削除されると思われる場合。
これらのいずれにも該当しない場合は、証明書の代金を支払わないでください。