web-dev-qa-db-ja.com

証明機関を特定のドメインへの署名のみに制限できますか？

他のドメインで悪用されないように、特定の制限されたドメインの証明書への署名のみが許可されているCA証明書（署名されていない場合でも）を作成することはできますか？

tlscertificatespublic-key-infrastructurecertificate-authority
37
Smit Johnth

番号。

（SSLサーバーの証明書について話していると思います。）

技術的には違います。これに最も近いのはName Constraints拡張機能です（ RFC 5280 のセクション4.2.1.10を参照）（ OID 2.5.29.30 ）。これにより、理論的には完全なPKIサブツリーを明示的な一連のドメイン（およびそのサブドメイン）に制限できます。拡張機能は、ホワイトリストとブラックリストの両方のセマンティクスをサポートします（あなたの場合、ホワイトリストが必要です）。ただし、実際には、次の2つの理由で失敗します。

  • Name Constraints拡張機能は、SSLの既存の実装ではほとんどサポートされていません。彼らは拡張機能を無視する可能性があります。

  • SSLクライアントがサーバーに接続すると、 RFC 2818で指定されているように、サーバー証明書でサーバー名が検索されます、セクション3.1 。タイプdNSNameの名前をSubject Alt Name拡張子で検索し、これらの名前はName Constraintsによって（理論的には）カバーされます。ただし、サーバー証明書にSubject Alt Name拡張子がない場合、クライアントは（subjectDN内の）共通名にフォールバックします。 Common NameはName Constraintsのスコープ内にありません。これは、証明書がSubject Alt Name拡張子を省略し、任意のサーバー名をその共通名に入れることにより、名前の制約を回避できることを意味します。

（これはX.509の全体像です：実装からのサポートの欠如と仕様団体間の調整の欠如のために機能しない多くの便利な機能のための多くのフックと規定。）

25
Thomas Pornin

Thomas Pornin の answer は良いですが、少し時代遅れです。 Name Constraintsのサポートは増加しています。

OpenSSL 1.0.1kとWindows 7が拡張機能をサポートしていることがわかりました。

テスト

[〜＃〜] xca [〜＃〜] を使用して、自己署名CA証明書を作成し、Name Constraintsに重要な.lab.example.com拡張を追加しました。証明書の作成中の「詳細」タブの行：

nameConstraints=critical,permitted;DNS:.lab.example.com

注：制約には先行ドットがない必要があります。技術的には正しくありませんが、サポートは拡大しています： https://github.com/golang/go/commit/e4dafa32620e80e4e39937d8e2033fb2ee6085f8

次に、そのCA証明書を使用して、HTTPSサーバー用の他の2つの証明書に署名しました。

  • test.lab.example.com-有効
  • bad.google.com-明らかに無効

次に、それに応じてDNSエントリを設定した後、これを使用して 変更されたsimple-https-server.py を生成し、生成された各証明書でHTTPSサーバーを実行します。

./simple-https-server --certfile test.lab.example.com.pem --hostname test.lab.example.com

そして

./simple-https-server --certfile bad.google.com.pem --hostname bad.google.com

CA証明書をOS信頼にインストールした後、複数のクライアントを使用して各サイトにアクセスしてみました。

結果

OpenSSL 1.0.1kはこれをサポートしているようです。 curlでbad.google.comにアクセスしようとすると、次のエラーが表示されました。

curl：（60）この証明書の認証局は、この名前の証明書の発行を許可されていません。

Windows 7上のChromeも正しく動作します。 Chromeはかなり一般的なnet::ERR_CERT_INVALIDを提供しますが、Windows証明書ビューアは非常に明確です：

証明書の名前が無効です。名前が許可リストに含まれていないか、明示的に除外されています。

参考文献

アップデート1

notを含む証明書に署名してみたところ、代わりに古い共通名のみを使用してサブジェクトの別名を指定しました。

OpenSSL/curlは依然として証明書の受け入れを拒否しました。

ChromeおよびWindows上のIE11は、Windows自体（サーバー証明書を表示しているとき）がそれについて文句を言わなかったにもかかわらず、Windowsで証明書を受け入れることを拒否しました。私にとって、ブラウザは単にOSに証明書の検証を要求するだけではありません。これは良いことです。

ただし、名前の制約は OSXではサポートされていません のようです。

結論

ルートCA証明書を危険にさらすことなく、他の人にインストールするように頼むのは安全だと思います。

44
Jonathon Reinhart