donderdag 23 april 2009

setting up certificates exchange 2007

Client Access Server Certificates
By default, Exchange 2007 installs self-signed certificates that are acceptable for use on the Hub Transport and Edge Transport server roles in most situations. There are however one or two exceptions, such as using Edge Transport server features, namely domain security. However, the self-signed certificates are not suitable for Client Access Server features such as Outlook Anywhere and long-term use of Outlook Web Access. As a result, the self-signed certificates installed on Client Access Servers should be replaced. In my project scenario, the Client Access Server role and the Hub Transport server role coexisted on the same servers, so in effect, I also replaced the Hub Transport server certificate too.

Within the customer’s Active Directory environment there was an internal Windows-based Certificate Authority (CA) that was capable of issuing the required certificates. This was good to see, since there are many Microsoft products other than Exchange 2007 that require the use of certificates, such as Office Communications Server 2007 for example. Once the Windows CA had been set up, it was obviously free in monetary terms to create certificates using this method rather than purchasing them from a public CA. Of course, certificates issued by a public CA are required on the ISA Server since it was accepting public requests for services such as Outlook Web Access, Outlook Anywhere and so on.

To create new certificates for the Client Access Servers, the first thing that needs to be done is to generate a new certificate request using the New-ExchangeCertificate cmdlet. It is very important to understand the various names that this certificate will require. Since the certificate requires multiple names, the Subject Alternate Name attribute is used. On my certificates I ensured that the following names were present:

The FQDN of the server, such as hubcas1.neilhobson.com or hubcas2.neilhobson.com.
The NetBIOS name of the server, such as hubcas1 or hubcas2. This is not strictly required, but I always add it anyway as quite often I like to test and use Outlook Web Access simply by entering https://servername/owa. Adding the server’s NetBIOS name to the certificate makes sure that you do not get a certificate warning prompt when using the server’s NetBIOS name.
The accepted domain name for the organization (such as neilhobson.com) which in my example, only a single accepted domain name is in use. However, in cases where additional accepted domain names are present you need to cater for them. An easy way to do this in Exchange 2007 Service Pack 1 is to use the –IncludeAcceptedDomains parameter of the New-ExchangeCertificate cmdlet which ensures that all accepted domains that you have defined are included in the certificate request.
The autodiscover domain name, such as autodiscover.neilhobson.com. In fact, I used the new –IncludeAutodiscover parameter of the New-ExchangeCertificate cmdlet for this purpose. Like the –IncludeAcceptedDomains parameter, this ensures that the autodiscover name for any additional accepted domain names is included in the certificate request. You do not have to use this parameter. If you do get into the habit of using it you will not forget any additional domain names that might be required.
The name that users will use to access email remotely, such as email.neilhobson.com.
Had I been using a certain technology such as Windows Network Load Balancing (NLB), it would have been a requirement to include the NLB name in the certificate too if it was different to the remote access name, but this was not the case in my project. Just to elaborate on this a bit further, imagine that users externally typed email.neilhobson.com to access Outlook Web Access when working remotely. It makes sense, from a training perspective, to allow the users to type the same address into their browsers when working on the internal network. If using NLB, you could therefore make sure that the NLB name was set to email.neilhobson.com, to give users a consistent naming experience when accessing Outlook Web Access. However, if you had decided to implement a different name for Outlook Web Access via NLB internally, such as nlb.neilhobson.com, you would need to make sure that the name nlb.neilhobson.com was also included in the certificate names.

Creating The Certificates
To create the certificate request, I ran the New-ExchangeCertificate cmdlet with quite a few different parameters. The full cmdlet I used was similar to this:

New-ExchangeCertificate –GenerateRequest –Path c:\hubcas1.txt –SubjectName cn=hubcas1.neilhobson.com –DomainName email.neilhobson.com, hubcas1, hubcas1.neilhobson.com –IncludeAcceptedDomains –IncludeAutodiscover –PrivateKeyExportable $true

Let us now go through each parameter and discuss what it allowed me to do.

