本番環境で自己署名証明書の代わりにcacert SSL証明書を使用することは良い考えですか?


10

職場では、プレーンなhttpまたは自己署名証明書(ロードバランサー管理インターフェイス、内部wiki、サボテンなど)を使用する多数のWebインターフェイスがあります。

特定のVLAN /ネットワークの外部から到達できるものはありません。

自宅で使用する場合は、cacert SSL証明書を使用します。

私は雇用主に自己署名証明書とプレーンhttpの代わりにcacert SSL証明書を使用するように勧めるべきかどうか疑問に思っていました。誰でも本番環境でcacert sslを使用していますか?賛否両論は何ですか?セキュリティは向上しますか?管理は簡単ですか?予期しないことはありますか?品質スキャンに影響はありますか?どうすればそれらを納得させることができますか?

もちろん、公開ウェブサイトの有料証明書は変更されません。

編集:

(好奇心旺盛)企業からの無料のssl証明書はクラス3ではないようです。パスポートを提示し、物理的に立ち会ってcacertsからクラス3を取得する必要がありました。各クラス1のブラウザーに警告はありませんか?

とにかく、私は無料のCAについて同じ質問をします。自己署名されたプレーンなhttpを使用するよりも良いですか、そしてなぜですか?

管理を容易にするために、サーバー側で行います。見逃したことはありますか?

免責事項:私はCacert Associationのメンバーではなく、Assurerでもなく、通常のハッピーユーザーです。


異なる「クラス」からの証明書は、ブラウザではどのようにも扱われません。それらを信頼するかどうかは、完全にユーザー側にあります。ブラウザから特別な扱いを受ける唯一の種類の証明書は、拡張検証証明書です。
Hubert Kario 2012年

回答:


3

CACertのように無料の証明書を使用することには何の問題もありませんが、使用しても何も得られないことをお勧めします。

デフォルトでは何も信頼していないため、ルート証明書をすべてのクライアントにインストール/デプロイする必要があります。これは、自己署名証明書または内部CAによって発行された証明書の場合と同じ状況です。

私が好む(そして使用する)ソリューションは、内部認証局とそのすべてのドメインマシンへのルート証明書の大量展開です。使用する認証局を制御できるため、ポータルサイトよりもはるかに簡単に証明書を管理できます。独自のCAを使用すると、通常、証明書要求と対応する証明書の問題をスクリプト化して、すべてのサーバー、サイト、および証明書を必要とするすべてのものが自動的に取得し、環境に配置された直後にクライアントから信頼されるようにすることができます。 ITによる労力や手作業は不要です。

もちろん、独自のCAを設定して自動化するタスクに達していない場合は、前述のような外部の無料のCAを使用すると、少し楽になり、1つの外部ルート証明書を展開するだけで済みますが、たぶん、それを最初から正しく行い、ドメインの内部CAをセットアップする必要があります。


内部認証局のセットアップは、セットアップに時間がかかるため、行われる可能性は低いですが、無料のssl証明書よりも優れていると思います。

6

StartSSLからの無料のSSL証明書をお勧めします。これは、最新のブラウザーでも認識されます。CACertに対しては何もありません。ただし、証明書を発行するためのアカウントしか必要とせず、ルート証明書を手動でインストールしない限り、これらの証明書は誰にも認識されません。

これは製品の推奨事項であるため、義務的な免責事項:StartSSLとは一切関係ありません。ただ幸せな顧客。


3

自己署名されたプレーンなhttpを使用するよりも優れていますか?その理由

自己署名証明書は、ユーザー(およびユーザー)が警告を定期的にクリックスルーするようにトレーニングしますが、これは悪い習慣です。その自己署名証明書が不正な証明書に置き換えられた場合はどうなりますか?ユーザーは気づくでしょうか、それとも、まだ別のセキュリティダイアログを盲目的にクリックするでしょうか?


自己発行の証明書またはルートCAがクライアントマシン/ブラウザ/関連ソフトウェアによって信頼されている限り、そもそも警告はないと思います。これは、更新された証明書をクライアントに何らかの方法でプッシュ、再プッシュ、および再プッシュすることを意味します(必要な場合のみ)。ルートCAが必要になるのは1度だけで、それが変更された場合に限られると思います
Alex

自己署名証明書は、信頼されている場合でも警告をトリガーします。しかし、それらは信頼についての2番目の警告をトリガーしません。
Stefan Lasiewski、2014
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.