Home » Exchange Server » Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?

Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported?

Question: can I use a wildcard SSL certificate on my Exchange 2010 server?

Answer: Yes, you can.

Often people ask me whether wildcard SSL certificates can be used with Exchange Server 2010, because they have heard that they are either unsupported, not secure, or just not recommended.

What is a wildcard SSL certificate? From Microsoft TechNet:

A wildcard certificate is designed to support a domain and multiple subdomains. For example, configuring a wildcard certificate for *.contoso.com results in a certificate that will work for mail.contoso.com, web.contoso.com, and autodiscover.contoso.com.

The attractiveness of wildcard SSL certificates is that they are usually cheaper than other types of certificates, and they make some Exchange Server configurations easier to manage.

Support for Exchange 2010 and Wildcard SSL Certificates

The support question is a relatively easy one to answer. Yes they are supported from a vendor perspective. One clue for this is that wildcard SSL certificates are an option in the Exchange 2010 new certificate wizard. Microsoft does not make a habit of including options in Exchange Server that will lead you down an unsupported path.

However they are not supported for all scenarios. For example:

  • wildcard certificates can’t be used in conjunction with OCS 2007 (eg for secure communications for UM/OWA integration)
  • wildcard certificates are not supported for older mobile devices such as Windows Mobile 5.0

Security Implications for Exchange 2010 and Wildcard SSL Certificates

The security question is also relatively easy to answer. The common assumption is that wildcard SSL certificates are less secure than other SSL certificates.

Microsoft’s own documentation even references “security implications”.

…many customers are uncomfortable with the security implications of maintaining a certificate that can be used for any sub-domain. A more secure alternative is to list each of the required domains as SANs in the certificate. By default, this approach is used when certificate requests are generated by Exchange.

Verisign/Symantec describes some of those implications here:

  • Security: If one server or sub-domain is compromised, all sub-domains may be compromised.
  • Management: If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.

However, put those concerns in the context of your Exchange organization. If you’re using a wildcard SSL certificate to secure a single, internet-facing Client Access server then the above issues do not create much concern.

On the other hand if you’re deploying a large, global Exchange organization with multiple geographic entry points for various services, or those services spread over many services, then those issues are of greater concern.


So in conclusion, yes Exchange 2010 supports wildcard SSL certificates and no they are not necessarily less secure than other certificates.

However, do your due diligence and make sure that the specific support and security scenarios that do exist will not adversely impact your own Exchange 2010 deployment.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. brian says:

    I found an issue that xp doesn’t seem to work with exchange 2010 where the cas has a wildcard installed. Have you seen this issue before also. I am stuck now on my exchange project with it and stressed.

  2. brian says:

    Hi Paul,
    When I change the msstd on the xp outlook profile to match the wildcard cert name of
    *.domain.com, I am no longer prompted for a looping outlook password prompts. However autodiscovery changes it back to webmail.domain.com so I can only log into profile only once.

    I have bought the wildcard cert and regret now that I didn’t buy a san cert instead but my employer would not be too forgiving.

    Is there anyway that you can think offhand that I could get windows xp to work with a wildcard cert. and not to use msstd credentials,
    I think for internal users it shouldn’t be using msstd at all, but not sure how to get around that.
    Any advice would be greatly greatly appreciated.

    • Preston Cole says:

      Hi Brian

      I’m in the same boat with Exch 2013 and a wildcard cert with XP clients.
      Did you manage to get a resolution to your problem?

      Hope to hear from you.


  3. Brian says:

    Hi Preston,
    In the end we got around by buying a cert with the server name in it, as xp won’t work with wildcard certs.
    All is working fine now. We are getting rid of xp so we can then use our wildcard cert then.

    • Preston Cole says:

      I thought that might be the case. I’m trying to get mine switched with my cert provider (wish me luck!).

      Thaks for getting back to me Brian.

  4. Dave Roberts says:

    Hi there!

    I’m having an issue with my new wildcard cert. I have a single internet-facing CAS server, but I’m getting errors about the FQDN when I attempt to assign the SSL cert for all services (POP and IMAP return errors). When I try to manually set the FQDN using Exchange Mgmt shell, I get an error “the command completed successfully but no settings of ‘1’ have been modified.” What am I missing?

    Thanks for your help!

  5. Paul Reed says:

    is there any difference to exchange 2013 between a Multi-domain SSL certificate and a UCC certificate? the UCC certificate is about $50 more than the Multi-Domain SSL certificate

  6. Fernando says:

    Hi Paul.
    One of my customers is using a certificate for POP3/IMAP services which has expired 2 days ago. Such certificate is intended for IMAP, POP and SMTP services. Exchange 2010 server has another certificate (a wildcard one) and assigned to IIS and SMTP services.

    I’d like to use the wildcard cert for all the services but when trying to assign it to POP and IMAP services I got the following warning:

    Enable-ExchangeCertificate -Thumbprint … -Services POP,IMAP,SMTP,IIS

    WARNING: This certificate with thumbprint … and subject ‘*.domain.com’ cannot used for POP SSL/TLS connections because the subject is not a Fully Qualified Domain Name (FQDN). Use command Set-POPSettings to set X509CertificateName to the FQDN of the service.
    WARNING: This certificate with thumbprint … and subject ‘*.domain.com’ cannot used for IMAP SSL/TLS connections because the subject is not a Fully Qualified Domain Name (FQDN). Use command Set-IMAPSettings to set X509CertificateName to the FQDN of the service.

    Is there a way for forcing this certificate to use all the services?


    • If you read that warning message it is explaining the solution to you. Wildcards are enabled for POP or IMAP by using Set-POPSettings or Set-IMAPSettings, not Enable-ExchangeCertificate.

  7. Cody says:

    You should really use a Unified Communications Certificate (UCC) for Exchange IMO. I’ve run into a lot of comparability issues in the past with certain scenarios using a wildcard cert with Exchange.

    Just because you can use something doesn’t mean you should.

    GoDaddy sells UC certs that can include up to 100 domain names. It does get expensive, but I use this as leverage for keeping/routing email for new domains. It puts that extra check in place when it costs money.

    A good example of a scenario where a wildcard cert will not help you – you have to route email for multiple domains, not sub-domains. Say the company you work for likes to grow by acquisition – you keep getting new domains to route email for. Those are new domains, not new sub-domains. You need a UCC/SAN, not a wildcard cert. (autodiscover.domain1.com, autodiscover.domain2.com, etc)

Leave a Reply

Your email address will not be published. Required fields are marked *