私は、インターネットからの SSL アクセスを許可するように、特にインターネットから Exchange Server データを参照するいわゆる Outlook Web Access を有効にするように、Windows 2003 サーバーを構成しました。
以下の手順に従ってこのサイトインターネットからサーバーにアクセスするために使用する URL と同じ cname を使用するというアドバイスに従って、組み込みの W2K3 証明機関を備えた自己発行証明書を作成するという目標を達成しました。つまり、インターネットから Exchange Server データにアクセスするために使用される URL が 'mydomain.com/exchange' であるため、cname は 'mydomain.com/exchange' に設定されています。
ユーザーは接続を許可されていますが、面倒な信頼できない証明書エラーに直面しています。この問題については多くの記事を読みました。これは次の場合に発生するようです: - cname と URL が同じではない - 証明書が信頼できない認証局によって発行されている
この問題を回避するために、よく知られた認証局から発行されていない証明書でも、Web サイトにアクセスするワークステーションに強制的に受け入れるようにしてみましたが、問題は依然として残っています。
何を試せばいいでしょうか?
編集:
警告は出ますが、ナビゲーションは許可されます。私が受け取った警告は次のとおりです。
グーグルクローム：
サイトのセキュリティ証明書は信頼されていませんmydomain.com にアクセスしようとしましたが、サーバーは、コンピュータのオペレーティング システムによって信頼されていないエンティティによって発行された証明書を提示しました。これは、サーバーが独自のセキュリティ認証情報を生成したため、Google Chrome が ID 情報としてその認証情報を使用できないか、攻撃者が通信を傍受しようとしている可能性があることを意味しています。（とにかく続行）
インターネットエクスプローラー9:
*このウェブサイトのセキュリティ証明書に問題がありますこの Web サイトで提示されたセキュリティ証明書は、信頼できる証明機関によって発行されたものではありません。
セキュリティ証明書の問題は、ユーザーを騙そうとしたり、サーバーに送信するデータを傍受しようとしていることを示している可能性があります。 * (この Web サイトに進みます (推奨されません)。)
オペラ11:
サーバーの証明書チェーンが不完全で、署名者が登録されていません。受け入れますか? 証明書エラー: 「mydomain.com/exchange/」の証明書は、不明な証明機関「WIN2003DC」によって署名されています。これが有効な証明書であることを確認できません。
答え1
サーバーとワークステーションがすべて同じ Windows ドメインのメンバーである場合、ドメインの Windows 証明機関を作成し、Web サーバーに証明書を発行することができます。 CA のルート証明書は Active Directory に自動的に公開され、ドメインの一部であるすべてのコンピューターは、そのルート証明書とそれが発行したすべての証明書を信頼します。 これにより、組織は、サードパーティの証明機関に料金を支払うことなく、組織内のコンピューターによって信頼される独自の証明書を発行できます。 これらの証明書は、当然ながら組織内でのみ信頼されます。
ドメインがない場合、またはクライアント コンピューターがドメインの一部でない場合は、相互に信頼されているサード パーティの証明機関によって発行された証明書が必要です。証明書の料金は支払う必要があります。