Managing exchange certificates

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/managing-exchange-certificates.html

Ilse Van Criekinge

PART-1

Introduction

Certificates can be used to encrypt the communication flow between two endpoints (both clients and servers). Certificates can also be used by these endpoints to authenticate themselves from each other. Exchange 2007 uses X.509 certificates for authentication and for encryption. X.509 certificates follow a standard format as published by the Telecommunication Standardization Sector (ITU-T).
An X.509 certificate is issued by a Certificate Authority (CA) that will bind the public key to a designated Distinguished Name, formatted according to the X.500 tradition, or to a so-called Subject Alternative Name or any of the Subject Alternative Names.
There are several components in Exchange 2007 that rely on certificates for encryption, authentication or both. In this article I will provide you with an overview of the different Exchange components that use certificates. I will then go deeper into the features of the by-default generated self-signed certificate. In part 2 of this article I will cover the naming requirements of a certificate you need to keep in mind when getting your certificates. To end, in part 3 of this article I will take a closer look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates.
Certificate Usage by Exchange Server 2007 Components

As already stated, several Exchange Server 2007 components rely on X.509 certificates for encryption, authentication or both. You will notice that when you install the Exchange 2007 Hub Transport server role, Client Access server role, Unified Messaging server role, and Edge Transport server role, Exchange will create by default a self-signed certificate to make sure its required components can use that certificate to function as required.
Figure 1 below shows you the self-signed certificate that is created by Exchange during the installation of the Exchange 2007 Client Access, Hub, and Unified Messaging server role. This certificate will be used by the following services: IIS, SMTP, POP, IMAP, and UM.

Figure 1: Self Signed Certificate created by default when installing the Exchange 2007 HUB, CAS, UM server role
Hub/Edge Transport server role and certificates

Transport Layer Security between Active Directory sites
The Exchange 2007 Hub Transport server role uses a certificate to encrypt all SMTP traffic between Active Directory sites. It is not possible to configure Exchange to allow unencrypted SMTP traffic between Hub Transport servers, located in different sites.
In order to see which certificate is used between two Hub Transport servers located in different Active Directory sites, you can enable SMTP protocol logging on the intra-organization Send connector on every Hub Transport server, as you can see in figure 2 below, by using the Exchange Management Shell cmdlet Set-TransportServer.

Figure 2: Setting IntraOrgConnectorProtocolLogging to verbose
By setting the so-called IntraOrgConnectorProtocolLoggingLevel to verbose, protocol logging will be added to the Send connector protocol log. After sending a mail from a mailbox homed in Site B to a mailbox located on an Exchange 2007 Mailbox server in Site A, looking at the Send protocol log reveals that the Exchange Hub Transport server in Site B (Ex2007SE) uses the certificate offered by the Exchange Hub Transport server in the destination Active Directory site (Ex2007EE) to start Transport Layer Security, as can be seen in Figure 3.

Figure 3: Send Protocol Log between Active Directory Sites
A quick look at the certificate on the Hub Transport server available for TLS, shows that it is a self-signed certificate used (Figure 4).

Figure 4: Self Signed Certificate
EdgeSync
Once EdgeSync is configured between your internal Hub Transport servers and the Edge Transport server(s), both servers will use a certificate to encrypt their communication. In addition both certificates will be used as a means to provide direct trust. Direct trust is a method of authentication where a certificate can be used for authentication when the provided certificate is present in Active Directory (for the Hub Transport server role) or ADAM/LDS (for the Edge Transport server role). When setting up EdgeSync, the requested certificates are published in the correct location.
Opportunistic Transport Layer Security
Whenever a SMTP server opens a connection to the Exchange 2007 Hub/Edge Transport server role, Exchange will allow for opportunistic TLS, by offering its certificate.
Domain Security
Certificates can also be used by the Hub/Edge Transport server to configure Domain Security with partner organizations, both for encryption and authentication.
Client Access Server role and certificates

Client Access
Certificates are used by the Client Access server role to allow the communication flow to be encrypted between the Client Access server and its different clients. By default SSL is required for:

