Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

previously we have requested a wildcard ssl certificate from godaddy for our major domain. one of the reasons was the new established exchange server 2010. usually you require following names included in certificiate:

  • FQDN (e.g. mail.whatever.com)
  • Hostname (mail)
  • Domain name (whatever.com)
  • Autodiscover.whatever.com
  • MX Record

with the wildcard certificate these are all covered (except of the local hostname). During creation/importing of the ssl certificate into exchange 2010, exchange first asks, if a wildcard certificate is used and then encounters an error -> due to the certificate is a wildcard certificate and not a certificate especially generated for the FQDN, SSL for POP and IMAP can not be provided.

couldn't find any workaround or solution for this on google, so I hope, maybe some one here has an answer or solution for me! :)

the exchange 2010 is running on a windows server 2008 R2 enterprise.

thanks in advance and best regards, sise

share|improve this question
add comment

4 Answers

up vote 1 down vote accepted

Unfortunately, your best option is to get a UC cert, which means ditching the wildcard and purchasing a new one entirely. See my answer HERE for a similar question.

share|improve this answer
1  
It appears that it is possible to use a wildcard cert with the POP3/IMAP4 services despite the warnings. joshperry's reference to KB948896 led me to the answer. Even though I was getting a warning when attempting to assign the certificate to POP3/IMAP4, it will still use the wildcard certificate that matches the FQDN defined for the service. So set the FQDN to mail.example.com and it will use the cert with subject *.example.com. –  Jason R. Coombs Apr 19 '10 at 3:37
add comment

Boo, UC certs are a bigger ripoff than normal certificates and only needed mainly because of NAT. When IPv6 becomes widely used and all computers have one-true-address these will be mostly moot as your server won't need to resolve to a different address inside and outside the firewall.

This can be quite easily be handled if you are using a two-faced DNS system that for the same hostname serves private (RFC1918) addresses to internal users and the server's public address to external users. For example mail.example.com from your internal servers returns 10.0.0.11 and from an external server it returns 208.65.70.82. So when connecting to your server internally you would still use mail.example.com.

Take a look at Microsoft KB Article 940726 which explains how to change the internal url for all of the exchange services to be the same as the external URL. It specifically cites this "workaround" for people that "cannot" use a certificate that supports Subject Alternative Names. To be honest I think that this configuration will become default in the next one or two versions of Exchange as IPv6 becomes common place.

We have also found this is really great for mobile users because mail.example.com will resolve to the same server inside the firewall as it does outside, especially nice when they're using a protocol like IMAP with a client that doesn't support "Outlook Anywhere".

For your POP/IMAP issues take a look at Microsoft KB Article 948896. Basically you just set the X509CertificateName to the FQDN that users will be accessing the service from (with Set-ImapSettings -X509CertificateName mail.example.com or through the GUI) and don't specifically assign the certificate to the IMAP service using Enable-ExchangeCertificate command.

share|improve this answer
add comment

you can indeed use a wildcard for imap and pop. rtfm here: http://technet.microsoft.com/en-us/library/aa997231.aspx

:)

share|improve this answer
add comment

Be aware you can use wildcards within Unified Communications (UC or SANS) certificates so you have a lot of options and versatility. I've seen a number of posts where people are having issues getting POP and SMTP to work with wildcard on Exchange. So perhaps using a wildcard within the UC certificate is a good compromise.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.