"Deep Exchange 2013"09 Certificate

Let's talk about the certificates in Exchange, CAS and MBX roles are useful to certificates, but CAS roles rely more on certificates, and when an Exchange server has just been installed, the installer automatically generates a self-signed certificate. This self-signed certificate often does not meet our needs, so we typically request an appropriate certificate for the DNS alternate name of the multiple IIS services involved in exchange for the enterprise CA.

Where Exchange uses certificates

1. Let the client verify the identity of the server. This is the most general usage, most administrators may have encountered a certificate name mismatch caused by the client error.

2, the server to verify the identity of the client or device, that is, client certificate authentication.

3. Protect SMTP mail transport and encrypt SMTP connections with Transport Layer encryption Protocol (TLS). Message delivery between Exchange servers in your organization The TLS connection is applied by default, and the TLS option can be turned on manually with an Exchange server outside your organization.

4. Authentication between servers and servers, also known as Mutual TLS, is most commonly used for integration with Lync servers.

Certificates are also used on Windows operating systems and some applications, such as PowerShell scripts that are encrypted with IPSec or digitally signed. We're just talking about exchange here. It should be mentioned that Exchange 2013 does not currently support IIS8 's centralized certificate store functionality, and it is not known that Exchange 2016 has changed.

If you're just running Exchange on your internal network, there's no plan to provide external user access. As long as you're not afraid to trouble. To install the client and ActiveSync devices uniformly, the Exchange2013 default self-signed certificate is fully sufficient. For the domain of the client is relatively simple, do a GPO, this self-signed certificate issued to the domain of the PC's Trust certification authority, of course, a certificate corresponding to a CAS server, there are several CAS server, you have to put these days on the CAS on the self-signed certificate all issued down. This is still a PC, if you run into a Windows phone that hand-installed certificate, it can be ... Imagine this workload ... The default self-signed certificate is valid for five years, but at least you have busy for a period of up to five years.

But when you have external client access requirements, this can be really out of the point. Because self-signed certificates are not trusted by external clients (unless you convince them to be loaded, similar to the first 12306).

Where to get the certificate

Ok, look at the above things, you wake up to say we do not use self-signed certificate, this time you have two choices, one is to enable the Windows Certificate Services feature within the domain, and then build a PKI structure within the enterprise. The second is to buy a certificate from a third-party certificate provider (root certificate). Each method has its own advantages and disadvantages.

Third-party certificates require additional cost of money, general Enterprise Single-domain Certificate in 3000-6000 years (see Manufacturers and categories) plus a domain name is doubled, wildcard domain name Certificate Basic pricing policy is a single domain price x3. But after buying this third-party public network certificate, your domain is included in the Internet-level chain of trust, for example, if you buy VeriSign or Digicert, what are the domestic wosign, these institutions are already considered to be the default trust, in other words, You can turn to the root CA certificate of these institutions in the certificate store of a newly installed operating system. Such other companies or organizations, or external computers and devices, can trust your Exchange server by default without having to make any additional settings.

Setting up your own PKI architecture is completely FREE because it relies on Windows Server's own Certificate Services to run, and this allows administrators to fully control the issuance of certificates and to know which certificates are used for what. The problem is also good to solve, you just need to reissue a correct certificate on it. And if you want to deploy EFS or smart card logins later in the environment, it's easier to have your own CA to do these things than to use a third-party certificate. Issuing certificates to each Exchange server with a CA in its own domain, as long as the client in the domain installs the root certificate of the domain root CA by default, and they trust the Exchange server by default. However, external devices or clients still need to be installed, but only one, that is, your internal domain CA's root certificate can achieve the effect of trusting the Exchange server. Of course, if you have money, you can also bribe a wildcard certificate so that the entire organization's servers are trusted by the external user by default. This still involves cost issues, and very high, if necessary, go to the various certificate website to look at the price bar.

Certificate content

Regardless of the method in which the certificate is issued, the SSL certificate contains the public and private keys to encrypt the content between the client and the server. The CAS server provides a copy of the public key to the client that is connected, the client uses the public key to encrypt the communication, and the CAs can use its own private key to decrypt the communication so that a secure channel is established between the client and the server. Next, the client generates a shared key, and uses the CAS public key to encrypt the shared Key,cas to decrypt the shared key with the private key, and then both sides agree to use the shared key to encrypt the information for communication, noting that this is not only the public and private keys used by the client and CAS, There is also a shared key. So that even if someone intercepts the data and gets the CAS public key, it still can't get the content inside because he doesn't have the CAS private key and can't get the shared key. (For specific SSL handshake procedures please refer to: https://support.microsoft.com/en-us/kb/257591)

In addition to the public and private keys, the certificate has some additional embedded properties, including the expiration date, the principal name, and other user-selectable names (subject alternative names SANS). When you request a certificate for a server, the CA will digitally sign these embedded properties when the certificate is issued to ensure that it is not tampered with after the certificate has been issued. This means that if you find that there is something wrong with the certificate after the certificate has been generated, you can only apply it honestly.

Recommendations for planning certificates

For this question, I have the following suggestions

1. Minimize the number of certificates you use, the more certificates you use, the higher the cost, or the more complex the environment becomes.