• Outlook Web Access
• Outlook Anywhere
• Exchange ActiveSync
• POP3
• IMAP4
• Exchange Web Services as Autodiscover, EWS, and Unified Messaging

Figure 5: Require SSL
The only virtual directory for which the use of a certificate is not required by default is the one that makes the Offline Address Book available for download by Microsoft Office Outlook 2007 clients and later.

Figure 6: OAB Virtual Directory does not require SSL by default
Certificate Based Authentication
It is possible to configure certificate based authentication, thereby allowing clients to authenticate themselves against the Client Access server by using their personal certificate. For more information, please refer to the following blog post done by the Exchange team at msexchangeteam.org.
Unified Messaging Server Role and Certificates
Certificates are used by the Unified Messaging Server role to encrypt the communication when sending a recorded Voice Mail message to the Exchange Hub Transport Server role. Certificates can also be used to encrypt the SIP and/or RTP traffic to the UM IP Gateway, and have to be used when you decide to deploy Office Communications Server in your environment, since Office Communications Server only communicates with other server roles through encryption.
What is all this about the Self-Signed Certificate?

When you deploy any Exchange 2007 Server role, except for the Mailbox Server role, Exchange will generate a self-signed certificate, and allow Exchange to use this certificate when required for the services IIS, SMTP, POP3, IMAP4, and UM.
Characteristics of this Self-Signed Exchange Certificate

Let us have a look at some of the features of this by default generated Self-Signed certificate.
Self-Signed certificates are only valid for one year
Self-Signed certificates are valid for one year, as can be seen in Figure 7, and will need to be renewed after a year.

Figure 7: Self-Signed Certificate only valid for one year
To renew a Self-Signed certificate, you can use the Exchange Management Shell cmdlet New-ExchangeCertificate. If you first grab the existing certificate by running Get-ExchangeCertificate, you can pipe the object to the cmdlet New-ExchangeCertificate, which will generate a new Self-Signed Certificate with the same settings, and enable it for the same services by default.
In Figure 8 you can see how the existing Self-Signed Certificate is renewed.

Figure 8: Renew an existing Self-Signed Certificate
The Exchange 2007 Client Access server only allows one certificate to be enabled for usage with IIS, but you can have multiple certificates enabled for POP, IMAP, UM, and SMTP. When multiple certificates are available, Exchange will select a certificate based on different criteria. I will come back this certificate selection process in part 2 of this article.
Self-Signed Certificate has by default one Common Name and two Subject Alternative Names
The Self-Signed certificate that is created when deploying Exchange 2007 will have its common name set to the Host name of the Exchange server, and have two Subject Alternative Names set to its Host name and its Fully Qualified Domain Name.

Figure 9: Self-Signed Certificate and its Subject and CertificateDomains
It is possible however to generate a Self-Signed Certificate with another Subject and Subject Alternative Names to make sure it can be used in your Exchange organization.
Using the Exchange Management Shell cmdlet New-ExchangeCertificate, you can create for example a certificate with Common Name webmail.proexchange.global, and then specify Subject Alternative Names like the Exchange server its Host and Fully Qualified Domain Name, as seen in Figure 10.
Do not forget to add the boolean parameter PrivateKeyExportable and set it to True, if you want to be able to export this Self-Signed certificate to enable your users to trust it (full details on this in part 2 of the article).

Figure 10: Generating a new Self-Signed Certificate with customized Subject Alternative Names
In part 2 of this article, I will come back to the required names of a certificate. In part 3 I will explain in more detail the used cmdlets.
Self-Signed Certificate are only trusted by its issuer
It is very important to know that the Self-Signed certificate is only trusted by the issuer of the certificate itself, which could break Exchange functionality if not configured correctly. Let us see what you need to consider if you decide to use the Self-Signed certificate:

