Link to home
Start Free TrialLog in
Avatar of Roadrnnr
Roadrnnr

asked on

Activesync SSL cert not trusted after IP change

Greetings Experts,

I have SBS 2003 with activesync and it was running flawlessly for a few years untill a few days ago we changed the IP address of the server. Now everything works (exchange, OWA, BES, etc) except activesync. I did the test at testexchangeconnectivity.com and it failed on this:

 Validating certificate trust for Windows Mobile Devices
  Certificate trust validation failed
   Additional Details
  The certificate chain did not end in a trusted root. Root = CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US  
 
The ONLY thing that has changed was the IP address of the server. It's an actual bought SSL cert which must still be working because my exchange accounts are still using it. I've combed EE and tried others that have simmilar problems, I've even deleted the cert and re-installed it.

What am I missing? How can the cert be invalid now because of an IP change and only for mobile devices?
Avatar of Rob Williams
Rob Williams
Flag of Canada image

If you changed the IP address of the server did you use the wizards?
If you change the LAN IP of the server you MUST run the "Change Server IP Wizard", and then run the "Connect to the Internet Wizard. If you have a 2 NIC server and only changed the WAN IP you only need to run the "Connect to the Internet Wizard". Both are located under server management, Internet and E-mail.

If you didn't run the wizards I am surprised that is the only issue.
did you change the internal or external ip address of the server?
Avatar of Roadrnnr
Roadrnnr

ASKER

It's the external IP of the server that we changed, the server has 2 Nics in it but I'm only using 1. I had only changed the ip address in the network TCP/IP window, but I just ran the "Connect to the internet wizard" and "Change server ip address" wizard and I'm still getting the same results.

Can you guys think of anything else I can try?

Thanks

Chris
ASKER CERTIFIED SOLUTION
Avatar of ConchCrawl
ConchCrawl
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
>>"It's the external IP of the server that we changed, the server has 2 NICs in it but I'm only using 1"
To confirm:
The second NIC is disabled not just un-configured?
If you are only using 1 NIC this is an Internal IP and you are using a router correct? Or does it and your entire network use public IP's?
Perhaps it would help if you would post the results of    ipconfig  /all    for us.
I did use reverse DNS before, now were not. I'm not sure that that is needed though. MX records have all been updated.

I haven't revalidated my cert, I didn't know you could do that? I'll give them a call though.

