5件のコメント

SSLの証明書に関して、会社の人から「Exchange Server 2007のCASに入れる証明書なんだけど、Exchangeインストール後にCSRsを作成すべきなのか?Exchangeインストール前にCSRs作成してしまってもいいのか?」という質問を受けたのですが、このあたり不勉強でよくわからなかったのでお勉強。

とりあえず自分が知っていることとしては以下の程度。このあたりよくわかってないです。

  • Windows上のIISでCSRsを作成するにはIISの管理マネージャーから要求を作成すればよい
  • Exchange Server 2003のOWA用に証明書を発行するにはIISの管理マネージャーから要求を作成すればよいだけ。この際にアドレス(ドメイン名)の設定は慎重に行う必要があるが(インターネットからのアクセスと社内からのアクセスとでドメイン名が変わる場合などに問題になる)それを解決すればCSRsの作成はExchange Serverを構成する前でも問題ない。

なので、Exchange Server 2007に関してもExchange Serverをインストールする前にIISをSSL化してしまって問題ないだろう。と考えました。

でも、Exchange Server 2007のCASに関してはOWA以外にも以下のものに関してSSL暗号化の必要が当たり前にあることが想定されます。さらにそれぞれ対して社内からのアクセスとインターネット経由でのアクセスのアクセスを考慮する必要があります。

  • Outlook Anywhere
  • Autodiscover
  • POP
  • IMAP
  • Unified Messaging

ひとつの解決策としては、SSL暗号化が必要な通信に関してはすべて同じドメイン名になるようにドメイン名のコントロールを行ってしまう方法が考えられると思います。この場合には事前にIISの管理マネージャーからCSRsの作成を行ってしまって問題ないと思います。こういう方向にしてしまえば安全だし、話はここで終わりなのですが、Exchange Server 2007での証明書発行に関して調べてみると以下のページが見つかりました。

By using the Exchange Management Shell, you can create a certificate request to include all the DNS host names of the Client Access servers. Then you can enable users to connect to the certificate for services such as Outlook Anywhere, Autodiscover, POP3 and IMAP4, or Unified Messaging that are listed in the alternate names attribute. For example, your users may be able to connect to your Exchange services by specifying the name as shown in the following examples:

You can create a single certificate by adding all the possible DNS name values to the certificate Subject Alternative Name property on the certificate request. A Microsoft Windows-based Certificate Services certification authority should create a certificate for such a request.

“Subject Alternative Name”という属性を使ってこのようなことが可能にできるようです。

Note:
Third-party or Internet-based certification authorities will issue certificates only for DNS names for which you are authorized. Therefore intranet DNS names will likely not be allowed.

おっと。このように書かれているということは、”Subject Alternative Name”属性はWindowsベースの証明局でしか利用できないということなのでしょうか。(英語を間違って解釈している気もします。英語力が足りません・・・。)

ここまでわかった情報からは質問に関する回答としては以下のようになるのかと思います。

  • MS純正の証明局を利用する場合には、複数のホスト名(ドメイン名)に対応した証明書が作れる。その際にはExchange Server 2007インストール後にNew-ExchangeCertificateコマンドレットを使ってCSRsを作成する。
  • MS純正の証明局を利用しない場合、あるいは利用する場合でも単一のホスト名(ドメイン名)に対応した証明書でまかなえるようにホスト名を設計する場合にはIISの管理マネージャでCSRsを作成してよい。Exchange Serverのインストールとの依存関係はない。

本当にこの考えがあっているのか、周辺情報もチェック。

またサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。

まずはWikipediaをチェック。相変わらず勉強になる。でもコモンネームが複数という話には特に触れられていなかった。

複数のウェブサイトでSSL暗号化通信をする場合は、コモンネームごとにサーバIDを取得して設定する必要があります。
※SSL暗号化通信の際には、コモンネームがサイトのURLと一致しているかを確認するため、
 異なるサブドメイン等でアクセスした場合にはエラーとなってしまいます。複数サイトで
 SSLをご利用になる場合は、サイトごとに証明書が必要となりますのでご注意ください。