• Outlook Anywhere and Exchange ActiveSync do not support the use of a self-signed certificate
• The Autodiscover web service will not check if the issuer of the certificate is trusted when launching Microsoft Office Outlook 2007 from a domain-joined client pc, but will complain about the certificate if you are using Microsoft Office Outlook 2007 from a non-domain-joined client pc, as shown in Figure 11.

Figure 11: Self-Signed certificate not trusted

• When Microsoft Office Outlook 2007 clients (domain-joined or not) use the Exchange Web Services provided by the Microsoft Exchange Client Access server, they will be prompted by Outlook that the certificate is not issued by a company they have chosen not to trust. Figure 12 shows the Security Alert shown when someone requests Free and Busy information.

Figure 12: Self-Signed Certificate not trusted

• Microsoft does support the use of Self-Signed certificates, but only for internal scenarios, like:
  
  - To encrypt SMTP sessions between Hub Transport servers in different sites;
  - To encrypt SMTP sessions between Hub Transport servers and Edge Transport servers;
  - To encrypt the synchronization of configuration and recipient information by configuring EdgeSync between internal Hub Transport servers and Edge Transport server(s);
  - To encrypt SMTP sessions between Unified Messaging servers and Hub Transport servers;
  - To encrypt SIP and RTP sessions between Unified Messaging servers and Office Communications servers (this does require you to make sure that the Office Communication Mediation server trusts your Exchange server as the issuer of that Self-Signed certificate);
  - To encrypt internal client access to Exchange (POP,IMAP,Outlook Web Access).
  
  
• If you do not want Exchange to generate a self-signed certificate during installation, you can specify the /NoSelfSignedCertificates parameter next to Setup in the command prompt. Be careful: this parameter can only be used when installing the Client Access server role or the Unified Messaging server role. If your server does not have a valid certificate available to encrypt communication between clients and the Client Access server or the Unified Messaging server, communication will be unencrypted, and therefore, insecure.

Summary

In the first part of this 3-part article on certificates and Exchange, you have seen which Exchange 2007 components use certificates, and what characteristics the self-signed certificate carries. In part 2 of this article I will show how you can trust the self-signed certificate and I will cover the requirements of a certificate you need to keep in mind when getting your certificates. To end, in part 3 of this article I will give you a close look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates

---

موضوعات مشابه:

• Managing Exchange Server 2007 using a Windows XP workstation
• Managing Access to Resources and Managing Printing
• Managing Exchange Certificates
• Managing Exchange 2007 using PowerGUI
• مشكل با Certificates

---

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/managing-exchange-certificates-part2.html

PART-2

Introduction

Certificates can be used to encrypt the communication flow between two endpoints, which can be both clients and servers. Certificates can also be used by these endpoints to authenticate themselves against each other. There are several components in Exchange 2007 that rely on certificates for encryption, authentication or both. In the first part of this article I provided you with an overview of the different Exchange components that use certificates and for what purpose. I also went into detail covering the features of the by-default generated self-signed certificate. In this second part of the article I will cover the requirements of a certificate you need to keep in mind when getting your certificates. To end, in part 3 of this article I would like to give you a close look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates.
How to trust the Self-Signed Certificate?

As seen in part 1 of this article, it is supported and possible to configure Exchange to use the self-signed certificate for internal scenarios. In order to make sure your clients do not get any security alert when connecting to the Exchange 2007 Client Access server, it is necessary however that you get your users to trust the self-signed certificate. Remember, it is absolutely NOT a good idea to educate your users to discard security alerts! Figure 1 shows that the Self-Signed certificate is not trusted when using Outlook Web Access.

Figure 1: Self-Signed certificate not trusted
There are a few methods available to make sure your users recognize the Self-Signed certificate as a trusted one. I will only cover one method, which does not require any action from the users themselves, and that is publishing the Self-Signed certificate using Group Policies. Keep in mind however that you will need to repeat this action every time you renew the self-signed certificate!
1. Export the Self-Signed certificate
To export the Self-Signed certificate, you can use the Exchange Management Shell cmdlet Export-ExchangeCertificate. Since this will include the private key automatically you need to define a password, which I did in the example shown in Figure 2, by defining a secure string variable $pwd. Please note that you can only export a self-signed certificate if you have marked the certificate to have an exportable private key (as covered in Part 1 of this article).

