• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 856
  • Last Modified:

Exchange 2007 OWA gives 'Choose a digital Cert' internaly.

I have a single server Server 2008, Exchange 2007 combination.
I have a SAN cert installed and bound.

The cert. is issued to
 
exserv.external.com

and the SAN entries

intserv.int.local
exserv.external.com

in that order.

External requests to https://exserv.external.com/owa , Blackberry bis , and external Outlook rpc over http all work fine, but internal requests to https://intserv.int.local/owa produce a 'Choose a digital certificate' window with this in it:
The website you want to view requests identification.
Please choose a certificate.
followed by a blank list.  Canceling this allows entry to the site, and the cert is valid.
Connecting to https://intserv.int.local goes direct to the IIS home page, no certificate request.

Also laptops inside the building that are setup with an rpc/http proxy connect using TCP/IP not HTTPS  after a medium pause while it tries.

Any ideas what setting in exchange/IIS i have wrong?

P.
0
petesulli
Asked:
petesulli
  • 6
  • 4
  • 3
4 Solutions
 
tigermattCommented:

Did you by any chance adjust the SSL Settings for the /owa virtual directory in IIS? It sound as if the setting regarding client certificates has accidentally been enabled.

In IIS Manager, locate the owa virtual directory, choose 'SSL Settings' from the list of options and ensure "Client Certificates" is set to Ignore. OWA doesn't need nor use them. Then press 'Apply' in the task pane to save the changes.

-Matt
0
 
AkhaterCommented:
can you share a screen shot please?

from what I understood it seems you have enabled client certificate request

Open IIS manager find default website double click on SSL settings and make sure clients certificate is set to ignore
0
 
AkhaterCommented:
:)
0
Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

 
petesulliAuthor Commented:
OK guys,
I .... MAY have tweaked that setting by accident.... ;)

BUT having fixed that, the web browser no longer asks for a cert, but the Outlook clients inside are still doing a pregnant pause and then connecting TCP/IP.

Any ideas on that bit?
0
 
AkhaterCommented:
did you restart iis after the change ?
0
 
petesulliAuthor Commented:
Just restarted the whole server to make sure.

Same things HTTPS connections from outside, but TCP/IP eventually from inside.  I can see the laptop atempt HTTPS then fall back to TCP?

I am at a complete loss on this guys.

0
 
tigermattCommented:

What are the settings in the 'Exchange Proxy Settings' dialog? Tools > Options > Exchange Account > Change > More Settings > Connection > Exchange Proxy Settings.

Specifically, the "On fast networks" and "On slow networks" settings.

Does Outlook Anywhere work from outside the network?

-Matt
0
 
petesulliAuthor Commented:
The proxy and msstd:  are both exserv.external.com.

All ticks on, and basic auth.

Yes it does work from outside.

And this is the crunch, I just read a note about split DNS, so I tested with a hosts entry on my machine for internal address against external name, and it all jumped into life.

Will report back after I have setup the split dns.
0
 
tigermattCommented:

If you don't have split DNS configured, it's possible the HTTPS request is resolving to the external IP of the server, but the firewall is preventing the internal traffic reaching the server via that external IP. Thus, Outlook eventually times out and resorts to trying TCP/IP.

Given your HOSTS file test, split DNS will almost certainly resolve that for you. Are you okay to configure the new DNS zone required?

-Matt
0
 
petesulliAuthor Commented:
Matt, you are a generous guy with your time!

Im think Stub forward lookup zone for external.com, containing an A record for exserver.external.com ?

Mark
0
 
tigermattCommented:

Hey Mark,

*laughing* Don't mention it!

A stub zone probably isn't the best way to go. Stub zones are essentially "pointer" zones - they only contain the Name Server and Glue records to refer a DNS request for that name space to an external name server. Given that the requests are being sent to an external name server by ISP forwarders or root hints at the moment anyway, this won't change any of the current behaviour.

You'll actually need to create a full Primary forward lookup zone, in which you can then create either an A or CNAME record (exserver.external.com) to map to your internal Exchange Server address. I prefer to use CNAME records in the external zone, setting the exserver.internal.local as the alias the CNAME maps to. With this approach, duplication of information is minimised and you don't need to manually change the external zone's records if the internal IP of the Exchange Server changes.

-Matt
0
 
petesulliAuthor Commented:
You are right,
Perfect, working like a charm.

Points time and home time at the same time... all good.

Mark
0
 
petesulliAuthor Commented:
Dropped afew points on AK cos he was obviously heading the same way as Matt :)
0

Featured Post

Learn to develop an Android App

Want to increase your earning potential in 2018? Pad your resume with app building experience. Learn how with this hands-on course.

  • 6
  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now