|
Posted by Ryan Hardin on February 9, 2006, 3:03 am
Please log in for more thread options Paul,
I'm glad you found my post helpful. My desire to synch successfully 100% of
the time became very frustrating. ASync would work for about 2 hours, then
quit for 2 hours, the start again for 2 hours...sometimes longer. Off and
on. And when it didn't work, the Application Log on our server would be
filled with those ActiveSync 3005: HTTP 400 errors...then they would
disappear. On my phone, the error was 85010014, and after seeing that number
many times, memorization of that number so I could google the Internet for
new insight of the problem was a breeze. But still, no one seemed to have a
solution other than what was already in the MSKB, which is still lacking any
type of resolution. It basically all comes down to the basics of DNS, how
SSL technology works, and how having multiple IPs on your server (and
subsequently DNS) can jack things up for accurate synching. I'm still
ecstatic as to my solution. EVERY SINGLE SYNC has been successful since my
change. No 85010014 errors or 3005 errors in the Application Log.
The intervals described above led me to think that some type of caching was
involved, so I then checked out our DNS server. Apparently each IP on the
server was entered into our internal DNS server. And from what I understand,
Exchange ActiveSyncing requires the server to "find itself" internally (from
the HTTP 400 errors that were generated) so it can grab the data from the
Exchange system and then send it back out via HTTP(s) to the phone. In doing
a query on itself, it was using the FQDN of its own machine name + windows
domain name - server.contoso.local. Since DNS had multiple host record (A)
entries for [server] in the contoso.local zone, and our Default Website could
only properly respond to ONE IP address (because of how SSL technology
works), problems would occur when the DNS cache would resolve itself to an IP
address that was not the correct IP address for SSL requests.
Maybe that helps clear up my post a bit.
On your situation (as mine) with 2 SSL certs on the box...
Basically you need the following for it to work:
1) Two SSL certs entered into IIS, one for each website
2) Two IP addresses on the box (either on multiple NICs or a single NIC,
doesn't matter)
3) In IIS, you must specify different IP addresses for the host headers used
for each website.
The reason for this is because SSL traffic actually encrypts the host
headers, so the only way for IIS to know which website to route website
requests to is via the IP address information in each packet that surrounds
the SSL encryption.
To explain logically...
Basically on the network level, all traffic is destined for an IP address
and a port. We all know that. And we all know that for web traffic, the
port number is 80. And we all know that you can only have a single
application respond to the same IP address and port. So how does IIS allow
multiple websites? Simple: Host Headers.
If there are multiple websites in IIS, each responding to (All Unassigned)
IP address and port 80, IIS reads and uses host header information at the
application layer to know where to route website traffic to the correct
website. This is how host headers work, and the host header information is
carried in the application layer, which is inside the network routing and
port data (that is, inside the destination IP address and inside the
destination port in the data packet).
If you were to map out the TCP traffic data, it would look something like
this:
--> {start packet 1} [ destination IP address ] + [ destination port ] + [
application data (host header + http get + blahblahblah) ] {end packet 1}
--> {start packet 2} [ destination IP address ] + [ destination port ] + [
application data (host header + http get + blahblahblah) ] {end packet 2} -->
However, when using SSL and port 443, the application layer is encrypted.
If it is not, then it defeats the purpose of the Secure in SecureSocketsLayer
(SSL). This encryption of the application layer also includes the encryption
of the host header information. More importantly, this data destined for a
secure website can only be decrypted by the website in IIS that holds the SSL
certificate assigned TO the secure website. This is how SSL certs work.
So, let's state our scenario again, this time using SSL and port 443 instead
of port 80:
If there are multiple websites in IIS, each responding to (All Unassigned)
and port 80, IIS then reads the host header information and then reroutes the
traffic to the correct website. But wait, how can IIS read the host header
information if it is encrypted? It can't. This is a limitation on all web
servers that I am aware of, and it really isn't a limitation. It is how the
protocol is designed for the appliation and security of the protocol. Also,
IIS (or other web servers) are not smart enough to know which SSL cert to use
in order to decrypt the host header information, and therefore, it cannot
route the traffic using the host headers to the correct website.
So the solution?
In IIS on each website that uses in SSL certificate, you must specify the IP
address to which the website in IIS is to respond. That is, instead of using
(All Unassigned) on your SSL websites, specify the IP address to which the
domain name on the SSL certificate resolves. Using this method, IIS will see
the traffic and say "OK. You have this IP. Go here. This website over here is
supposed to respond to you." This basically circumvents the need to read the
encrypted host header in order to send it to the right website. The IP
address specified allows it to be sent to the correct website, without using
host headers. So if IIS simply sends the traffic to the website that
specifically responds to an IP address, it can then use the Cert to decrypt
the data, and now you're rockin'.
Basically, if IIS has multiple websites responding to the same IP and port,
it uses Host Headers. Since Host Headers are encrypted by SSL, having
multiple SSL websites requires the use of different IP addresses.
This is something that Microsoft should consider in their next version of
IIS:
If there are multiple SSL certs on multiple websites in IIS, when a website
request arrives on the machine, IIS should query all SSL certificates stored
on the websites. IIS should continue down this list trying to decrypt the
application data until it can find a match of an unencrypted host header with
a host header that is listed on a website stored in IIS. If this were the
case, multiple SSL certs in IIS would not require you to have an IP address
for each cert. I'm not sure what security risks are imposed, but this seems
like a logical thing to me.
All the best,
- Ryan Hardin, CCNA, MCSE (MCP ID No: 2529921 - that's for you, Microsoft.
Hook a brother up.)
"Paul Schwartz" wrote:
> Ryan,
>
> Thanks for taking the time to write this. I'd only been banging my head for
> a few hours on my dual-homed test box before I found your post. To ensure
> that my test environment worked at all I took out the second IP and my
> device synched.... now I need to figure out how to have the device work with
> 2 IPs like you've described, since I do in fact have 2 certs on the box.
>
> Paul
>
> > Problem: Sometimes Exchange ActiveSync works. Sometimes it doesn't. When
> > it
> > doesn't, the problem was always "problem with the server - x85010014".
> >
> > After a month of reading KB articles with no credit to M$ as to my
> > situation, I think I have fixed the 85010014 errors on my WM5.0 SmartPhone
> > Exchange ActiveSync.
> >
> > A mockup of my setup (I'm hiding my info):
> > Network Environment:
> > Windows Server Name (FQDN): server.contoso.local
> > Public Internet Domain Name (for OMA, OWA, RPC-HTTP, ExchAS, etc):
> > secure.contoso.com
> >
> > System Environment:
> > - Exchange 2003 SP2
> > - Enabled FBA OWA (we use Public SSL cert from Thawte for
> > secure.contoso.com)
> > - Created additional Exchange Virtual Directory: /ExchDAV (see KB 817379)
> > - Modified registry to have SMTPProxy value for SMTP domain of our default
> > Recipient Policy in ESM: contoso.local (see KB 886346)
> > - In Active Directory, we have multiple SMTP addresses for users, with the
> > Primary SMTP address being firstname.lastname@contoso.com.
> >
> > The problem seems to revolve around DNS name resolution. Our specific
> > error
> > in the Exchange Server's Event Log is as follows:
> > Event ID: 3005
> > Source: Server ActiveSync
> > Unexpected Exchange mailbox Server error: Server: [server.contoso.local]
> > User: [firstname.lastname@contoso.com] HTTP status code: [400]. Verify
> > that
> > the Exchange mailbox Server is working correctly.
> >
> > In IIS, I have the following host headers on the Default Website, which
> > contains the /exchange et al. virtual directories.
> > - A blank host header with port 80. (you MUST leave this one - do not
> > delete)
> > - A host header for secure.contoso.com for port 80.
> > - SSL host header using port 443 with our SSL cert.
> >
> > Note: This probably doesn't apply to anyone many out there, but we have
> > two
> > SSL certs on this machine. So we specify the IP for our Cert here on the
> > Host Headers instead of (All Unassigned). This is a great trick to allow
> > multiple SSL certs and secure websites on your server. Each website in
> > IIS
> > must explicitly have the IP address on the host header values instead of
> > (All
> > Unassigned).
> >
> > We also have multiple IPs on our server, so it is multihomed.
> > Let's say:
> > 1.1.1.1 - this is specific to our Default Website in IIS
> > (secure.contoso.com
> > resolved here on the Internet)
> > 1.1.1.2 - this is specific to our 2nd SSL Website in IIS
> > (somethingelse.msft.com goes here)
> > 192.168.1.1 - private IP of machine for LAN/VPN sitting inside firewall
> > (we
> > use PAT for ports 80 and 443 to point to this machine)
> >
> > On our Internal DNS Server on our network, there are multiple entries for
> > the SERVER hostname, one for each IP above.
> > server.contoso.local - 1.1.1.1
> > server.contoso.local - 1.1.1.2
> > server.contoso.local - 192.168.1.1
> >
> > This is where the problem lies. We need to consistently and accurately
> > resolve SERVER.CONTOSO.LOCAL to 1.1.1.1, as seen in event log entry.
> > Remember, this is because the Default Website answers to this IP and will
> > not
> > answer to (All Unassigned). We tried removing the DNS host record, but it
> > would always be regenerated by the server (even after changing the TCP/IP
> > DNS
> > properties to not register its address in DNS.
> >
> > So if you have a multihomed server, using private and public IPs on the
> > machine, or even using two IPs on the same NIC, (or oddly have multiple
> > SSL
> > certs on your machine) you may want to try our workaround.
> >
> > Our workaround: The good 'ole /system32/drivers/etc/hosts file.
> > I created an entry for SERVER.CONTOSO.LOCAL to be the IP 1.1.1.1, and my
> > Smartphone started synching right away.
> >
> > So there's my contribution to the Internet community :)
> > Cheers,
> > Ryan Hardin, CCNA, MCSE
>
>
>
| 
XML Sitemap