Figure 2: Export Self-Signed certificate
2. Publish Self-Signed certificate as trusted via Group Policy
It is possible to publish the exported certificate in a user's personal store by using Group Policies. In the following example, I have started the Group Policy Management console to create a new group policy and apply it to the domain (Figure 3).

Figure 3: Create and link a new GPO to the domain
I called the new GPO Trust Self Signed Certificate, and I am not using any Source Starter GPO (Figure 4).

Figure 4: Name New GPO
Since I want to import the exported Self-Signed certificate, I drill down to User Configuration, Policies, Windows Settings, Public Key Policies, and right-click Trusted People to start the Certificate Import Wizard (Figure 5).

Figure 5: Start the Certificate Import Wizard
I specify the file I previously created by running Export-ExchangeCertificate, and click Next to continue (Figure 6).

Figure 6: Select File to Import
Next, I enter the password I used to export the private key, and click Next to continue (Figure 7).

Figure 7: Type the password used to protect the private key
The certificate store where the certificate will be stored is set to Personal Store, I click Next to continue (Figure 8).

Figure 8: Select Certificate Store where certificate will be kept
To finish I click Finish after reviewing the given settings (Figure 9).

Figure 9: Completing the Certificate Import Wizard
The Certificate Import Wizard will tell me that the import completed successfully. When clicking OK and the import is done, and the group policy is ready to be applied (Figure 10).

Figure 10: The import was successful
Next time a user logs in to the domain, or the group policy refresh kicks in, the Self-Signed certificate will be marked as trusted. As can be seen when gaining access to Outlook Web Access (Figure 11).

Figure 11: Self-Signed certificate = Trusted
Getting a certificate from a public certification authority

Even though Exchange 2007 does generate a self-signed certificate during installation, and you can enable clients to trust it, you need to keep in mind what I wrote in the first part of this article:

1. Self-Signed certificates are only valid for one year
2. Self-Signed Certificate are only trusted by its issuer
3. Self-Signed Certificates are not supported for Outlook Anywhere nor Exchange ActiveSync

Therefore it is recommended that you get yourself a certificate from a certification authority. You can choose to deploy your own certification authority, or you could get a certificate from a public certification authority. It is recommended by Microsoft to get a certificate from a public certification authority in the following situations:

• External client access to Exchange (POP, IMAP, Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, Autodiscover)
• If you want to setup Domain security with partner organizations

If you do get a certificate from a public certification authority, you will save yourself a lot of administrative hassle of getting your certification authority recognized as a trusted one by non-domain joined clients, and/or partner organizations that want to configure domain security with your Exchange environment.
Microsoft has published a knowledge base article (Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007) with a list of certification authorities that issue Unified Communications Certificates for Microsoft Exchange and for Communications Server 2007, which can be used to deploy the Domain Security feature.
What is a public certification authority?

Public certification authorities, otherwise referred to as root certification authorities, are certificate issuers that are trusted by practically all mainstream browsers and applications, thereby eliminating the need to get the certification authority trusted. When you decide to get a certificate from a public certification authority, you need to consider if the public certification authority is considered trusted by all applications you will be using and if it can get you the certificate you need (thinking about names, validity date, and so on).
Names to have in a certificate

Looking at a certificate, and why a certificate is not accepted to be used for encryption and authentication by Exchange, it usually boils down to any of the following four reasons:

1. The security certificate must be issued by a trusted certification authority;
2. The security certificate must not be revoked by the certification authority that issued it;
3. The security certificate must not be expired;
4. The security certificate comes with a name that does not match the expected name.

Even though some applications, like Outlook Web Access, allow you to use the certificate even though the certificate is not issued by a trusted CA, or the security certificate was issued for a different website's address, it is not recommended to ignore these warnings since it could mean that someone or some process is trying to fool you or intercept any data, as stated clearly by Microsoft Internet Explorer 7 (Figure 12).

