ルート証明書の使用をドメインに制限することは可能ですか?


28

私の顧客は、アプリケーションが機能するために自己署名証明書を使用しています。動作するには、証明書の署名に使用したルート証明書をインストールする必要があります。

1つのドメインに対してのみ検証するようにルート証明書を構成することは可能ですか?


それは私だけかもしれませんが、あなたが実際に何を求めているのかはわかりません。どのような最終状態を達成しようとしていますか?ルート証明書をドメインコントローラーの信頼にインポートすると、そのドメイン下のシステムのみがそれに対して検証できるようになります...
Gravy

自己署名証明書を、公的に信頼されていないルートCAの使用と混同しているように聞こえます。自己署名証明書を使用するように構成されたアプリケーションは、証明書検証エラーを無視するように構成する必要があるため、非常に悪いです。公的に信頼されていないルートCAを使用することは、実際には非常に一般的です。
グレッグアスキュー

内部CAサーバーはありますか?
Crypt32

1
CAは、名前制約を使用して特定のドメインに自身を制限できますが、他の誰かのCAに遡って制約を適用することは別の問題です。
マットノルドホフ

3
違いはありません。サードパーティCAにも名前の制約を適用できます。プライベートCAを使用してサードパーティのルートCA証明書に署名し、生成された相互証明書を公開するだけです。この場合、外国のチェーンは制限された相互認証を介してあなたのプライベートチェーンになります。
Crypt32

回答:


24

経験則として:

いいえ、顧客のCA証明書を信頼することは、そのCAによって署名されたすべての証明書の信頼を意味します。

特定の(サブ)ドメイン(*のみ)に対してのみ、顧客または他のCA証明書を信頼することをエンドユーザーとして選択できる簡単なオプションを備えたアプリケーション/ライブラリは知りません。 example.comと* .example.orgのみ。

Mozillaは、現在信頼されている政府支援CAをオープンアテンションポイントとして同様に懸念しています。たとえば、ChromeにはGoogleサイトにアクセスするための追加チェックが組み込まれています。これは、不正な* .google.com証明書とDiginotar CA 。

ただし、CAを信頼していない場合でも、そのCAによって署名された特定のサーバー証明書をインポート/信頼することができます。これにより、その証明書のホスト名に対するSSL警告が防止されます。これにより、アプリケーションがエラーや苦情なしに動作するはずです。

例外:

X.509v3 PKI標準の非常に未使用のオプションはName Constraints拡張です。これにより、CA証明書に、証明書の発行が許可されているドメイン名パターンのホワイトリストとブラックリストを含めることができます。

運がよければ、顧客はPKIインフラストラクチャをセットアップし、CA証明書にその名前の制約を含めたときに自分自身を抑制しているかもしれません。その後、CA証明書を直接インポートして、限られた範囲のドメイン名しか検証できないことを確認できます。


2
@CryptoGuy:内部CAは外部ドメインの証明書も発行できます。内部CAを信頼すると、自分の(Active DirectoryまたはDNS)ドメインの証明書のみ、example.comまたは*.ad.example.com 有効な証明書などの制限はありません。また、内部CAは*.example.bank、すてきな中間者攻撃を許可し、オンラインバンキングの認証情報を覗き見るための証明書を発行でき ます。
HBruijn

1
「すべて」は完全に正確ではありません。証明書失効リストなどがあります。しかし、それは最終的な結果を変えません。
ベンフォークト

1
申し訳ありませんが、あなたは再び間違っています。サードパーティCAを制限して、希望する名前リストに発行された(そのCAからの)証明書を信頼できます。あなた自身の内部CAに関して、私は信頼が疑わしいと思います。自分のCAを信頼していない場合、ITに何か問題があります。OPは、プライベートCAを持つことで、サードパーティCAに対する部分的な信頼を確立できます(信頼する名前を制限する)。
Crypt32

3
編集した投稿に:サードパーティCAに名前制約拡張機能がない場合でも、相互認証を介して独自の内部CAサーバーを使用してそれらを適用できます。この場合、証明書チェーンは次のようになります。リーフSSL証明書->相互証明書-> CA証明書->内部ルート証明書。秘trickは、内部CAを使用してサードパーティCAに署名することです。また、相互認証にはすべての必要な制約があります。
Crypt32

