Modifying Exchange Certificates

Exchange Server 2013, like its predecessors, relies on SSL-secured connections and encryption. For this reason, each Exchange Server requires its own server certificate. During the installation, each Exchange Server issues a self-signed certificate. The problem with this approach is that no client trusts this CA, which leads to certificate error messages. A solution to the problem is either to rely on an internal certification authority on the basis of the Active Directory Certificate Services or to use a third-party certificate. Clients that are members of the same Active Directory forest automatically trust internal certification authorities. If you use a third-party certification authority, you must manually add the CA certificate to your Trusted Root Certification Authorities if it is not yet known.

In Exchange Server 2013, you can manage server certificates directly in the web-based Exchange Admin Center. To assign a certificate to the server, click on servers in the Exchange Admin Center and then press certificates . Each Exchange Server in the organization needs its own certificate. To install a new certificate, first click on the plus sign. The wizard creates a certificate request, which you either request via the Active Directory Certificate Services or via the third party's web front end.

In the first step of the wizard, type in the display name for the certificate in the console. On the next page, you can specify that you also want to connect child domains with the same certificate. Then, select the server on which you want to save the certificate request (Figure 6).

Figure 6: Using SSL certificates to harden Exchange.

In the wizard, enter the name of the domain via which the server will be accessed externally or internally. The wizard then shows you which domains are listed for access in the certificate. Note that the name with which you access the server from the Internet is stored as the common name. Otherwise, clients accessing the server from the Internet see an error message because the name of the certificate does not match the URL for access. This point is especially important for using Outlook Anywhere. If you see a certificate error in Outlook Web App, you can confirm this without any effect, but Outlook refuses to connect with this type of error. On the next page, enter the data for the certificate and your organization and then save the request as a text file. You can then use this file to request the certificate.

In the next step, open the web front end for the certificate issuer. If you are working with the Active Directory Certificate Services, you can access it on https://<servername>/certsrv . Next, select the option Submit a certificate request using a base64-encoded CMC or PKCS #10 file or a renewal request using a base64-encoded PKCS #7 file .

In the next window, enter the complete text of the *.req file that you created in the Saved Request field. To do this, open the file in Notepad and copy the complete text to the clipboard by pressing Ctrl+A then Ctrl+C; then, use Ctrl+V to paste it into the field. Select Web Server as the Certificate Template and then press Submit .

Next, download the certificate as a *.cer file and save it on the server. Then, go back to the Exchange Admin Center and click on servers | certificates . Click on the certificate in the console and then press Finish . At this point, you can enter the path to the *.cer file, and complete the operation. The certificate should now appear as Valid .

For this to happen, the certification authority from which the certificate comes must be listed in the Trusted Root Certification Authorities on the Exchange Server. If you work with the Active Directory Certificate Services, the Exchange server installs the certificate for the trust relationship automatically via Group Policy. The root CA certificate must be deposited on the Exchange Server, so that the Exchange server will trust this CA certificate.

Conclusions

Exchange Server 2013 has many new features that are not just upgrades from Exchange Server 2007/2010. Microsoft has not managed to include long-awaited changes, such as the integration of databases in SQL Server. Management is somewhat easier, however, if the web interface is not quite as convenient as the legacy, proven Exchange Management Console. Integration of antivirus protection is nice, although any company that uses Exchange today already has a mailbox scanner. The new transport rules are, above all, a security feature.

Office 365 can connect to Exchange Server 2010 just as easily as to Exchange Server 2013. From my point of view, the changes do not justify upgrading from Exchange Server 2007/2010. Only companies migrating from some other system to Exchange should use the new version. Exchange 2013 is a little faster in comparison; it optimally supports Windows Server 2012 and cooperates better with Sharepoint, but do not expect revolutionary changes.