GenerateRequest: This allowed me to create a certificate request file rather than a self-signed certificate.
Path: Here I specified the file that was to contain the certificate request generated, namely c:\hubcas1.txt.
SubjectName: This parameter links the certificate with a server name and is in the style of an X.500 distinguished name. In my case, the certificate was issued to hubcas1.neilhobson.com.
DomainName: You will note that I ensured that the DomainName field contained the external access name, the NetBIOS name and the Fully Qualified Domain Name (FQDN). This means that all these names were present on the certificate.
IncludeAcceptedDomains: As I discussed earlier, I usually add this parameter to ensure that any additional domains defined as accepted domains within the Exchange 2007 configuration are added to the certificate.
IncludeAutodiscover: Like the accepted domains, I usually add this parameter to ensure that additional autodiscover domain names are added appropriately.
PrivateKeyExportable: This is useful tool to allow you to export the certificate, such as when you copy the certificate to an ISA Server.
Once I ran this command it completed and informed me of the certificate thumbprint and subject name. An example of this can be seen in Figure 26.


Figure 26: New-ExchangeCertificate Cmdlet

Running this cmdlet also created the file c:\hubcas1.txt on the Client Access Server. This is the familiar certificate request file, the contents of which will look similar to that shown in Figure 27.


Figure 27: Contents of a Certificate Request File

As I mentioned earlier, in my project, an internal Windows CA was present and was able to be used to create the certificates for the combined Hub Transport and Client Access Servers. To create the certificates I used the following process:

I first navigated to the web interface of the CA by bringing up a browser and going to http://server/certsrv. Here, ‘server’ should be replaced with the name of the server running the Windows CA. This brought up the welcome screen that you can see in Figure 28.

Figure 28: Windows CA Welcome Screen

From the welcome screen I chose the option to Request a certificate. This action brought up the Request a Certificate screen that you can see in Figure 29.

Figure 29: Windows CA Request a Certificate Screen

From the Request a Certificate screen, I chose the option to submit an advanced certificate request. This action brought up the Advanced Certificate Request screen that you can see in Figure 30.

Figure 30: Windows CA Advanced Certificate Request Screen

From the Advanced Certificate Request screen, I chose the option that starts with Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file. This action then brought up the Submit a Certificate Request or Renewal Request screen that you can see in Figure 31.

Figure 31: Windows CA Submit a Certificate Request Screen

In the Saved Request field, I pasted the contents of the certificate request file hubcas1.txt. I then made sure that the Certificate Template field was set to Web Server. The completed screen can be seen in Figure 32.

Figure 32: Windows CA Completed Submit a Certificate Request Screen

Once completed, I clicked the Submit button which resulted in the Certificate Issued screen that you can see in Figure 33. From here, I ensured that the DER encoded option was selected and then chose the Download certificate link that you can see on the same screen. I then saved the resulting certificate file, certnew.cer, locally onto the Client Access Server.

Figure 33: Windows CA Certificate Issued Screen

MS Exchange online test tool

Microsoft announced an online service for IT pros that enables them to test incoming e-mail traffic to Microsoft Exchange Server.

The tool, called Exchange Server Remote Connectivity Analyzer, was announced last week as a beta version. However, it's apparently been available as a test version since late last year.

The Microsoft Exchange team on Wednesday pointed to the availability of the beta version. The team's blog includes a video that demonstrates how the tool works, which can be accessed here.

The remote analyzer tool helps IT administrators assess server setup problems, particularly when e-mail clients located outside an organization's firewall are having problems trying to connect. While Exchange Server comes with its own test tools, those tools can only test traffic within an organization's firewall.

The Exchange Server Remote Connectivity Analyzer will test incoming e-mail traffic by simulating three client types, including Windows Mobile clients using Exchange ActiveSync, Outlook clients using Outlook Anywhere and clients that use SMTP.

You can run the tests for Windows Mobile and Outlook with autodiscovery turned either on or off.

The beta still has some usability limitations, and it requires certificates for some tests to work, according to the Exchange team blog. The team plans make those improvements in a future version, along with adding new tests for Exchange Web Services, IMAP, Outlook Web Access and POP.

The Exchange Server Remote Connectivity Analyzer tool, nicknamed "ExRCA," can be accessed for free online here.