Figure 12: Security Certificate Warning
Outlook Anywhere and Exchange ActiveSync will not function if there is any problem with the certificate (Figure 13).

Figure 13: Outlook Anywhere fails to connect since the name of the security certificate does not match the name of the target site
Let us have a look at the names you need for a security certificate for your Client Access server:

• NetBIOS name of your Client Access server;
• Full Qualified Domain Name of your Client Access server;
• Autodiscover domain name(s) of your Exchange organization;
• Name used to publish Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, Pop, and/or IMAP to external clients.

Names you need for a security certificate for your Hub/Edge Transport server:

• Fully Qualified Domain Name of your Hub Transport server;
• All accepted domain names in your Exchange organization.

And for the Unified Messaging server, you just need the Fully Qualified Domain Name of your Unified Messaging server role.
Example situation
Image you have got an environment as pictured below in Figure 14.

Figure 14: Example Exchange organization
In this Exchange environment, you will publish both Outlook Web Access, and Outlook Anywhere using your ISA server located in the DMZ. Mails sent to and from your organization pass your Exchange Edge server role, also located in the DMZ. Your Exchange organization has two domains for which it is responsible: ProExchange.Global and BelgianBeers.Rock. You have agreed to configure Domain Security between your Exchange organization and one of your partners organization Sunshine.Edu. EdgeSync is configured to replicate your configuration and recipient information to the Edge server. You will acquire two certificates from a public trusted CA, one to publish Outlook Web Access and Outlook Anywhere and one setting up domain security between your Exchange organization and Sunhine.Edu.
Table 1 lists the Exchange servers that exist in this Exchange environment, and their roles.

FQDN Exchange Server
Exchange Server 2007 Sp1 (RU5) roles installed
Edge.ProExchange.dmz
Edge Server role
Ex2007EE.ProExchange.Global
Mailbox + Client Access + Hub Transport server role
Ex2007SE.ProExchange.Global
Unified Messaging server role
Table 1
A closer look at your Exchange organization reveals the URL's listed in table 2 that are used from the outside and on the inside by users to connect to their mailbox.

Connecting to
Connecting with HTTP(s)
Connecting using RPC
Outlook Web Access
https://webmail.proexchange.global
https://webmail.belgianbeers.rock
https://Ex2007EE.proexchange.global
Outlook Anywhere
https://webmail.proexchange.global
https://Ex2007EE.proexchange.global
Free and Busy information
https://webmail.proexchange.global/EWS/Exchange.asmx
https://Ex2007EE.proexchange.global/EWS/Exchange.asmx
Download OAB
http://webmail.proexchange.global/OAB
http://Ex2007EE.proexchange.global/OAB
Change Unified Messaging settings
https://webmail.proexchange.global/U...g/Service.asmx
https://Ex2007EE.proexchange.global UnifiedMessaging/Service.asmx
Autodiscover
https://autodiscover.proexchange.glo...todiscover.xml
https://autodiscover.belgianbeers.ro...todiscover.xml
https://Ex2007EE.proexchange.global/...todiscover.xml
Table 2: URL's
These URLs can also be retrieved and changed using the Exchange Management Shell. Figure 15 shows the Exchange Management Shell cmdlets to retrieve the URLs provided by the Exchange web service Autodiscover to Microsoft Office Outlook 2007 clients.

Figure 15: InteralUrl and ExternalUrl configuration settings
Table 3 lists the records that are registered in DNS.

Name
Type
Data
Autodiscover.ProExchange.Global
Alias (CNAME)
Webmail.ProExchange.Global
Autodiscover.BelgianBeers.Rock
Alias (CNAME)
Webmail.BelgianBeers.Rock
Webmail.ProExchange.Global
Host (A)
External IP ISA Server
Webmail.BelgianBeers.Rock
Host (A)
External IP ISA Server
ProExchange.Global
Mail Exchanger (MX)
[10] Edge.ProExchange.Dmz
BelgianBeers.Rock
Mail Exchanger (MX)
[10] Edge.ProExchange.Dmz
Edge.ProExchange.Dmz
Host (A)
External IP Edge Server
Ex2007SE.ProExchange.Global
Host (A)
10.10.10.102
Ex2007EE.ProExchange.Global
Host (A)
10.10.10.101
Table 3: Registered records in DNS
To enable secure access to Outlook Web Access and publish Outlook Anywhere, the following names have to be present on the certificate that you will enable for the service IIS on your internal Client Access Server and export to your ISA 2006 Sp1 server:

