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.
Summary
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.
I have a 2010 sp3 and 2016 environment that is also going forward getting a hybrid connection with O365 indefinitely. I have cert renewals coming up and I asked MS if they have any problems with wildcards and they said no.
My question is. A SAN cert seems to be the best way to go for this company because they acquire companies slowly. The one they just acquired is already on O365 and I am debating moving them down to 2016 and then back to the new tenant we are moving some users to soon after the connections are made and tested.
We use proofpoint as part of the solutions. I have seen some companies use the certs within the F5 in such a manner as to off load that work and came Exchange safe and clean with less over head.
I would think that applying the SAN certs in proofpoint/F5 would be my best choice then using self signed certs or wildcard certs within the local domain.
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)
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?
Thanks.
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.
Hi,
This might be a bit old now but I noticed a couple of people mentioning that wildcard’s didn’t seem to work with XP clients. This effects Exchange 2013 as well so thought it would be worth leaving a reply.
To get a wildcard to work with Outlook on XP/Server 2003 clients you have to correct the Outlook Providers CertPrincipalName to stop autodiscover giving out the Outlook Anywhere FQDN rather than the correct msstd:*.domainname.com name. I have come across this a couple of times and evidently so have others so I blogged it, hope you don’t mind me leaving a link.
http://www.stopdoingitwrong.co.uk/exchange-2013-wildcard-there-is-a-problem-with-the-proxy-servers-security-certificate/
Thanks for the great posts.
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
It depends on the provider. Some providers use different marketing terms for basically the same thing. Do a side by side comparison of the features each one claims to have, and go from there.
Hi Paul,
I have setup a single Exchange 2013 server with all the services on it. As I cannot assign the wildcard certificate in the ecp to POP and IMAP, I am using Set-POPSettings command to do it but I get the following error:
Cannot process argument transformation on parameter ‘AuthenticatedConnectionTimeout’. Cannot convert value “certificateID” to type “Microsoft.Exchange.Data.EnhancedTimeSpan”. Error: “String was not recognized as a valid TimeSpan.”
I will appreciate if you can provide a solution to this as I could not find it anywhere else.
Is it still possible to use a Wildcard certificate with Exchange 2013 otherwise can I get multiple standard certificates for each of the domains to save money?
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!
It would probably help if you told me what errors you’re getting when you try to assign the certificate.
has anything changed for exchange 2013?
Wildcards are still supported in Exchange 2013.
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.
Brian
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.
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.
Thanks
Brian
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.
Preston
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.
Thanks
What indicates to you that its the wildcard that is the issue?
And why not just use a SAN certificate anyway?
And how did you make it work with Exchange 2010? It dosent seems to work, saying that the FQDN dosent match since it’s *.contoso.com instant of exchange.contoso.com.
Pingback: » Suporte à certificados wildcard