2, the use of San Certificate, the General certificate contains only one domain name, but the San certificate, that is, the user optional name can contain multiple domain names. This reduces the number of certificates, and you can use a SAN certificate to cover all of the namespaces for Exchange 2013 services, such as autodiscover.contoso.com,mail.contoso.com, Cas01.contoso.com,cas02.contoso.com and so on are gathered in a SAN certificate.

3, do not in the main name of the certificate with the computer name, thoughtful, do not write the computer name, but with the load-balanced array name, that is, a farm unified access point FQDN

4. Remember that you can apply different certificates to different services

5. Deploy Vista SP1 or newer clients so you don't have to worry about the various issues about the name of the certificate subject due to client compatibility.

Request and apply a certificate

Microsoft recommends that you use the built-in certificate management tools in the EAC to request and apply certificates, but unlike Exchange 2010, you won't see the specifics of PowerShell execution at the end. The specific steps are not introduced here, the use of the EAC and Exchange2010 of the students will find that Microsoft in the ease of use is still some effort. You can also use the PowerShell command to request a certificate, for example, I want to apply for a certificate with multiple user alternative names:

New-exchangecertificate–generaterequest–path ' c:\temp\cert.req ' –subjectname ' c=cn;o=contoso;cn=mail.contoso.com ' –domainname ' mail.contoso.com, autodiscover.contoso.com, legacy.contoso.com ' –privatekeyexportable $True

Combine namespaces and say a few more

Remember the previous article about namespaces, we combine certificates and namespaces to see the certificate planning for the following three scenarios

Scenario One:

Contoso has two offices in Redmond and Portland, where the current environment is Exchange2007 coexistence with Exchange2013, and a dual active DAG is deployed for two 2013 MBX to increase site resilience. The client does not have to worry about connecting to which data center can get the mailbox data correctly, and ensure that there is no single point of failure on the connection, the load balancer will continue to turn on SSL offload.

For these requirements, Contoso requires the following namespaces

1, autodiscover.contoso.com– automatic discovery

2. Legacy.contoso.com–ex2007 the namespace that the client must have under coexistence conditions

3. mail.contoso.com--owa,activesync,outlookanywhere Primary namespace

4, Smtp.contoso.com-imap client use

5, Imap.contoso.com-imap client use

Then we have the following namespaces that conform to the unbound model (SSL offload is turned on, and load balancing can be used for health detection and load balancing on each protocol at layer 7. ）

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/6F/54/wKioL1WZYBPSft9cAAGDTU77_fo583.jpg "title=" Qq20150706004052.png "alt=" Wkiol1wzybpsft9caagdtu77_fo583.jpg "/>

Scenario Two:

Contoso has a data center in Redmond and Bel Air, where Exchange 2010 and Exchange2013 coexist, and Contoso requires users to connect to their nearest client, unless a failure occurs to switch and disable SSL offload on the Load balancer device (then you have to solve the health detection problem by using a namespace per service).

In order to meet the above requirements, we need the following namespaces

1, autodiscover.contoso.com

2. mail-wa.contoso.com Redmond The primary namespace of the OWA service in the data center

3. Primary namespace for OWA services in mail-md.contoso.com Bel Air data Center

4. Failback namespace for OWA service in mailfb-wa.contoso.com Redmond data Center

5. Failback namespace for OWA service in mailfb-md.contoso.com Bel Air data Center

6. EAs namespace in Eas-wa.contoso.com-redmond data center

7. EAs namespace in Eas-md.contoso.com-belair data center

8, Oa-wa.contoso.com-redmond's Outlookanywhere

9, Oa-md.contoso.com-belair's Outlookanywhere

10. Ews-wa.contoso.com-redmond Exchange Web Services

11, ews-md.contoso.com

12. Oab-wa.contoso.com-redmond Offline Address Book

13, Oab-md.contoso.com

So our solution fits into the model of the bound namespace.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/6F/57/wKiom1WZXlPBssNMAAGqO_I5LwM968.jpg "title=" Qq20150706004102.png "alt=" Wkiom1wzxlpbssnmaagqo_i5lwm968.jpg "/>

Scenario Three:

Contoso has two offices in Redmond and Portland, where the current environment is Exchange2007 coexistence with Exchange2013, and a dual active DAG is deployed for two 2013 MBX to increase site resilience. The client does not have to worry about which data center is connected to the mailbox data, and ensures that there is no single point of failure on the connection, and SSL offload is turned off on the load balancer.

So to meet the above requirements, we need the following namespaces

1, autodiscover.contoso.com

2, legacy.contoso.com

3, mail.contoso.com

4, oa.contoso.com

5, ews.contoso.com

6, Oab.contoso.com

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/6F/54/wKioL1WZYC6A0TpfAAGKpF1LKxw426.jpg "title=" Qq20150706004110.png "alt=" Wkiol1wzyc6a0tpfaagkpf1lkxw426.jpg "/>

OK, the certificate we are finished, so far is a total of 9 articles, about the front end of the CAS is basically over, the next chapter begins we'll talk about the transport service in Exchange 2013.

This article is from the "Castamere Rainy season" blog, be sure to keep this source http://sodaxu.blog.51cto.com/8850288/1671153

"Deep Exchange 2013"09 Certificate