• Common Name = Webmail.ProExchange.Global, Outlook Anywhere requires the common name to match the external host name used to enable Outlook Anywhere
• Subject Alternative Names:
  Webmail.ProExchange.Global
  Webmail.BelgianBeers.Rock
  Autodiscover.ProExchange.Global
  Autodiscover.BelgianBeers.Rock
  Ex2007EE.ProExchange.Global
  Ex2007EE
  Ex2007SE.ProExchange.Global
  Ex2007SE

To enable EdgeSync, offer opportunistic TLS and configure domain security with your partner organization Sunshine.Edu, you need a certificate for your Microsoft Exchange Edge server role with the following names:

• Common Name = Edge.ProExchange.Dmz
• Subject Alternative Names:
  ProExchange.Global
  BelgianBeers.Rock

In part three of this article I will provide you with detailed steps on how to create a certificate request with Subject Alternative Names, and how to import and enable the acquired certificate for your Exchange services.
Summary

In the first part of this 3-part article on certificates and Exchange, you have seen which Exchange 2007 components use certificates, and what characteristics the self-signed certificate has in stall. In this second part of the article I have shown you how you can trust the self-signed certificate and which names your Exchange certificate needs to have before you can successfully use it. In part 3 of this article I will give you a close look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/managing-exchange-certificates-part3.html

PART-3

Introduction

Certificates can be used to encrypt the communication flow between two endpoints, which can be both clients and servers. Certificates can also be used by these endpoints to authenticate themselves against each other. There are several components in Exchange 2007 that rely on certificates for encryption, authentication or both. In the first part of this article I provided you with an overview of the different Exchange components that use certificates and for what purpose. I also went into detail covering the features of the by-default generated self-signed certificate. In the second part of the article I covered the requirements of a certificate you need to keep in mind when getting your certificates. And to end, in part 3 of this article I would like to give you a close look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates.
Exchange Cmdlets for managing certificates

Exchange Management Shell offers you a set of cmdlets you can use to manage certificates in your Exchange environment:

• Enable-ExchangeCertificate
• Export-ExchangeCertificate
• Get-ExchangeCertificate
• Import-ExchangeCertificate
• New-ExchangeCertificate
• Remove-ExchangeCertificate

In part 2 of this article series, I described a given Exchange organization, for which we need to get 2 Exchange certificates, as summarized in Table 1 below.
Common Name
Subject Alternative Names
Required for Services
Webmail.proexchange.global

• Webmail.ProExchange.Global
• Webmail.BelgianBeers.Rock
• Autodiscover.ProExchange.Global
• Autodiscover.BelgianBeers.Rock
• Ex2007EE.ProExchange.Global
• Ex2007EE
• Ex2007SE.ProExchange.Global
• Ex2007SE

• Outlook Web Access
• Outlook Anywhere
• Autodiscover
• EWS (Out of Office, Free and Busy)

Edge.proexchange.dmz

• ProExchange.Global
• BelgianBeers.Rock

• EdgeSync
• Opportunistic TLS
• Domain Security

Table 1: Certificate Requirements
New-ExchangeCertificate

