筆者は,市場におけるベンダー間の競争こそが,製品の品質向上につながると考えている。最近ようやく競争が始まった分野の1つに,SSL(Secure Sockets Layer)証明書がある。SSL証明書を使うためには,ユーザー企業が独自に証明書を発行するか,外部の認証機関(CA)から証明書を購入する必要がある。最近,安価にSSL証明書を発行してくれるベンダーが増えている。ExchangeでSSL証明書が使いやすくなったといえるだろう。

 SSL証明書をただ使いたいだけなら,自社で独自の証明書を発行するという手もある。こういった自己署名の証明書は,多くのアプリケーションで有効だ。例えば,多くの企業がOfficeのマクロの署名に使ったり,イントラネットのWebサーバーを保護するために,自己署名の証明書を使用している。インターネットのサービスにアクセスするクライアントのセキュリティ・リスクに応じて,自己署名の証明書を利用するか,それとも英Comodo(日本法人は日本コモド)や米GoDaddy.com米VeriSign(日本法人は日本ベリサイン)などの外部のCAから購入した証明書を使用するかを決定すればいいだろう。

 外部のCAから証明書を購入する費用には大きな差がある。例えばComodoは128ビットのサーバー証明書を年間139ドルで販売しているが,GoDaddy.comの発行する同じ証明書の値段は年間90ドルである。証明書の強度,猶予期間,そして証明書発行者の評判など,すべてが最終価格に跳ね返ってくる。

 Exchangeではいくつかの用途で証明書を使用する。最も一般的なものは,当然ながらOutlook Web Access (OWA)へのアクセスの保護である。Exchange Server 2003以前のバージョンでは,OWAを使うのにSSLは必須ではないが,SSLを使用しないと,ネットワークの信用証明を盗み取ろうとするアタッカーに対して不必要に自分自身を公開してしまう可能性がある(Exchange 2003の認証では,SSLは必須であり,使用しない場合は認証が行われない)。証明書はほかにも,POP,IMAP,Exchange ActiveSyncのSSL保護照会にも使用できる。
 証明書の要求やインストールは全く容易であるが,「Internet Services Manager for Microsoft IIS」について,自主学習のみでは得られない知識が要求されるだろう。証明書をインストールし,保護対象のExchangeサービスに対して有効化すれば準備は完了である。

Exchange Server 2007でSSL証明書を取り巻く環境が変化

 Exchange Server 2007で状況は大きく変わる。自己署名の証明書のセットを自動生成してインストールするため,経験の浅い(または怠惰な)管理者にとっては大きな恩恵がある。これは,Exchange 2007 OWAがClient Accessサーバー・ロールをインストールした瞬間から自動的に保護されることを意味する。ただし,この新機能の追加によって,知っておかなければならない問題点がいくつか増えている。

 Exchange 2007のインストール時には,Exchangeでの使用のみを想定した,新しい証明書が自動的に生成される。この証明書は完全な128ビットSSL対応の証明書であるが,自己署名されているため,ブラウザやモバイル機器,ドメインに参加しているコンピュータの認証リストには表示されない。また証明書をOWAで使用しようとすると,証明書認証警告が表示される。

 Exchange 2007にインストールされた証明書は,HTTP,SMTP,IMAP,POPで使用するために自動的に割り当てられる。割り当てが瞬時に行われることや,これらのプロトコルを使用する通信はインストール完了直後から保護されるのは便利である。例えば,ExchangeはSMTP TLS (Transport Layer Security)要求に,インターネット標準の「STARTTLS VERB」とExchange 2007固有の「X-ANONYMOUSTLS拡張」を使用して反応する。同様に,Client Accessサーバー・ロールに対する自己署名の証明書が,Exchangeの仮想ディレクトリにOWAをインストールする際に割り当てられるため,OWAも即座に保護される。

 Exchange 2007における証明書の操作方法はいくつかある。新しいコマンド・ライン環境である「PowerShell」の「Get-ExchangeCertificate」というコマンドを使用すると,割り当てられているロールやプロトコルを含む,証明書のプロパティを確認できる。デフォルトでは,Get-ExchangeCertificateを新しくインストールしたサーバー上で実行すると,「services」フィールドに「all」が設定された証明書が1つ表示される。また,この証明書がOWAやExchange ActiveSyncを含む,いくつかのIIS仮想ディレクトリに割り当てられていることも確認できる。

 このような保護設定が自動的に行われるため,Exchange 2007は最初から安心して使用できる。ただし,他の証明書を導入する場合はどうだろうか。答えは「状況による」である。

 IISを介して提供されるサービスに対しては,標準のISM(Internet Services Manager)インターフェースを使用して,証明書の要求と管理を行う必要がある。幸運なことに,ISMを使用すれば既存の証明書を新しいExchange 2007 Client Accessサーバーに容易に移行できる。ただしエクスポート可能な秘密鍵を証明書に持っていることが条件である(鍵がない場合は,認証局が証明書の鍵を再設定してくれる場合がある。ただしポリシーはCAによって異なるため,この機能はあてにしないほうが良い)。

 Autodiscoverなど,他のExchangeサービスに対して独立した証明書を使用したい場合は,さらに「New-ExchangeCertificate」と「Import-ExchangeCertificate」という2つのPowerShellのコマンドを覚える必要がある。New-ExchangeCertificateは,新しい自己署名の証明書や証明書要求(これは利用したいCAに送信する)の生成に使用する。CAから証明書が返送されたら,Import-ExchangeCertificateを使用して,CAが発行した証明書と使用したいExchangeサービスをリンクさせる(公開鍵暗号化標準規格#12のファイルが入力として必要になる)。

 証明書を展開する場合は,いくつか微妙な問題があることを頭に入れておく必要がある。まず,1つのClient Accessサーバーで複数のサービスが動作する可能性があることを忘れてはいけない。Microsoftは現在,証明書に新たにサブジェクト名を追加することを推奨している。こうすれば,証明書が例えば「autodiscover.robichaux.net」と「mail.robichaux.net」に対して発行されていることが分かるが,外部のCAのすべてがこのような追加名を許可しているわけではない。

 次に,内部の操作で自己署名の証明書を使用するのは全く問題ないが,TLSで保護されたSMTPやOWA,Exchange ActiveSyncといった外部に公開するサービスには,外部発行の証明書を使用したほうが良いということを頭に入れておく必要がある。特に,Windows Mobile 5.0デバイスのなかには,新たな証明書ルートのロードが容易でないものがあり,この制限がCAの選択に影響する可能性がある。