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での証明書発行に関して調べてみると以下のページが見つかりました。

ByusingtheExchangeManagementShell,youcancreateacertificaterequesttoincludealltheDNShostnamesoftheClientAccessservers.ThenyoucanenableuserstoconnecttothecertificateforservicessuchasOutlookAnywhere,Autodiscover,POP3andIMAP4,orUnifiedMessagingthatarelistedinthealternatenamesattribute.Forexample,yourusersmaybeabletoconnecttoyourExchangeservicesbyspecifyingthenameasshowninthefollowingexamples:
YoucancreateasinglecertificatebyaddingallthepossibleDNSnamevaluestothecertificateSubjectAlternativeNamepropertyonthecertificaterequest.AMicrosoftWindows-basedCertificateServicescertificationauthorityshouldcreateacertificateforsucharequest.

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

Note:
Third-partyorInternet-basedcertificationauthoritieswillissuecertificatesonlyforDNSnamesforwhichyouareauthorized.ThereforeintranetDNSnameswilllikelynotbeallowed.

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

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

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

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

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

SSLID
SSLURL
 
 SSL
*.xxx.xxx.xx
 

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

(DNS)SubjectNameSubjectAlternativeName

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

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

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

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

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

7.1.2.3SubjectAlternativeNames
X.5093subjectAltNameRFC3280
CriticalityFALSE

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

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

CurrentlyVersignsupportsSANpropertysets(butrequiresanEnterpriseAgreement),Thawtedoesnot(asof4/16/2007),andEntrustdoes.EntrusthasaspecialsectionontheirsiteforUnifiedCommunicationCertificates(canbeusedforExchange2007orOCS2007).SearchforUCCcertificates.

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

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

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

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

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

その他の参考記事