SSTP VPNサーバーの自己署名証明書
WindowsクライアントのSSTPをサポートする必要があるカスタムVPNソリューションを開発しています。このため、私のサーバーは、SSLハンドシェイク中に証明書を使用して自身を認証する必要があります。通常どおり、Windowsはローカルの信頼できる証明書のセットを調べ、接続を受け入れるか拒否するかを決定します。
このプロジェクトには現在、（Verisignまたはだれかからの）公式証明書に支払う予算がないため、ここでは自己署名証明書を使用したいと思います。残念ながら、これは、Windowsがサーバーを正常に認証できるように、ユーザーにこの証明書をインストールするように依頼する必要があることを意味します。
このシナリオについて2つの具体的な質問があります。
この自己署名証明書を「信頼されたルート証明機関」ストアにインストールするようにユーザーに要求した場合、これはユーザーに（なんらかの）セキュリティリスクをもたらしますか？たとえば、誰かが私の証明書の秘密鍵を手に入れたら、それを使用して、他のエンティティ（GoogleやFacebookや銀行など）になりすまして、それらの名前の独自の証明書に署名し、それをポイントさせるだけでよいのです。私のルート証明書、または彼らは私のサーバーを偽装することしかできませんか？
その場合、証明書を使用してSSTPサーバーを認証するだけで、他のhttpsまたは他の接続を認証しないようにWindowsに指示する方法はありますか？好ましくは、これは、証明書内のいくつかの設定だけでなく、ユーザーが簡単に実行または確認できるアクションです。
配布CA証明書を作成したくない。 CA秘密鍵を手にした人は、サードパーティの証明書をその場で偽造することにより、すべての顧客からのほとんどのTLS通信を傍受することができるため、これはあまりにも大きな責任を負うことになります。
配布するのは、顧客から見たホスト名と一致する共通名を持つ自己署名のエンドユーザー証明書のみです。このような証明書は、サーバーとの通信を保護するためにのみ使用できるため、安全に配布できます。
明らかに、公開証明書のみを配布します（通常、これは.pemまたは.crtファイル）、秘密鍵を非公開にします。
Windowsホストに展開する信頼されたルートCA証明書の証明書パッケージの一部として秘密鍵などを含めない限り。秘密鍵はおそらく他の方法で侵害されます。
そうは言っても、署名する中間または内部CAベースの証明書である場合は、署名証明書を取得した誰かがそれを使用して中間者を実行し、被害者のネットワークで「信頼できる」ssl復号化を実行したり、「信頼できる」なりすましフィッシングサイトやその他の悪意のあるブラウザフレンドリーなコンテンツをユーザーに作成したりする可能性があります。
自己署名証明書が純粋に信頼認証のみの公開証明書である場合。一般に、攻撃者がそれを採用せずにWebサーバーを偽装することを決定する限り、問題はありません。
どちらのシナリオでも、これが概念実証のためのテスト/開発環境で発生している場合は、おそらくサイバーセキュリティに関して懸念すべきより大きな問題があります。
代替認証について本当に偏執的である場合。サーバーがTLSを介して（相互認証）を認識しているクライアント側の証明書をクライアントが持つための要件を追加できます。また、ネットワークセキュリティインフラストラクチャがSSTP over SSL/TLSトラフィックにのみ特定のVLANまたは静的IP/MACペアリングでアクセスすることを許可する）場合がある代替制御もあります。