Exchangeの証明書計画

最近、私たちの専門家は、クライアントのExchange証明書のSANフィールドを最小化する問題に直面しました（証明書は支払われ、TMGはありません-つまり、同じ証明書が内部ユーザーと外部ユーザーに対して取得されます）。



NLBクラスターがあるため、ADドメインと外部名が一致しません（contoso.localとcontoso.ru）。 理想的には、次のようになります。

1. mail.contoso.ru（外部fqdn）

2. autodiscover.contoso.ru

3. cashub1.contoso.local（InternalNLBBypassUrlおよびSMTP、UMのint fqdn）

4. cashub2.contoso.local（InternalNLBBypassUrlおよびSMTP、UMの整数fqdn）

5. cashubnlb.contoso.local（fqdn ClientAccessArrayおよびInternalUrlの場合）

6.メール（多くの文字を入力しないように短い名前）

7. cashub1（多くの文字を入力しないように短い名前）

8. cashub2（多くの文字を入力しないように短い名前）



合計8つの名前は非常に高価です！



行こう：



1.短い名前は、アドレスを入力するときにリラックスしないでくださいので、すぐに放棄することができます！ （通常、サーバーのNetBIOS名は必要ありません。しかし、多くのユーザーと管理者はOWAを内部で使用することを好み、これによりログオン時に証明書に関する不必要な警告が防止されます。内部名を追加しても悪影響はありませんが、そうではありません必要です-blogs.technet.com/b/exchange/archive/2007/07/02/3403301.aspx ）。



2. DNSとすべてのInternalUrlを分割し、cashubnlb.contoso.localではなくmail.contoso.ruに登録するAutodiscoverServerInternalUriも実行します。



3. ClientAccessArrayの場合、値をcashubnlb.contoso.localに設定します。 Outlookは外部で速度が低下するため、HTTPSと同じ値を使用することはお勧めしません。 また、MAPI接続に使用され、SSLは使用されないため、証明書には必要ありません。 （CAS配列はMAPIのみであり、SSLを使用しないため、CAS配列FQDNは証明書に含まれてはなりません。CAS配列FQDNは、混乱が生じる可能性のあるOWA / EAS / OLA / EWS URLと同じではないことをお勧めします（同じFQDNを使用して）これを行うと、外部ユーザーのOutlook Anywhereで大幅なタイムアウト/遅延が発生します-social.technet.microsoft.com/Forums/en-US/exchange2010/thread/8e25cee3-dea3-41c8-886f -9152992dd598 ）。



4. SRV自動検出エントリを作成すると、証明書に自動検出エントリがまったくない場合があります。 （Outlook 2007は、自動検出サービスを見つけるためにDNS SRVレコードの追加チェックを実行します。この追加チェックには、自動検出サービスの複雑な構成や有効な証明書は必要ありません。）ただし、Aレコードはありません（Witout自動検出。証明書にxxx.orgが含まれている場合、DNSにはAレコードがありません。設定している場合は削除してください。） しかし、これは多すぎる...



5. SMTPおよびUMサービスの場合、自己署名証明書または内部証明書を使用できるため、intFQDNを拒否できます。



6. InternalNLBBypassUrlがまだ残っているので、BPAはそれを誓いますが、それは作業に一切影響しません。 -social.technet.microsoft.com/Forums/da-DK/exchangesvradmin/thread/54d2c3ae-3a12-4cbd-9ea1-70832e1b593a ）。



簡単な操作の後、次のようになります。

1. mail.contoso.ru（外部fqdn）

2. autodiscover.contoso.ru



それだけです！