SSL and Mobile Devices

[1DMF]

Hello,

I'm confused by how we set up mobile devices iPhone/MD5/MD6 with our server.

I asked our web host if we could use our SSL certificate for this and they said 'No' as the exchange and web were not on the same box so could not be used for OWA.

This raises two issue for me...

1. Why would the SSL certificate be registered to a box (or IP) address and not our domain name.

2. What's mobile devices got to do with OWA, OWA already works fine with its own self signed certificate, ok you have to click the warning to continue , but it's running fine over SSL.

Can some explain exactly what it is I need and how I apply it to the server to enable secure conectivity of mobile phones with MS Exchange compatibility.

I thought OWA (outlook web access) and OMA (outlook mobile access) were two different things?

Thanks,

1DMF.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[ShackDaddy]

Certs are attached to a HOSTNAME, not a domain name or an IP address. So a cert that's used for

http://www.domain.com

will not work for jimmyeatsfrys.domain.com.

OWA uses a self-signed cert if you haven't purchased a 3rd party one, and apart from the warning you get when you go to a site with an untrusted cert, it works fine. You can use your existing self-signed cert with Exchange ActiveSync & OMA if you are willing to import your self-signed cert to each device that you will be connecting with. To summarize, OWA is more tolerant of self-signed certs and you just have to click once to get what you are after. OMA and Exchange ActiveSync are much less tolerant and require local installation of untrusted certs.

I prefer to spend $20 on a GoDaddy cert instead of wasting a lot of time loading certs on devices and having to reimport them when users replace their phones.

Get a cert with the same name you use for OWA on it, so if your OWA address is mail.domain.com, get a cert for mail.domain.com. Just get the cheapest cert GoDaddy has to offer.

To submit the cert request at GoDaddy, you will need to generate one on your server. The easiest way is to just create a new test website in the IIS, go into Properties on it, Security, and then into SSL/Encryption/Cert area and generate a new cert request. Use your organization name but don't use any punctuation in it. Then put "Technology" or something like that into the division/department area. Otherwise choose the defaults. This will create a text file, and you can past the contents of that text file into a field that GoDaddy will provide for you on their site. Once the cert request goes through (GoDaddy will ask permission from the person who registered your site's domain name before releasing the cert), you will get email instructions on how to install the cert. Go ahead and install it in the test site you created.

Once it's there, you can delete the test site and go to your Default web site and change the cert that's there from the self-signed to the GoDaddy one. Once that's in place, your OWA users won't get warnings and you will be able to use Exchange ActiveSync and RPC-over-HTTPS pretty easily.

Dave Shackelford
Shackelford Consulting

 

[1DMF]

Thanks Dave,

So a cetificate is locked to a FQDN, gotcha!

I do have a DNS record set up to point to our Web Server (not the SBS box), which I 302 redirect to our internal SBS machine running Exchange, how will this mess with the mobile devices as the final URL is specifically...

my.ip.addy/exchange

So should I actually be buying a certificate for our IP address?

Also if I point the HOSTNAME to ip.of.sbs.box/exchange is that the same location the mobile devices should be sent to?

If not then how can I use the same certificate for both OWA & OMA if the final destinations are not the same?

As you can probably tell, still a little confused over what to set the SSL certificate in the name of.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[ShackDaddy]

Frak! You made things complicated.

I would not do what you are doing. You don't want to create a cert for an IP address because no 3rd party will give you that cert unless your organization is the registered owner of that IP block in the RIPE database. If your org owns it, great, you could go that route.

What's so hard about creating a new hostname for your SBS server to own, and having your web server redirect to that FQDN if users are stuck on going to

http://www.domain.com

right now? Is it some "security through obscurity" concern?

Dave Shackelford
Shackelford Consulting

 

[1DMF]

Well yes, I do like the thought of 'security by obscurity' thought I know this is more a conceptual security rather then a reality one.

But @the end of the day our SBS is located on a 'Private' IP addy.

We have a completely seperate dedicated server hosted by a 3rd party for all our web hosting requirements.

So going to

http://www.domain.com

would never reach our SBS box or the IP it sits on, nor would we ever want it to!

Now I used to get users who wanted to access OWA to go to ip.addy/exchange but they kept forgetting the IP address , so I simply set up a conical DNS record for owa.domain.com which reroutes to our IP.addy/exchange.

does that make more sense?

So the question remains, what domain / hostname do I buy the SSL certificate for?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[ShackDaddy]

Am I missing something here? I understand how you currently have things arranged... but if you can go to "ip.addy/exchange" (and I assume that's a public IP) then you can also create a dns record for that IP, and get a cert for it.

Your SBS box may have a private IP, but some public IP somewhere routes 443 to your SBS box, or it doesn't work. That public IP can have an additional A-record associated with it, and away you go. You've made it clear that your web server and SBS box are reached through separate public IP's...yes?

Dave Shackelford
Shackelford Consulting

 

[1DMF]

It's not you that's probably missing something, it's me!

We've paid £80.00 and an engineer is going to buy and set up it all for us, sometimes it's easier and simpler to just get in someone who knows what they are doing and understands all the terminology.

Thanks for your time.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!