Ip configuration is listed below. I did disable the second nic in the networking window (it's greyed out).

C:\Program Files\Windows Resource Kits\Tools>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : WOODSTOCK
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Unknown
   IP Routing Enabled. . . . . . . . : Yes
   WINS Proxy Enabled. . . . . . . . : Yes
   DNS Suffix Search List. . . . . . :

Ethernet adapter Server Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Broadcom BCM5708C NetXtreme II GigE (NDIS
 VBD Client)
   Physical Address. . . . . . . . . : 00-19-B9-F0-4C-07
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 74.14.208.199
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IP Address. . . . . . . . . . . . : 74.14.208.198
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IP Address. . . . . . . . . . . . : 74.14.208.203
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 74.14.208.1
   DNS Servers . . . . . . . . . . . : 74.14.208.203
                                       4.2.2.1
   Primary WINS Server . . . . . . . : 74.14.208.203
You are showing 3 public facing ip addresses bound to your lan nic? Is there a reason for this, could you please elaborate?
You are pointing one of your dns servers to one of those ip's on the nic, which would be correct if you are pointing it to the primary sbs server. The 4.2.2.1 doesn't really matter but also probably shouldn't be there.
Are you using forwarders in your dns and what are those ip addresses?
I'm not sure why you have three ip addresses bound to this nic, could you please elaborate?
Are you using a router that you control and have access to on your network?
There are a few websites on there that require their own IP address, not much to do with Exchange. I had 3 IP's when I was on my old IP block too and it worked without an issue.

It seems to be more related to my SSL cert which I don't understand. Is the cert bound to the IP address?
You have a very unique situation with the public facing IP's, not to say that's wrong. The issue would be more to do with the 'common name' you used on the original cert hopefully not an ip address.
So assuming you used a common name such as 'externaldomain.com' then the cert should be ok.
The difference here is that you don't have an internal address (private ip), your external and internal address are the same, so did you rerun the wizards that RobWill suggested?
You could simply run the wizard to create a request for a new csr and upload to godady an have them reissue the ssl cert, that would make sure there is no conflict. godaddy lets you do that without any cost and it's automated.
You would then download the ssl cert for iis and install both the intermiadte cert and ssl cert  on sbs as you did originally.
I'm preplexed as you are about why changing the ip address would affect your cert if nothing else changed? But as I stated earlier you do have a unique situation.
Ooooo... all kinds of conflicts could be present here. SBS is designed to be configured with the wizards and it cannot do so properly with this configuration. I appreciate it was working but SBS, a domain controller, should not be a web server because of security concerns. It is also designed to work in a specific fashion based on 1 NIC or two.
Hwever....
You should remove the 4.2.2.2 address, that should be placed in the forwarders list of DNS, not on the NIC.
I would also check the DNS management console under server properties on the interface tab and see that only 74.14.208.203
 has a check next to it.

I would also check the IP's in IIS to see that the proper cert is bound to the proper site and IP. In IIS right click on the web site and choose properties. The IP will shown on the first page (or you can select) and then check the matching certificate under directory security /view certificate. Also on the directory security page check that there are no IP restrictions.
Yeah I don't get why changing the IP broke the cert either, and just for OMA, nothing else. All the other SSL stuff works.

I did go ahead and run the "Change server IP" and "Connect to the Internet Wizard". It ended up breaking RPC over HTTP but re-adding the registry settings for that fixed it up again.

I have removed the 4.2.2.X addreses and placed them into the forwarders list, verified that .203 had a check next to it and moved the default site to .203 as well (it was "all unassigned" before). The certificate shows the FQDN of the server (no IP information) and everything on the server works, except activesync.

The only other thing I can think of is to get the server to re-generate the CSR and have the SSL company re-issue the cert?

Is there a way to run activesync without using SSL? Or is that a bad idea?

I appreciate the feedback so far.. thanks :)
in 2003 you can disable the ssl on the website, depends on your security issues. If you need help with that I can show you how to disable SSL for activesync on IIS site. The other way is just to ignore the cert on the pda.
I should've said as long as activesync isn't setup for SSL only.
For the record:
I know I said to use the wizards before, but this is not a default install. The most important thing in managing an SBS is to use the wizards, but it is very possible they are "breaking" some of your configurations such as the IIS IP associated with the NIC. I would avoid using any network related wizards at this point.
Having said that if you ever change the IP again you have to use the wizards, and changes you have just made, you will have to do again. Therefore I would carefully document any edits you are having to do because of this process.

If ever it is an option I would recommend moving the non-SBS web services to a separate physical or virtual server running 2003/2008 web server, both for security and management purposes.

As for the certificate, I think ConchCrawl is more familiar with the options especially relating to active sync. However, do the external users connect to the same FQDN or are there multiple FQDN's pointing to the same server using the different IP's. If the latter you need multiple cert's and I am not sure how you would generate those with the standard SBS tools.
Everyone connects to the same FQDN which holds the cert. The FQDN of the actual SBS server is what we use for all exchange stuff, then as for web sites they are just added to IIS.

I definately will take your advice for future rollouts as I have another server that is non SBS and is working flawlessly.

Well I got farther now. I got my SSL cert regenerated and now I'm passing that part of the connectivity test.

Now I'm failing on this:

 Attempting FolderSync command on ActiveSync session
  FolderSync command test failed
   Tell me more about this issue and how to resolve it
   Additional Details
  Exchange ActiveSync returned an HTTP 500 response.
 
Did a quick search on EE here, checked all my virtual directory permissions which all seem to be in order. Have you guys seen this one?

C.

Working!! Re-issued the SSL certificate from RapidSSL, applied it to the server and that made testexchangeconnectivity tool report a HTTP 500 error. I then followed http://support.microsoft.com/kb/817379 to turn off form-based authentication and bingo. It's back

The wierd thing is that in KB 817379 said "in SBS you MUST use /exchange-oma as your ExchangeVDir" but in fact, when I changed it to a custom virtual directory, that's when it all changed.

Very happy! Thank you for all your help!
Glad you got it working, yeah the forms based authentication is something to always checked but since you were having other problems, then those of course had to be resolved first and I didn't see your last post until now. But glad the other information helped you work out your problem.
Yeah, once I got the HTTP 500, Forms based was the second thing I checked.

I wish I could understand why changing the IP address forced me to re-generate my SSL cert.... I just don't get it.

However it works now :)
I would bet that part of their automated authentication that validates who you say you are, contains your external ip address associated with the common name.