1
CryptoGuyはこれは可能であると言いますが、実装の詳細を見つけるのは困難です。これを達成する方法を説明する回答はどうですか?そして、おそらくどのプラットフォームがnameConstraintsをサポートしているかについての議論です。
ヨルフス

17

@CryptoGuyの回答はかなり良いものでしたが、さらに詳しく説明したかったのです。

言い換えると:

サードパーティCAを制限して、希望する名前リストに発行された(そのCAからの)証明書を信頼できます。サードパーティCAに名前制約拡張機能がない場合でも、相互認証を介して独自の内部CAサーバーを使用して、サードパーティCAを適用できます。秘trickは、内部CAを使用してサードパーティCAに署名することです。

リーフSSL証明書->相互証明書-> CA証明書->内部ルート証明書。

そして、これがどのように機能するかを示します(OpenSSLコマンドラインCAを使用)

単純なCAを作成する

openssl req -new -x509 -days 3650 -newkey rsa:2048 -sha256 -out root-ca.crt -keyout root-ca.key -subj "/CN=My Root CA"

中間CAの作成をスキップできます

Name Constraintsを使用して、中間CA要求を作成します。

openssl req -new -days 3650 -newkey rsa:2048 -out domain-ca.req -sha256 -keyout domain-ca.key -config ossl_domain_com.cfg

これをossl_domain_com.cfgファイルに:

[ req ]
prompt=no
distinguished_name=req_distinguished_name
req_extensions=domain_ca

[ req_distinguished_name ]
CN=somedomain.com trust CA

[ domain_ca ]
basicConstraints=critical,CA:true,pathlen:1
nameConstraints=critical,permitted;DNS:.somedomain.com

次に、CAでその中間ドメインCAに署名します。

openssl x509 -req -in domain-ca.req -CA root-ca.crt -CAkey root-ca.key -sha256 -set_serial 1 -out domain-ca.crt -extensions domain_ca -extfile ossl_domain_com.cfg

中間体の作成をスキップした場合は、ルートCAを使用して署名します

証明書を使用して、元のドメインのCAをあなたの権限で再署名します。ここでCA拡張機能を追加できます。

openssl x509 -in third_party_ca.crt -CA domain-ca.crt -CAkey domain-ca.key -set_serial 47 -sha256 -extensions domain_ca -extfile ossl_domain_com.cfg -out domain-cross-ca.crt

-x509-to-req引数を使用してリクエストを作成する必要がある場合があります。リクエストは、上記の中間体とまったく同じ方法で署名します。

次に、ルートCA、中間CA、およびドメインクロスCAをブラウザーの信頼データベースに追加します。


2
MacOSはnameConstraintsをサポートしていません。名前に制約のある内部CAで作業している人なら誰でもご利用いただけます。security.stackexchange.com/questions/95600/... archive.is/6Clgb
jorfus

Q:このソリューションのステータスはどうなっていますか?最近(2018)にどのシステムが機能しますか?//別の会社が自己署名証明書をインストールすることを余儀なくされるたびに、これが欲しかった。香港郵便局やシマンテックについて考えるたびに。//誤って拡大を実装しない限り、このように説明された縮小を実装しなくてもかまいません。
クレイジーグリュー

@KrazyGlewこれに使用するバッチファイルがありますが、今でも定期的に使用しています。時々、有効期限が切れるかローテーションするときに中間証明書を再発行しなければならないので、もう少し手間がかかりますが、問題はありませんでした。別の中間機関、または追加した追加のドメイン名を使用しているためにブラウザが信頼できない機関が管理するサイトを時々実行しますが、私のサイトはそれを信頼していません。
davenpcj

2
おかげさまで使用できました。中間証明書がなくてもうまく機能しますが、中間証明書を使用する利点はありますか?また、basicConstraints構成ファイルの行により、制約拡張が証明書に2回含まれるようになり、Firefoxが証明書を拒否し、不可解なエラーメッセージが表示されます。安全に削除できると思います。
wrtlprnft

最後のステップでエラーが発生しました:error with certificate to be certified - should be self signed。それは何を意味し、これを解決する方法は?pastebin.ubuntu.com/p/QHhpQh2N6J
mymediaは
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.