※ワイルドカード証明書(*.xxx.xxx.xx)では、同一ドメイン名の複数コモンネームに
 対応が可能です。

やはりコモンネームは単一、あるいはワイルドカードのみが指定できる模様。

サーバのホスト名 (DNS アドレス)が、サーバ証明書内の Subject Name あるいは Subject Alternative Name の項目と一致するかの検証を行うかどうかを指定します。

ここではSubject Alternative Nameについての記載があります。むむ。WindowsのCA限定の話じゃないですね。結構新しいRFCで定義されていて、まだ実装が追いついていないものが多い・・・という感じなのでしょうか。

opensslでsubjectAltNameを使って実験されている方がいらっしゃいました。なるほど。

こうなると、話はまた元に戻って、実際に利用しようとしている認証局ベンダーがSubject Alternative Nameに対応しているのかどうなのかという話になるのだと思います。クライアント側の対応に関しても考慮しなくてはいけないのだと思いますがまずは、証明局側から。シェアが一番多いベリサインはどうでしょうか。

とりあえずググってみたところ上記にヒット。CPSってなんだろう??

CPSはCertification Practice Statementの略だとのこと。最新版のVersion 3.4 日本語版 (PDF) を見てみたところ以下の記述が。

7.1.2.3 Subject Alternative Names
X.509 バージョン3 証明書のsubjectAltName エクステンションは、RFC3280 に従い設定される。
Criticality に関するフィールドは、「FALSE」に設定されなければならない。

ちょっともうよくわからなくなってきてしまいましたが、ここに定義されているということは対応しているし、設定可能だということだという気がします。

追記:以下のサイトに対応状況に関して記述がありました。

Currently Versign supports SAN property sets (but requires an Enterprise Agreement), Thawte does not (as of 4/16/2007), and Entrust does.  Entrust has a special section on their site for Unified Communication Certificates (can be used for Exchange 2007 or OCS 2007).  Search for UCC certificates.

ということで、質問に関する回答はこのようになるのかな?(自信はあまりないです)

  • 複数のホスト名(ドメイン名)でSSL通信を行いたい場合には、Subject Alternative Nameに対応した証明局を利用する必要がある。この場合にはまずExchange Server 2007をインストールし、その後にNew-ExchangeCertificateコマンドレットを使ってCSRsを作成する必要がある。前提条件としてクライアントソフトウェアでもSubject Alternatie Nameに対応している必要がある。
  • 利用しようとしている証明局がSubject Alternativeを利用しない場合、あるいは利用する場合でも単一のホスト名(ドメイン名)でまかなえるようにホスト名を設計する場合にはIISの管理マネージャでCSRsを作成してよい。Exchange Serverのインストールとの依存関係はない。

RFCの何番で定義されたのかとか、それが出たのは何年なのかとか、どこまで実装が進んでいるのかとかまだまだ調べることはありますが、一度ここまでにしておきます。年末だし。のど痛いし。

質問者へはまず、どのようなホスト名(ドメイン名)で構成する予定なのか確認ですね。

間違い等々たくさんあると思いますので、気がついた方突っ込み待ってます。教えてください。

その他の参考記事

5件のコメント

  1. CPSはその認証局のポリシーを書いたものですね.そのポリシーに従って,証明書を発行するわけです.今の認証局であれば,subjectAltName は必ず対応していると思います.X509 v3 の規格なわけですから.ただ,そこに何か値を入れてくれるかどうか?は,その認証局のポリシー次第となるわけですね.それとそういうサービスを提供しているか?最近サービスは調べてませんが,そういうサービスを提供している所ってあまり聞いたことないような.

  2. 細かい所ですが,前述の「ツッコミ」を少し訂正.CPSはその認証局の運用について書いたもので,ポリシーが前提にはなりますが,ポリシーそのものではないですね.認証局のポリシーやその他に基づいて,どのように認証局を運用します,と書いたのが CPS というところでしょうかね (この説明も間違っているかも? ^^;)

  3. >defiantさん
    丁寧にありがとうございます!
    おおよそのニュアンスはつかめた気がします。

コメントを残す

メールアドレスが公開されることはありません。