none
Different SSL certificates for external and internal use?

    Pertanyaan

  • Hi!

    First off: Congratulations to MS for Exchange 2010, love it!

    But I have a bit of a problem here: We have purchased an official SSL certificate for use with our external OWA domain (owa.imc.at)
    Using this certificate, access to https://owa.imc.at/ and also ActiveSync works perfectly without security warnings. (Domain names match)

    The problem with the official cert is the internal access using Outlook, where the server name is srv-xch01.imc.at. (ActiveDirectory domain name is the same as the public domain for web site, email ...)
    When connecting internally with Outlook the certificate does not match because it's only issued for owa.imc.at, and not srv-xch01.imc.at - resulting in disturbing warning popups.

    I noticed that I cannot use different certificates on the same IIS Site after we requested the certificate.It's too late now... the cert is only valid for owa.imc.at.

    So what is the solution here?
    How is it possible to present different certificates for different domains?
    - Do I need to install another IIS (ClientAccess Role) on a different server? (different cert on frontend/backend)
    - Can I somehow present different certificates depending on the client IP address? (depending on public or private address class)
    - Can I make IIS listen on an additional TCP port and use another cert there? (same site, same server, different socket, different cert)
    - Can I do it using some Proxy that switches out the Certificate?

    I'm a bit stuck and need clearance about the possible solutions here. What would you suggest?

    Thanks! Daniel
    03 Desember 2009 21:25

Jawaban