The Exchange Management Shell cmdlet New-ExchangeCertificate can be used to create a new self-signed certificate or can be used to create a new certificate request, which can be forwarded to your Certification Authority and afterwards imported and enabled for SMTP (Transport Layer Security (TLS)) and/or IIS, POP, IMAP, and UM (so-called Secure Sockets Layer (SSL) services).
The key parameter that will cause the cmdlet New-ExchangeCertificate to generate a new self-signed certificate or to generate a request, is called GenerateRequest. If you omit this parameter, a new self-signed certificate will be created by Exchange, as can be seen in Figure 1. If you add this parameter, Exchange will create a certificate request for a PKI certificate (PKCS #10) in the local request store.

Figure 1: Create a new Self-Signed Certificate
When creating a certificate request, the following list of parameters can be added:

• SubjectName - entered as a X.500 distinguished name, which contains the most important property of a certificate, the common name. The subject name is the field that is used by DNS-aware services, and will actually reassure the DNS-aware service that the certificate has indeed been issued for the requested server or domain name;
• DomainName - used to add any additional Subject Alternative Names to the certificate. You can add multiple domain names separated by a comma, but every domain name itself is limited to 255 characters each;
• IncludeAcceptedDomains - will add all accepted domains configured in the Exchange organization as subject alternative name (when names are defined both using the DomainName parameter, and using this switch parameter IncludeAcceptedDomains, they will only appears once in the certificate request)
• IncludeAutoDiscover - will add for every domain name the subject alternative name autodiscover.domainname. Two side notes here:
  - When names are defined both using the DomainName parameter, and using this switch parameter IncludeAutodiscover, they will only appears once in the certificate request
  - This parameter can only be added when running the cmdlet on an Exchange Client Access server
• Keysize - can be used if you want to specify a different size of the RSA public key associated with the certificate you are creating. If omitted, a default value of 2048 bits will be taken, but you can add the parameter and set the value to 1024 bits, 2048 bits, or 4096 bits;
• Path - where you want the certificate request to be stored. You need to specify both the path and a filename (file type .req);
• PrivateKeyExportable - can be used to generate a certificate (and/or request) with an exportable private key. If omitted, the private key will not be exportable. By adding this parameter and setting its value to True, you will be able to export the certificate and import it on another Exchange server and/or ISA box;
• BinaryEncoded - can be used to change the by default via Base64 encoded export file to a DER-encoded file;
• Services - can only be used when generating a new self-signed certificate to define which services (IIS,SMTP,POP,IMAP,UM) will use the new self-signed certificate. Default value for this parameter is set to SMTP (as can be seen in Figure 1), by setting its value to None you can generate a new self-signed certificate without enabling it for any service;
• FriendlyName - can be used to give your certificate another name than the default "Microsoft Exchange", it is limited to 64 characters.

Given our Exchange organization, we need to create two certificate requests. As can be seen in Figure 2, both certificate requests will be generated on our Exchange HUB/CAS/MBX server, called Ex2007EE. One certificate request, called secure_smtp.req will be used for SMTP, and the other one, called secure_client.req will be used for IIS, and UM. To make sure both certificates can be exported and shared, the private key will be set to be exportable.

Figure 2: New-ExchangeCertificate
These two certificate requests can now be delivered to the certification authority of choice, and after receiving the certificates, they can then be imported and enabled for the required services.
Enabling EdgeSync, check the following TechNet article

When enabling EdgeSync you need to keep the following TechNet article in mind, entitled "EdgeSync Fails with Event ID 10104", which clearly states that the Hub and Edge Transport servers do not support the use of the same certificate!
Import-ExchangeCertificate

The Import-ExchangeCertificate cmdlet allows you to import a certificate, which can be useful when:

• you want to import a previously exported certificate
• you want to import a certificate file generated by a certification authority

There are two important parameters which you should remember when running the cmdlet Import-ExchangeCertificate:

• • Password - to enter the password that was used to encrypt the private key when exporting the certificate
  • Path - to specify the location where you stored the certificate file received from a CA

Once the certificate has been imported, you need to enable it for a service, by running the cmdlet Enable-ExchangeCertificate.
Enable-ExchangeCertificate

By running the cmdlet, Enable-ExchangeCertificate, you will enable a certificate for one or more services by updating the metadata stored with the certificate.
Every service has different metadata requirements, and will have different properties updated:

• POP3-IMAP4: msExchPopImapX509CertificateName property will be updated;
• IIS: Default Web Site will be updated;
• SMTP: the Network Service account will be granted Read access to the appropriate private file key in the directory Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys;
• UM: certificate property will be updated to include Unified Messaging.

After receiving our two requested certificates, you can see in Figure 3 that they are imported, and in the same line, enabled for their required services.

Figure 3: Import-ExchangeCertificate
Get-ExchangeCertificate

To get a list of all certificates that are available in your local certificate store, you can run the cmdlet Get-ExchangeCertificate. You can use this cmdlet to review the certificate fields that are used by the Exchange services (Figure 4) like:

• Issuer: who issued the certificate
• Subject: Common Name of the certificate
• CertificateDomains: Subject Alternative Names defined on the certificate
• NotBefore: defines the date and time from when the certificate can be used
• NotAfter: defines the date and time when the certificate expires
• IsSelfSigned: to see if the certificate is a self-signed certificate or not
• RootCAType: defines the kind of CA that issued the certificate
• Services: for which services the certificate is enabled for
• Status: defines if the certificate is valid or not
• Thumbprint: a digest of the certificate data

Figure 4: Get-ExchangeCertificate (SMTP)

Figure 5: Get-ExchangeCertificate (IIS,POP,IMAP)
Export-ExchangeCertificate

In order to export a certificate (whether for backup purposes, or for using it on multiple servers), you can use the cmdlet Export-ExchangeCertificate. Running the cmdlet will export an exchange certificate and its private key by default.
It is also possible to use this cmdlet as well to export a certificate request. When running the cmdlet, Exchange will investigate the certificate to export (by using its thumbprint), and if it is a certificate request export it as a PKCS #10 file. If it is a certificate, the certificate will be exported to a PKCS #12 file.
There are two parameters to be kept in mind when running the cmdlet Export-ExchangeCertificate:

• Path: to define a target location and file name to store the exported file, remember to enter a .req file extension for exporting a certificate request, and .pfx or .p12 for exporting a certificate;
• Password: to protect the private key, has to be entered as a secure string (different methods can be used to set the password, as can be seen in Figure 6 and 7).

In our Exchange organization, I need to export both certificates to make sure they can be used multiple times. First I will export the one used for providing TLS, and import it on the Edge server role and enable it for SMTP, as shown in Figure 6. Then I will export the one used for IIS, POP, and IMAP, and import it on my Unified Messaging Server role, to enable it for UM, as shown in Figure 7 and 8, and I will import it and configure ISA to use it for publishing Outlook Web Access, and Outlook Anywhere.

Figure 6: Export-ExchangeCertificate (SMTP)

Figure 7: Export-ExchangeCertificate (IIS,POP,IMAP)

Figure 8: Import-ExchangeCertificate (UM)
Remove-ExchangeCertificate

Once you have enabled the required certificates for every service, you can choose to remove any un-needed certificate from Exchange server and the local certificate store by running the cmdlet Remove-ExchangeCertificate. If the certificate that you are removing is stored in Active Directory directory service, this instance will be removed as well.
Figure 9 shows you how you can remove all self-signed certificates at once.

Figure 9: Remove-ExchangeCertificate (Self-Signed)
Validate your Certificate configuration

After getting the required certificates, and configuring your Exchange services to use them, it is time to test if everything is working as planned.
Figure 10 shows you that Outlook Web Access and Outlook Anywhere work fine, using the required certificate.

Figure 10: Certificate properties
And the desired Domain Security feature with organization Sunshine.Edu, is configured as planned, as can be seen in Figure 11 and 12.

Figure 11: Domain Security

Figure 12: Domain Security
Summary

In the first part of this 3-part article on certificates and Exchange, you have seen which Exchange 2007 components use certificates, and what characteristics the self-signed certificate has in stall. In this second part of the article I have shown you how you can trust the self-signed certificate and which names your Exchange certificate needs to have before you can successfully use it. In part 3 of this article I have given you a close look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates