私たちの社内サイトを実装し、可能であれば証明書認証を使用したいと思います。私は人々がすべてのものに対して自己署名CAを作成するさまざまな例に触れてみましたが、それは私が望むものではありません。
セキュリティ上の理由から、実際のワイルドカードサイト証明書を使用してこれを開発したくありませんでした。秘密鍵ファイルを含むサーバーが少ないほど良いです。私がしたいのはこれです:
a)自己署名CAを使用してHTTPS用のSSL証明書に署名し、それをシステム証明書ストアに追加します。この冒険の目的に応じて、これは最初のCA、すなわちca-1
。
b)S / MIME証明書を発行したCAを使用して認証します(それらははい正しいタイプ! )この目的(クライアント認証)に使用される証明書は、2番目のCAまたは発行されますca-2
。
最終的に開発が完了すると、エンドユーザーca-1
の利便性とセキュリティのために、a)のサイトと証明書を当社SSL証明書プロバイダのサイトと証明書に置き換える予定ですが、開発ユーザー認証には公開証明書のみを使用するため、実際の証明書を使用やりたいです。キーは開発サーバーに保存されます。開発の観点からは、実際の証明書を使用する方が便利です。
また、SSL / TLSと認証用に別々のCAを選択できるという観点から、これがどのように行われるのかを見たいと思います。 (ただ昔の好奇心だけです。)
私のHTTPd設定(/etc/httpd/conf.d/site.conf
)は次のとおりです。
<VirtualHost *:443>
ServerName site
DocumentRoot /srv/site/www
SSLEngine On
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLHonorCipherOrder On
SSLCertificateFile /etc/pki/tls/certs/site-1.crt
SSLCertificateKeyFile /etc/pki/tls/private/site-1.key
SSLCertificateChainFile /etc/pki/tls/certs/ca-1.crt
SSLCACertificateFile /etc/pki/tls/certs/ca-2.crt
</VirtualHost>
<Directory /srv/site/www>
Require all granted
</Directory>
<Directory /srv/site/www/secret>
SSLVerifyClient require
SSLVerifyDepth 1
SSLOptions +StdEnvVars
SSLVerifyClient require
Require all granted
</Directory>
<VirtualHost *:80>
ServerName site
RewriteEngine On
RewriteRule ^(/.*)$ https://%{HTTP_HOST}$1 [redirect=301]
</VirtualHost>
また、SELinuxを使用する必要があることも知っていますrestorecon -RvF /srv
。 (すでにそうしています。)
アイデアは、認証されていないユーザーでもグラフィックを表示できるように開いたスプラッシュページを持つことです(単にページを表示するのではなく、再試行する前にコンピュータに証明書をインストールすることを思い出してください)。ドキュメントルートの403 Forbidden
コンテンツ/secret
しかし、認証されたユーザーにのみ表示されます。スパムページの少量のPHPは/ secretのコンテンツの可用性を検出し、自動的にユーザーをリダイレクトします。
計画は、HTTPdがCAによって署名された証明書を持つユーザーのみを認証することです(ca-2.crt
この場合)。しかし、もちろん、Webアプリケーションは証明書の組織(O)が私たちのものであることを確認する必要があります。後でアプリケーションがCAとO(組織)に満足している場合は、ブラウザがユーザー証明書で共有するCN(一般名)を使用して認証し、OU(組織単位)を使用して権限を分割することもできます。部門。
多くのアイデアのように、一見すると、とにかく良いアイデアのように見えます。しかし、実際には望ましい効果を得ることはできません。ブラウザは理由に言及403 Forbidden
せずにエラーのみを表示します。もちろん、外部コンテンツもうまく機能します。/var/log/httpd
/secret
site-1.crt
私のスマートカードの秘密鍵に署名したCAになります。 (私のホストOSはこれを知っています:私はそれを電子メールの署名と暗号化、SSH経由でサーバーにログインするために使用したので満足しています。)正しく動作することを確認してください。 )site-1.key
ca-1.crt
ca-2.crt
また、すべてのユーザーの公開鍵をHTTPdが認証するリストに追加する必要があることを受け入れる準備ができています。それほど便利ではありませんが、確かに安全です。また、会社全体または部門全体がリソースにアクセスするのではなく、よりきめ細かいアクセスも許可します。
この冒険にどんな助けでもいただければ幸いです。