Semua Balasan

  • Are your internal users not going to the sam URL as the external ones would? In other words are you using split-brain DNS or not? If your internal users went to the same OWA URL internall then you would not get any certificate popup warnings.
    Brian Day, Overall Exchange & AD Geek
    MCSA 2000/2003, CCNA
    MCTS: Microsoft Exchange Server 2010 Configuration
    LMNOP
    03 Desember 2009 22:22
  • You could create another Exchange Virtual Directory, I believe that would help ya.


    SF - MCITP:EMA, MCTS: Exchange 2010, Exchange 2007, MOSS 2007, OCS 2007 -- http://www.scottfeltmann.com
    03 Desember 2009 23:24
  • When accessing OWA from inside they use the same URL https://owa.imc.at/, but Outlook is not connecting to that URL. Maybe I could change the internal Name to owa, but I want to keep internal server names as they are. SRV-XCH01 ist the Exchange server. What would I do if the internal (ActiveDirectory) domain name was different? like srv-xch01.imc.local? I think that is almost everywhere the case, so how are other companies doing that?
    04 Desember 2009 9:37
  • Another Virtual Directory would still be on the same Server/Site and use the same certificate, so that wouldn't help me.
    04 Desember 2009 9:38
  • I just figured out that you can create another binding on the same Site/Server, with a different Port (for Example 8443 instead of 443) and select a different certificate there.
    That would be the solution for me, because I would then just set up the port forward on the firewall from port 443 to port 8443.

    However, when I create that second binding/socket Outlook presents an warning and for example Out Of Office Wizard doesn't work anymore.
    I don't understand why that affects Outlook, because an additional socket shouldn't change the old one... Outlook shouldn't even be aware that it exists.

    What is going on here?
    04 Desember 2009 11:18
  • This is what I get in the IIS Logs when both Bindings are enabled:
    2009-12-04 13:05:42 192.168.210.104 POST /Autodiscover/Autodiscover.xml - 443 - 192.168.210.142 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6425;+Pro) 500 0 0 281
    2009-12-04 13:05:42 192.168.210.104 POST /autodiscover/autodiscover.xml - 443 - 192.168.210.142 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6425;+Pro) 500 0 0 234
    2009-12-04 13:05:42 192.168.210.104 GET /autodiscover/autodiscover.xml - 80 - 192.168.210.142 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6425;+Pro) 403 4 5 250

    This is what I get when only the 443-Port is bound and I start Out-Of-Office Wizard for example:
    2009-12-04 13:09:49 192.168.210.104 POST /Autodiscover/Autodiscover.xml - 443 - 192.168.210.142 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6425;+Pro) 401 0 0 1859
    2009-12-04 13:09:51 192.168.210.104 POST /Autodiscover/Autodiscover.xml - 443 IMC\da 192.168.210.142 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6425;+Pro) 200 0 0 2000
    ...

    Somehow it seems to respond with a HTTP 500 error
    04 Desember 2009 13:14
  • Why not use a SAN/UC certificate?

    I think that will solve your problem, insert the owa.externaldomain.com, autodiscover.externaldomain.com, hostname and hostname.domain.local
    You can have a look at this link to get help for creating the CSR
    https://www.digicert.com/easy-csr/exchange2007.htm

    Or like others said, make users from the inside connect to the same address as for the external usage
    • Disarankan sebagai Jawaban oleh chrislehr 07 Desember 2009 21:50
    05 Desember 2009 13:34
  • Like I said, the certificate is only valid for owa.imc.at, we have no SAN certificate. That would also be more expensive.
    I would really like to use a different server name internally. That has got to be possible somehow.

    I'd like to know why an additional socket on the site causes that error message in Outlook.
    05 Desember 2009 15:04
  • You have choices here.

    1) Buy a SAN cert - I see you already said that this is not an option, but it is the LEAST confusing and least complex option.
    2) Duplicate /owa, /ecp, /Activesync /EWS and Autodiscover virtual directories.  Duplicate the number of SSL certs.  Typically, I also add a second IP to the server and have one IP (the first one) be the "internal" IP/Namspace/cert and the second one be your "external" IP/NameSpace/cert


    I am speaking at a high level, but option #2 makes your environment more confusing/complex and less "default" installation.  Option #1, like you said, costs more.  But so does downtime and confusion due to an overly complex environment.
    07 Desember 2009 21:53
  • How are users accessing your external OWA server?  Are they going to a reverse proxy or direct to the CAS?

    Are you using split DNS?  The question is what IP address are users using internally when they connect to your URL?  This could be a matter of your internal LAN not routing correctly to the external IP and coming back in.  You're better off pointing your internal DNS to the internal IP.

    So, really, what is your owa traffic like?  The reason active sync works is b/c it is going to your external IP address and then coming in from the outside since they are liekly using the broad band of the cell phone carrier.

    But, the best bet would be is to use a SAN cert.  If you dont' have a SAN cert available than you need to figure out a way to either do a reverse proxy like ISA, which will do SSL Bridging or use a SAN cert from an internal CA and deploy the CA as a trusted root on all your mobile devices.

    In regards to your question how do other companies do it?

    Well, if you have ISA you point traffic to ISA and deploy your public cert on ISA.  Then you use an internal CA to deploy an internal UC cert and deploy that on the CAS server.  This UC/SAN cert will include your owa name, netbios name of your server, fqdn of your server and autodiscover.domain.com.

    If you don't have a reverse proxy and you're using one DNS environment for internal and external you will need to allow your LAN to pass traffic outside your network to your external entry point and back in.

    Your network/firewall guy should know how.   But likely your problem with the domain name is b/c of a network routing from the lan to outside and back in.


    SF - MCITP:EMA, MCTS: Exchange 2010, Exchange 2007, MOSS 2007, OCS 2007 -- http://www.scottfeltmann.com
    07 Desember 2009 21:58
  • Thank you for your replies!

    I would like to keep it as simple as possible of course, but buying another certificate is not really what i want to do.
    There must be a way to get IIS just use a different cert depending on either the client IP address or the TCP port.

    I think creating a second binding must be a solution, since I can select a different certificate for each binding.

    The only problem with that is that Outlook complains and I don't know why.

    Can anyone explain why it does even make a difference to Outlook/Exchange when there's a second binding?

    You can see in the logs I posted above that Outlook tries to connect to the same port but gets HTTP 500 and 403 instead of 401, 200.

    Is there a way to track down the whole HTTP stream? (not only what is in the logs there)
    07 Desember 2009 23:14
  • Wireshark.

    I still think you're problem is with DNS and network routing.


    SF - MCITP:EMA, MCTS: Exchange 2010, Exchange 2007, MOSS 2007, OCS 2007 -- http://www.scottfeltmann.com
    08 Desember 2009 4:05
  • It would be pretty bad if wireshark could log HTTPS traffic

    Our network and DNS is pretty simple.

    An internal network 192.168.210.0/24 where all the servers and clients are in. All patched one big switch.
    The internet gateway and firewall is a Fortigate 50B. It has NAT enabled between LAN and WAN with one static public IP address.
    Also it has the port forwards needed to access the Exchange server (HTTP, HTTPS) and to our mail Relay and Spam filter (SMTP) from the outside.

    Internal and external DNS are completely separated, but have the same domain imc.at
    08 Desember 2009 19:31
  • You could configure ISA to act as a reverse proxy for internet traffic. Put your public Cert on the ISA server and than deploy an internal CA and give a SAN cert to your internal Exchange.  This will allow for multiple names on the exchange server and should resolve your issue.

    ISA will present additional security, for Exchange, SSL bridging and data packet analyzing. 


    SF - MCITP:EMA, MCTS: Exchange 2010, Exchange 2007, MOSS 2007, OCS 2007 -- http://www.scottfeltmann.com
    08 Desember 2009 23:22
  • OK thanks, I'll have a look at that.
    Is there a KB article or other tutorial on how to set up ISA for that matter?
    08 Desember 2009 23:27
  • Using ISA as a reverse proxy is the best solution to secure external access to any CAS service.

    The use of the same FDQN for internal and external sites is quite easy. You can easily split Active Sync and OWA to support different authentication mechanisms.

    External (via ISA)
    - Site 1: Exchange Active Sync (using Basic Auth for device support)
    - Site 2: All other Exchange services (using Token authentication)
    External DNS requests are being handled by the external DNS servers

    Internal (direct access)
    - Site 1: Exchange Active Sync (end point for ISA and for direct access of mobile devices connected to workstations)
    - Site 2: All other Exchange services (using Windows authentication)
    Internal DNS requests are being handled by the internal DNS servers

    Site 1 uses a different SSL cert as site 2.
    09 Desember 2009 8:08
  • I don't understand why I would need ISA to accomplish that.

    Again: Why does Outlook complain when I enable a second binding on the Site in IIS?
    Why do I get a different HTTP response to the same request even if I use the same port?
    09 Desember 2009 9:36
  • I have a similar situation:  internal exchange server running owa at servername.internaldomain, but also serving up owa to external clients at webmail.publicwebsitedomain.  we have ssl bridging set up between our ISA server and the exchange server, and the cert is for webmail.publicwebsitedomain.  Internal users connecting via servername.internaldomain get a bad cert warning, but if they use the external address (webmail.publicwebsitedomain) they connect without error.

    I've considered deploying a local hosts file to clients pointing webmail.publicwebsitedomain to the internal server (rather than the external ISA network IP), but that seems kludgy.  I haven't deployed the ISA Firewall client either (doesn't seem appropriate to mess with for just this).

    Maybe split-DNS would help you use a single cert for both internal and external use?

    http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html

    I'm several versions behind (ISA2000, Exchange2003) but I believe the concepts are the same.  I haven't bothered with setting it up because we're a small enough shop that I don't think our ISA server really gets overworked by looping internal requests to our internal OWA through it's external network connection, but maybe it's appropriate for your situation.

    Another thought I had was a separate front-end exchange server running on a different IP, but again, that seems like overkill.

    If you figure out a good solution, please post it - I'm curious to hear what you end up doing.

    Cheers,

    Ned

    23 Maret 2010 19:30
  • Ned, you would be better of moving to ISA 2006 and using Split DNS. 

    You will also need to deploy (if you don't have one already) an internal Certificate Authority (CA).  With the internal CA you can create your own trusted certificates that will be trusted by domain computers.  Here you can have as many subject alternative names (SAN) as you want on one cert.

    You would configure internal name space, split DNS, ISA would host the public cert and the Exchaneg server will have the internal cert.

     


    SF - MCITP:EMA, MCTS: Exchange 2010, Exchange 2007, MOSS 2007, OCS 2007 -- http://www.scottfeltmann.com
    25 Maret 2010 13:57
  • Why not create an internal dns name owa.imc.at on your internal dns servers, or the cname owa.imc.at pointing to srv-xch01.imc.at. Then internal would still be routing to the same name as external.
    18 April 2011 15:22
  • You have choices here.

    1) Buy a SAN cert - I see you already said that this is not an option, but it is the LEAST confusing and least complex option.
    2) Duplicate /owa, /ecp, /Activesync /EWS and Autodiscover virtual directories.  Duplicate the number of SSL certs.  Typically, I also add a second IP to the server and have one IP (the first one) be the "internal" IP/Namspace/cert and the second one be your "external" IP/NameSpace/cert

    I am speaking at a high level, but option #2 makes your environment more confusing/complex and less "default" installation.  Option #1, like you said, costs more.  But so does downtime and confusion due to an overly complex environment.

    He is right, there is no cheap way or tricky way with Exchange 2010 and Outllok 2010 clients. You, at the end, will have to buy a SAN Certificate. In Europa we pay around EUR 200.- for 3 Names and EUR 25.- for any add. name (4th URL).

    Do not try the second Active Directory Virtual Directory (For Activesync) if you are an IIS Expert. You may end up in a terrible security Leak by doing so. And in the worst case you get a lot of trouble because you wanted to save the investment for the SAN-certificate. This at the end is highly complex and if you patch Exchange you may run into trouble in such a situation.

    The discussion for tthese points assuming you have NO ISA Firewall in place and don't want that.

    Just the MX in DNS, Your Firewall and the CAS Server.

    04 April 2012 7:43
  • OK thanks, I'll have a look at that.
    Is there a KB article or other tutorial on how to set up ISA for that matter?

    You want to install AND manage an ISA Server because you Don't want to spend EUR 200.- for the SAN Cert? Or you want the reverse proxy security and need that?
    04 April 2012 7:44
  • Did you ever get an answer to your question?

    I had the same problem. This is what i did to correct my issue...

    First, you'll need to have a CA Server online.

    Then, Open IIS Manager -> Select your server -> Server Certificates -> Create Domain Certificate -> run through wizard...

    note - common name is the FQDN of your server Exchange server (in your case srv-xch01.imc.at). Also, i would recommend setting the friendly name same as the common name. It makes it easier later on.

    Once the new SSL Certificate is listed, then drill down to the site that needs the SSL Certificate...

    Your going to add a new binding to the existing site (not make a new site)...

    Add Binding -> HTTPS -> set the IP and your local IP (not "All Unassigned") -> Port 443 -> Select the new SSL Cert that you just created (you can "view" and verify the thumbprint is the same as what you just created) -> Click Ok -> CMD prompt -> IISRESET /NOFORCE

    I did this and have no issues. Hope it goes well.

    cheers

    Joseph

    • Disarankan sebagai Jawaban oleh Robert Coraci 18 September 2012 22:54
    • Saran Jawaban dibatalkan oleh Robert Coraci 18 September 2012 22:54
    22 Juni 2012 16:43
  • I recently encountered the same problem.

    Here is the knowledgebase article that I used to solve the problem:

    http://support.microsoft.com/kb/940726

    18 September 2012 22:54
  • Just stumbled upon that old thread and indeed, in the end it was as simple as changing the internal URLs in Exchange config.

    So now every client (Outlook, Browser to OWA, Phones ...) connects to the same Domain and everything's OK

    except for autodiscover :) but that's another story

    02 Oktober 2012 12:19