Personally I use comodo I tried godaddy - its not trusted properly by default on android devices so you need to install the chain? certificates on them before it will let you pass through without trust warnings. Not worth it for the end user. Thats a problem with the cheaper providers. You really need one of the recognised brand names so the chain is pre-installed in windows/android/ios and already trusted.
So I just went with a comodo certificate for about $80 through www.namecheap.com
GoodSync. Easily back up and sync your files with GoodSync. Simple and secure file backup and synchronisation software will ensure that your files are never lost (affiliate link).
raytaylor: Personally I use comodo I tried godaddy - its not trusted properly by default on android devices so you need to install the chain? certificates on them before it will let you pass through without trust warnings. Not worth it for the end user. Thats a problem with the cheaper providers. You really need one of the recognised brand names so the chain is pre-installed in windows/android/ios and already trusted.
So I just went with a comodo certificate for about $80 through www.namecheap.com
Are you sure you didn't forget to send the chain certificate from your webserver? StartSSL has the same "problem", the certificate you get isn't trusted, but you configure your webserver to also send the chained certificate along with it and it works fine.
raytaylor: Personally I use comodo I tried godaddy - its not trusted properly by default on android devices so you need to install the chain? certificates on them before it will let you pass through without trust warnings. Not worth it for the end user. Thats a problem with the cheaper providers. You really need one of the recognised brand names so the chain is pre-installed in windows/android/ios and already trusted.
So I just went with a comodo certificate for about $80 through www.namecheap.com
GoDaddy Intermediate Certs are not part of the default Java keystore (their roots are). As has been said you need to send the chain, not just the server certificate when you use them.
On a Netscaler this means adding the intermediate certs and linking them.
On most other appliances it means uploading a pfx with all certificates in the chain.
Realistically 99.9% of users don't even look at who issued the certificate. If you are protecting financial transactions I would go with a legit SSL provider with a long track history that you can call, not just email.
For OWA for a SME, who really cares as long as it works.
For Outlook Anywhere.. This is what MS has to say https://support.microsoft.com/en-us/kb/929395
ie a UC/SAN cert is needed.
But looking at servers with basic Digicert/Thwate IIS certs installed, Outlook Anywhere still works OK. Thats all Im concerned with, Outlook Anywhere.
So I guess there is no straight answer as to what cert is ACTUALLY needed Its almost as if cert sellers went out of their way to confuse & confuddle, perhaps to make price comparisons near impossible ?
1101: For Outlook Anywhere.. This is what MS has to say https://support.microsoft.com/en-us/kb/929395
ie a UC/SAN cert is needed.
But looking at servers with basic Digicert/Thwate IIS certs installed, Outlook Anywhere still works OK. Thats all Im concerned with, Outlook Anywhere.
So I guess there is no straight answer as to what cert is ACTUALLY needed Its almost as if cert sellers went out of their way to confuse & confuddle, perhaps to make price comparisons near impossible ?
Exchange can be complicated. Which SSL certs are you talking about and where are they installed?
Outlook Anywhere will use the ExternalURL to connect - this could be webmail.bob.com - if you have that SSL cert installed that might work.
But you also want to have autodiscovery work, so you need autodiscover.bob.com (or an SRV record).
You then also need your internal names to work for internal clients/cas servers to communicate with each other - so cas01.bob.com, cas02.bob.com, and even more names if your internal and external DNS are split. It is also good practice for your InternalURL and ExternalURL to be different and the InternalURL to not be resolvable externally.
If you have external load balancers you can have a single SSL cert for webmail.bob.com, then have all the internal stuff on internally issued certs.
Our Exchange cert has 10 SANs - as we need it to provide connectivity across 2 physical sites and 3 domains.
In short - if you are clever you can make it work (with some issues) without a SAN certificate - but the proper way to do it is to use one.
1. Get a UCC SSL cert. 2. Register it for mail.yourdomain.com (or whatever your external fqdn is) 3. Register SANs for autodiscover.yourdomain.com If your internal domain is externally invalid (ie yourdomain.local etc) then you need to configure your exchange to use external fqdns for all server communication (ie pointing everything at mail.yourdomain.com). You then need to configure a split dns inside your network so that internally your devices resolve mail.yourdomain.com to your internal ip address (ie 192.168.1.15). You external dns will point mail.yourdomain.com to its external ip address (ie 103.83.99.95). If your internal domain is externally valid (ie internal.yourdomain.com) then you register the internal servers as additional SANs (ie cas01.internal.yourdomain.com).
I might still have the powershell scripts for both methods which ill see if i can dig out (they go through and change all the internal and external fqdns on the exchange server).
PS. I use godaddy and they work perfectly (you need to import the intermediate cert onto the web server). No issues what so ever in the last 6 years
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
Trusted
