Exchange Server 2010 uses certificates extensively to
protect the confidentiality and integrity of communications.
Certificates facilitate the use of industry-standard SSL and TLS
protocols to secure communications by Exchange Server in a flexible
manner using Open Standards. These protocols are native to the Internet
as well, allowing easy transition and transport of services over the
Internet and intranet.
Components Using
Certificates
Key Exchange
Server 2010 server components use certificates to authenticate and to
encrypt communications. Components that use certificates include the
following:
SMTP— The SMTP component in Exchange Server 2010 uses
certificates to encrypt and authenticate SMTP traffic between Hub
Transport servers and Edge Transport servers, between partner
organizations, and for opportunistic TLS.
EdgeSync Synchronization— Certificates encrypt the LDAP
communications between the Hub Transport and Edge Transport servers.
Unified Messaging— Certificates encrypt the SMTP traffic from the
UM server to the Hub Transport servers, IP gateways, and Office
Communications servers (OCS).
Autodiscover— The
HTTPS traffic between the CAS and the client are encrypted with
certificates.
POP3/IMAP4— The Post Office Protocol Version 3 (POP3) and
the Internet Message Access Protocol Version 4 (IMAP4) protocols are
encrypted and authenticated with certificates via SSL and TLS to improve
the security.
Outlook Anywhere—
Certificates are used to secure the Outlook Anywhere HTTP communications
from the CAS to the client.
Outlook Web App—
Certificates secure the Outlook Web App HTTP communications from the CAS
to the client.
ActiveSync—
Certificates secure the Exchange ActiveSync HTTP communications from the
CAS to the client.
Many of these services are
client-facing, and all the services can be externally facing as well,
creating potential risks to the confidentiality of the services.
Certificates enable the services to be protected with advanced
encryption to ensure their privacy.
Self-Signed Versus
Public Versus Private Certificates
The
difference between self-signed, public, and private certificates is
simply where they are issued from. If issued and signed by the owner of
the certificate, they are self-signed certificates. If issued by a
public CA, they are public certificates. If issued by a private CA, they
are private certificates. The difference is all in the level of trust
that third parties can place in the certificates.
Public certificates are
the gold standard of certificates. The public CAs that issue these
certificates are trusted by most operating systems and browsers, which
means they trust the certificates issued by the CAs. Examples of public
CAs include VeriSign, Thawte, and Digicert. Using a public certificate
is easy, but a cost is charged by the public CA for the certificate.
Because certificates have expiration dates, this is a recurring cost
that the public CAs charge every time the certificate is renewed.
Private certificates
are issued by private CAs. A private CA can be created on a number of
platforms, including Windows Server 2003 and Windows Server 2008.
Certificates issued by these private CAs have no cost. However, these
private CAs are not trusted by default by the operating systems and
browsers, so the certificates issued by these private CAs are not
trusted either. This can lead to annoying pop-up warnings or even failed
applications. These can be circumvented by adding the private CA to the
list of trusted CAs on the specific computers and deploying a Public
Key Infrastructure (PKI). There is typically significant administrative
overhead associated with maintaining a private CA.
Self-signed
certificates are issued by the computer using the certificate. This is
useful because it does not require any additional PKI infrastructure,
and the computer can maintain its own certificate. This enables an
application such as Exchange Server 2010 to reap the benefits of
certificates on installation without having to go through the additional
configuration steps to acquire a certificate from a CA. And there is no
cost or infrastructure requirement. However, this is the least trusted
and least secure of certificates because there is no third-party, public
or private, vouching for the certificate.
The server components
covered in the previous section all install by default in a protected
mode (that is, using SSL/TLS) using self-signed certificates. These
default self-signed certificates can be replaced as needed.
Choosing
Certificates in Exchange Server 2010
Exchange Server 2010 can
use any of the three types of X.509 certificates to encrypt a
communication channel. However, how the other end of the communications
channel views the certificate that is presented by Exchange Server 2010
is a major factor in which type to use. When the two end points, for
example, the Exchange Server 2010 server and a client, negotiate the
security of the communications channel, the Exchange Server 2010
certificate is presented to the client. If the client does not trust the
CA that issued the Exchange Server 2010 certificate, the communications
might fail or the user is prompted with a warning.
By default, Exchange
Server 2010 issues self-signed certificates on installation. Self-signed
certificates can be used for external communications but are not
recommended on a long-term basis. Self-signed certificates are the best
option for internal communications, such as for Unified Messaging or
EdgeSync services.
It is recommended to use
self-signed certificates for internal communications, which are the
following:
Between Hub Transport servers
Between Hub Transport and Edge Transport servers
EdgeSync communications
For
Unified Messaging communications
Internal-only
client access servers
Note
Self-signed
certificates that are created by Exchange Server expire in one year. The
internal components that rely on the default self-signed certificates
continue to operate even if the self-signed certificates have expired.
However, when the self-signed certificates have expired, events are
logged in Event Viewer. It is a best practice to renew the self-signed
certificates before they expire.
Public
certificates typically have a cost associated with their use but are
trusted by all the communication channel endpoints like the clients.
This ensures that when the Exchange Server 2010 presents a public
certificate during the negotiation of the communications channel, the
client accepts it without question.
It is recommended to use
public certificates for external client access communications, which are
the following:
POP3 and IMAP4
Outlook Web App
Outlook
Anywhere
Exchange ActiveSync
Autodiscover
Using public
certificates enables users to access services from a wide array of
locations such as home systems, Internet kiosks, and other companies’
systems without any certificate issues due to the ubiquitous trust of
public CAs, such as VeriSign.
Private
certificates fall into an interesting area for Exchange Server 2010.
Public certificates are identical to private certificates, except that
the clients must be configured to trust the issuing CA. This means
inserting the private CA certificate into the client’s Trusted Certificate Authority
container. When this is done, the client trusts all certificates issues
by the private CA just as if it were a public CA.
Using private certificates
enables administrators to forego the cost of public certificates with
some administrative effort. This is most effective if users access the
Exchange Server 2010 services from relatively few locations in which
there is a measure of administrative control, such as mobile domain
members or home systems. Domain members automatically trust an
Enterprise CA via Active Directory, so no configuration is needed. The
home users can be given instructions or scripts that configure the home
systems to trust the private CA. This is not effective with locations
such as Internet kiosks in which the users have no local control.
Names in
Certificates
Certificates certify the
identity of something, also known as the subject. For users, this is
their name and their email address. For Exchange Server 2010 servers,
the subject is the server name. In an X.509 certificate, the Subject
field contains the identity in the format CN = <subject name>. For
example, the Exchange Server 2010 EX1 server self-issued certificate
will have CN = EX1 in the Subject field. A user named Chris Amaris from
Company ABC might have an autoenrolled certificate with CN = Chris
Amaris and E = [email protected] to designate the email address of
the subject. Note that the Subject field can contain only one CN
reference.
However, multiple DNS names
for a single server can be quite common; owa.companyabc.com,
autodiscover.companyabc.com, smtp.companyabc.com, and
imap.companyabc.com might all reference different services on an
Exchange 2010 server supporting Hub Transport and Client Access Server
roles. Or even that a server might be referenced by its NetBIOS name
(for example, EX1) or by its fully qualified domain name (for example,
EX1.companyabc.com). When a receiving application examines the
certificate to verify the identity of the server, it might not find the
name for the server in the certificate Subject field and fails
authentication. These naming dichotomies cannot be represented with only
the Subject name.
To address this, there
are three name types of X.509 certificates:
These certificates
are the same X.509 certificates but have different fields within the
certificate populated in different ways. Public CAs charge different
amounts depending on how the fields are populated. And some Private CAs
and some Public CAs won’t issue certain types of certificates. Operating
systems and applications might or might not support all usages of these
certificates, so care must be taken in how they are deployed.
Single name
certificates contain only one subject name in the Subject field and are
the default certificate name type. All certificates must contain at
least one name. These certificates are supported by all platforms and
applications.
Subject Alternative Name certificates (SAN
certificates) have one or more names in the Subject Alternative Name
field of the X.509 certificate, typically in the format DNS
Name=<subject name>. When examining the certificate, the receiving
application matches names in both the Subject field and in the Subject
Alternative Name field. Exchange Server 2010 issues self-signed SAN
certificates by default. For example, the Exchange Server 2010 EX1
server self-issued certificate is a SAN certificate and will have CN =
EX1 in the Subject field, and DNS Name=EX1 and DNS
Name=EX1.companyabc.com in the Subject Alternative Name field. SAN
certificates are supported by most modern public CAs, operating systems,
and applications.
Rather than adding
each subject name into the SAN field of the certificate, it is
convenient to have the certificate represent all potential subject
names. This simplifies configuration and avoids the need to reissue
certificates if additional names are added later. Wildcard certificates
use the asterisk character (*) to designate all possible subject names
rather than list the names specifically. For example, rather than
specifying EX1 and EX1.companyabc.com, the certificate is issued to the
wildcard subject name *.companyabc.com and matches to both names (and
any other host in companyabc.com!). Wildcard certificate support is
being adopted slowly by operating systems, clients, and applications.
There is no common agreement on how to match wildcard certificates to
names, which is hindering the progress on adoption.
Wildcard certificates
are supported by Exchange Server 2010, Outlook, Outlook Anywhere, and
Outlook Web App. Windows Mobile 5.0 (Exchange ActiveSync) does not
support wildcard certificates.
However, special
configuration is sometimes needed on the Exchange Server 2010 server to
support wildcard certificates. For example, if wildcard certificates are
used on an Exchange Server 2010 CAS server, the set-OutlookProvider cmdlet must be run to enable the Autodiscover
service to function properly. The command for Company ABC using a
wildcard certificate would be set-OutlookProvider –Identity EXPR
–CertPrincipalName msstd:*companyabc.com.
To
illustrate the emerging support for wildcard certificates, Outlook 2007
does not support wildcard certificates out of the box and receives a
certificate error when accessing an Exchange Server 2010 CAS server
that’s configured with a wildcard certificate. Special configuration is
required to make it work. To configure Outlook 2007 to support a
wildcard certificate issue to companyabc.com, execute the following on
the Outlook 2007 client:
1. | In Outlook 2007, on the Tools menu, click Account
Settings.
|
2. | Select the
Microsoft Exchange Account Name and then click Change.
|
3. | Click the More Settings button.
|
4. | Select the Connection tab and click the Exchange Proxy
Settings button.
|
5. | Select
the Connect Using SSL Only check box.
|
6. | Select the Only Connect to Proxy Servers That Have This
Principal Name in Their Certificate check box, and then in the box that
follows, enter msstd:*.companyabc.com.
|
7. | Click OK twice.
|
8. | |
9. | Click Finish.
|
10. | Click Close.
|
Close Outlook and open it
again to have the setting take effect. The certificate error will no
longer be present.
In general, choosing SAN
certificates is the safest and most widely supported certificate name
type. Wildcard certificates are a good option if the public CA supports
them and additional configuration and testing time is allocated.
