Get wild with wildcard certificates

Most organizations that are considering securing their email systems are also looking at SSL certificates to aid in that effort.  Security certificates allow for encrypted communications using Outlook Web Access, Outlook Anywhere (RPC over HTTPS) and ActiveSync devices like Windows Mobile Smartphones. The issue is that a normal SSL certificate is bound to a single server, which means you'd have to obtain a signed certificate from a provider for each server you want to put into the solution.

You could use self-signed certificates to get around the issue of having to purchase individual certificates, but only at a cost.  Many applications will not accept self-signed certificates, and even Microsoft-controlled systems like OWA will kick up several layers of security errors - which will increase support headaches for you and your staff.

Alternately, you can obtain a Wildcard Certificate from a provider, which will allow you to use one certificate for multiple servers in your organization.  These certificates are more expensive than single-server options, but can give you much more flexibility with things like server rebuilds, migrations, and failover.  The only restriction is that the servers will have to be part of the same organization. That means that all the servers will have to be part of the same domain and/or forest in the sense of Active Directory.

Wildcard certificates can be defined at either the organizational level - such as *.wildcarddomain.com - or masked at another level, www*.wildcarddomain.com for example.  With the first example, all server identities that are part of wilddcarddomain.com will be able to share the certificate.  In the second, www1, www2 and even wwweb.wildcarddomain.com will be able to share the masked certificate.  Which you use will depend on the depth of security you are looking to implement, as more specific masks allow for less chance of someone spoofing the certificate for a foreign machine.

Once you install the wildcard certificates, you can allow services to move between servers within the same organization without breaking security. This can be extremely helpful for both migrations and disaster recovery, as you can have both of the servers shielded under the same certificate, and therefore you will not get naming errors when the users move or fail over. 

In a worst-case scenario, you can use single-server certificates on a migration or failover target, but your end users will get errors about the certificate being valid, but assigned to a different server name than the one they are connecting to.  You can then purchase another certificate after the fact and assign it to the target server to remove the error if/when needed.  However, wildcard certificates give a much better option for flexibility to you and your team.