Modify the internal/external host name of Exchange to be a unified domain name (outlook certificate error)

With the popularity of the Exchange mail system in more and more enterprises, employees are also happy to use Office Outlook to send and receive mail, greatly It is convenient for real-time effective delivery of work emails. However, when users use Outlook, they will encounter more and more problems, such as Outlook certificate error reporting, resulting in the failure to use the client. Today we will talk about the issue of the outlook certificate.

As we all know, the public network of the enterprise Exchange mail system must be combined with the public network certificate. Otherwise, many certification institutions at home and abroad cannot judge whether your enterprise email is a legitimate source of transmission, which may result in the failure of mail. Normally send and receive. The following figure is the default of some of our certificate management, the root certificate authority of the credit card, and only the public network certificate or private certificate issued by these organizations can make the application have real running rights and access rights.

At present, when an enterprise is setting up an Exchange mail server, if it wants to publish the public network, it usually applies for two kinds of certificates. One is “multiple domain names”. Certificate & rdquo;, the other is the "wildcard" & rdquo; certificate. The wildcard certificate is presented in the form of *.contoso.com, which means that all public domain accesses of the second-level domain name are allowed. It is also a certificate that we recommend now. Because this certificate is widely used and the authentication surface is very wide, it is basically not The Outlook certificate mentioned in this article will report an error, so it is not in the scope of this discussion.

This article focuses on the scope of the "multi-domain certificate". At present, the multi-domain certificate purchased from different certification authorities in China is a certificate that can contain five second-level domain names, so it is named “multi-domain certificate”. In other words, only when the second-level domain name publishing service included in this certificate is used can it be effectively and legally accessed.

In the current Exchange Server deployment, we generally use two front-end CASs recommended by Microsoft and two back-end MBXs for high-availability DAG deployment.

In this case, the "multi-domain certificate" we applied for usually contains the following two-level domain names:

We can see that the above five The second-level domain name contains the FQDNs of the two front-end servers. The purpose of this is to enable users to access the Exchange Server through the internal and external networks, and then access the server from the front-end client for authentication. service. But the front-end two CAS servers must also have a legitimate effect. In other words, they must have their own public network certificate entries. Because of this, we will also add the FQDN of the two CAS servers on the front end to the multi-domain certificate entry. (If it is a single mail server ALL in one deployment, you can apply for the FQDN of this server)

If we applied for the public network certificate, we forgot to add the FQDN of the front-end server to multiple domain names. In the certificate entry, or the certificate of the old mail server (the CAS name does not exist or has changed), our client outlook will encounter the following error when accessing the Exchange mail server, making the user unable to use the outlook client normally. end.

So how do you solve this problem? Let's look at it.

First of all, we can think about it, when the user uses Outlook to access the Exchange mail server, it prompts the certificate to report an error. This basic can be determined that when the client accesses, it cannot be verified, then we will be the administrator. Open EMS and use the get-outlookanywhere command to see the current settings for outlookanywhere.

Sure enough, we found that when the server accesses the Outlook, the internal host name and the external host name are different, because the mail system access names we publish are generally Is mail.contoso.com or other, but the internal access host name is written with our front-end server FQDN, so in the case of the front-end CAS server certificate is missing, we really can not pass the server verification. Then we can only circumvent this problem by modifying this value.

First we enable the SSLOffloading function with the following command

Get-OutlookAnywhere |  Set-OutlookAnywhere -SSLOffloading $true

Then use the following two commands to unify the internal/external hostname and enable SSL authentication requirements for internal and external users

Get-OutlookAnywhere |  Set-OutlookAnywhere -InternalHostname mail.guochen.com -InternalClientsRequireSsl $ture Get-OutlookAnywhere |  Set-OutlookAnywhere -ExternalHostname mail.guochen.com -ExternalClientsRequireSsl $true

After checking whether the internal/external URL hostnames of all virtual directories are unified to mail through the Exchange 2013 ECP console .xxx.com, if not, please change the URL to a uniform domain name.

After setting this up, we will look for our unified hostname mail.xxx.com for both internal and external outlook access, so that Ingeniously avoiding the error caused by the absence of the CAS certificate, the user can be authenticated from the internal and external network to the CAS server for verification, thereby linking to the back-end MBX mailbox database for normal mail use.

This article comes from “Ma Junyi's running space" blog, please be sure to keep this source http://horse87.blog.51cto.com/2633686/1616402