Dunavant
asked on
OWA over SSL - Not working outside the LAN
Hello,
I have been struggling with this issue for too long and guess I have to admit : I need assistance ! :-P
I need to set-up OWA for remote users to acces their corporate mail.
It works just fine ovet regular HTTP, but after some reading I discovered that this is actualls quite bad (no encryption...)
So I decided to switch to HTTPS, and issued my own certificate as per described here: http://www.msexchange.org/tutorials/Securing-Exchange-Server-2003-Outlook-Web-Access-Chapter5.html
It is working very fine from inside the network (LAN), both HTTP and HTTPS.
But when tested from outside our FW, only HTTP works.
- When reaching HTTPS URL, IE gives a "Page cannot be displayed"
- When tested with Firefox, it says that the connection attmp has been dropped.
I have a linux box sitting outside our LAN "just in case", so the first thin I did was test the opened port on the FW for my IP:
80/tcp open http
135/tcp open msrpc
443/tcp open https
Looks quite ok for me.
Then I thought it could be a problem with the certificate, so I ran (from outside box) a openssl to see what happens.
openssl s_client -bugs -connect MY.IP.ADD.RESS:443
CONNECTED(00000003)
3827:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
and this is where I stand...
Any hint ?!? Seems to be an SSL problem, and I really am a newbie for that...
Thanks !
I have been struggling with this issue for too long and guess I have to admit : I need assistance ! :-P
I need to set-up OWA for remote users to acces their corporate mail.
It works just fine ovet regular HTTP, but after some reading I discovered that this is actualls quite bad (no encryption...)
So I decided to switch to HTTPS, and issued my own certificate as per described here: http://www.msexchange.org/tutorials/Securing-Exchange-Server-2003-Outlook-Web-Access-Chapter5.html
It is working very fine from inside the network (LAN), both HTTP and HTTPS.
But when tested from outside our FW, only HTTP works.
- When reaching HTTPS URL, IE gives a "Page cannot be displayed"
- When tested with Firefox, it says that the connection attmp has been dropped.
I have a linux box sitting outside our LAN "just in case", so the first thin I did was test the opened port on the FW for my IP:
80/tcp open http
135/tcp open msrpc
443/tcp open https
Looks quite ok for me.
Then I thought it could be a problem with the certificate, so I ran (from outside box) a openssl to see what happens.
openssl s_client -bugs -connect MY.IP.ADD.RESS:443
CONNECTED(00000003)
3827:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
and this is where I stand...
Any hint ?!? Seems to be an SSL problem, and I really am a newbie for that...
Thanks !
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I don't know if it is a pre-requisite, but I have no sites running SSL without FBA (SSL is a pre-requisite of FBA)
Confused yet? I am :)
If you are enabling SSL, you may as well enable FBA - it is a much prettier experience.
Which reminds me, you haven't ticked "Require SSL" on any IIS sites have you?
-red
Confused yet? I am :)
If you are enabling SSL, you may as well enable FBA - it is a much prettier experience.
Which reminds me, you haven't ticked "Require SSL" on any IIS sites have you?
-red
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ok, so I tried to install a rapidssl FreeSSL certificate, just to gove it a go.
No changes, still same error...
As far as IIS log are concerned, it seems to me the HTTPS reaches it.
copy past a sample below :
2006-11-17 13:45:25 172.17.6.121 SUBSCRIBE /exchange/ssladmin/Calenda
So 443 -> status 200, thus seems ok...
Any idea, I am sinking here... :(
No changes, still same error...
As far as IIS log are concerned, it seems to me the HTTPS reaches it.
copy past a sample below :
2006-11-17 13:45:25 172.17.6.121 SUBSCRIBE /exchange/ssladmin/Calenda
So 443 -> status 200, thus seems ok...
Any idea, I am sinking here... :(
ok, if you're sure that's your test that came from the outside...
so what does this traffic have to travel through to get back to the client? firewall? what kind?
is there a single exchange server involved here? or is this a FE/BE scenario?
kris.
so what does this traffic have to travel through to get back to the client? firewall? what kind?
is there a single exchange server involved here? or is this a FE/BE scenario?
kris.
ASKER
Yop, the traffic goes through a Firewall, a Symantec Security gateway 5000.
Set-Up is like this :
Internet <-> SGS (FW) <-> Exchange Server
Only one Exchengeserver involved here.
An idea : could it be some kind of IP address being masked / replaced by the FW and thus the certificate failing to be validated from the client machine outside the LAN ?!?
Set-Up is like this :
Internet <-> SGS (FW) <-> Exchange Server
Only one Exchengeserver involved here.
An idea : could it be some kind of IP address being masked / replaced by the FW and thus the certificate failing to be validated from the client machine outside the LAN ?!?
ok, so with a single server you actually will not want FBA at this point, it will just create more complications. You have 'integrated auth' enabled on the Exchange server, right?
have you enabled verbose logging on the device?
kris.
have you enabled verbose logging on the device?
kris.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
OK, I think I spotted the problem.
I "sniffed" my FW (Symantec Security Gateway 5000), and it seems that after the initial handshake, the IIS server is is assigning a custom port n° (from open range) to the transaction to be effected on.
It is this port that is then blocked, thus making the SSL connection fail.
I don't really want to open the whole connection of my mail sevrer to the wild, so still to figure out:
1) Is there a specific ranged used by IIS for that post-handshake connection ?
2) If not, can I block IIS onto one specific custom port ?!?
I "sniffed" my FW (Symantec Security Gateway 5000), and it seems that after the initial handshake, the IIS server is is assigning a custom port n° (from open range) to the transaction to be effected on.
It is this port that is then blocked, thus making the SSL connection fail.
I don't really want to open the whole connection of my mail sevrer to the wild, so still to figure out:
1) Is there a specific ranged used by IIS for that post-handshake connection ?
2) If not, can I block IIS onto one specific custom port ?!?
ASKER
Ok, I just closed the question as I will open a new one.
I figured out the problem was on the FW and wil focus on that.
Splitted the point according to the help given, let me know if you think I was unfair.
Cheer !
I figured out the problem was on the FW and wil focus on that.
Splitted the point according to the help given, let me know if you think I was unfair.
Cheer !
ASKER
Is it a prerequisite for using OWA over https ?!?
(Will try that in a minute anyway)