☰

エラー ホスト名が検証されません - テスト証明書 TLS Exchange 2016 cu21

tag-icon • tag-icon domain-name-system ssl lets-encrypt exchange-2016
エラー ホスト名が検証されません - テスト証明書 TLS Exchange 2016 cu21

Let's Encryptで証明書の練習をする勝利アクメ通常が作成され、通常のメール、OWAおよびその他のサービスでのhttpsを送受信します

テストチェックTLS警告メッセージが表示されます:

証明書ホスト名は検証されません:

(mail.contoso.com != mail | DNS:mail | DNS:mail.lan.contoso.com)

mail.lan.contoso.comのDNSエラーが理解できません。エラーはDNS SPLITだと思っていましたが、フォーラムエラーについて何かコメントします。

フォーラム、書籍、チュートリアルでは、他のコネクタは変更すべきではないと理解しています。誰も変更しません。そのため、インターネットから受信するための新しいコネクタが作成され、FQDN を変更できます。

この推奨事項フォーラム私のDNS設定：

プライベート AD DNS (lan.contoso.com)

レコードタイプ DNS名 内部IP
あ メール 192.168.1.4
あ 翻訳元 192.168.1.3

プライベート DNS (contoso.com) 分割

レコードタイプ DNS名 内部IP
あ メール 192.168.1.4
あ 自動検出 192.168.1.4

パブリック DNS (contoso.com)

レコードタイプ DNS名 価値
あ メール xxx.xxx.xxx.xxx
あ 自動検出 xxx.xxx.xxx.xxx
メキシコ @ メール

答え1

多くのテストを経て、私はいくつかのエラーメッセージを理解しましたチェックTLSExchange受信コネクタで使用される証明書です。チェックTLSそして、エラーなしでテスト全体に合格しました。

アドバイスありがとうございます@Lutz Willek。これからも練習を続けていきます。

私の解決策を皆さんと共有します。これがこの問題を抱えている他の人の役に立つことを願っています。

それが良い手順かどうかは分かりませんが、私が使用している解決策は以下を使用しますMicrosoft ドキュメント参考のため。

  1. Let's Encrypt証明書が作成され、サービスが有効になっていることを確認します
    Get-ExchangeCertificate | Format-List FriendlyName,Thumbprint,Issuer,Subject,CertificateDomains,Services
  1. 割り当てる受信コネクタを特定し、匿名ユーザーに焦点を当てました
    Get-ReceiveConnector | where {$_.Bindings -like '*25' -AND $_.PermissionGroups -like '*AnonymousUsers*'} | Format-List Identity,Bindings,RemoteIPRanges,PermissionGroups
  1. コネクタを特定したら、証明書の割り当てに進みます
    $cert = Get-ExchangeCertificate -Thumbprint xxxxxxxx

    $tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"

    Set-ReceiveConnector "Server_Name\Default Frontend Server_Name" -TlsCertificateName $tlscertificatename
  1. 受信コネクタに証明書が割り当てられているかどうかを確認する
    Get-ReceiveConnector -Identity "Server_Name\Default Frontend Server_Name" | Format-List Name,Fqdn,TlsCertificateName

答え2

もう一つの答え100%正しいです。

何が起こったかというと、ホスト名を使用して (内部) サーバーが作成されたということです。エラーは、 DNS 名を使用してサーバーに接続するmail.lan.contoso.com場合に備えて、このホスト用に作成された証明書がまだ提示されていることです。mail.contoso.com

だからあなたは必要機能的なサービスを作成するには、次の操作を実行します。

  • autodiscover.contoso.com内部ネットワーク内で への特定の名前解決は必要ないため、の分割 DNS 構成を削除します192.168.1.4。(パブリック名前解決は常に使用できるため)
  • クライアントが に接続するように設定しますmail.contoso.com。(自動検出設定を確認してください)
  • 用に作成された証明書を使用するように Exchange サーバーを構成しますmail.contoso.com。現在、 の証明書がmail.lan.contoso.com提示されています。

あなたができた信頼性を高め、メンテナンスの手間を減らすために、次の操作を実行します。(これにより、サービスをサーバーから分離できます)

  • サーバー側で、2 番目の IP 内部 IP アドレスを設定し192.168.1.5、内部の名前解決をこの IP アドレスに向けます。(サーバー自体を指している部分はmail.contoso.com変更しないでください)mail.lan.contoso.com
  • 192.168.1.5サーバー (Exchange) 側では、代わりにこの特定の IP でリッスンするようにメール サービスを構成します192.168.1.4。

少なくともできること考慮する、使用していない分割DNS全然：

  • 私の経験からすると、スプリット DNS が徹底的に実装されていない場合、かなりのデメリットが生じます。また、平均的な管理者のネットワーク経験では、残念ながら、関連するすべての課題を監視して対処するには不十分です。
  • もう 1 つの重要な理由は、ネットワーク設計が簡素化されていることです。これにより (他の利点の中でも) インシデントが発生した場合に根本原因をより迅速に特定できるようになります。
  • 分割 DNS 設定には、他の方法を使用してより効率的に実現できないような実質的な利点はあまりありません。

関連情報