[isapros] Re: ISA and SAN Certs
- From: Jason Jones <Jason.Jones@xxxxxxxxxxxxxxxxx>
- To: "isapros@xxxxxxxxxxxxx" <isapros@xxxxxxxxxxxxx>
- Date: Mon, 8 Oct 2007 15:22:24 +0100
Nah, meant the fact that a portal approach may make it easier to have less
external FQDNs and less certs.
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: 08 October 2007 15:21
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
Sorry; it won't.
IAG has similar problems with SAN certs.
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jason Jones
Sent: Monday, October 08, 2007 7:18 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
Yeah, or SANs...appears we have gone full circle! :-)
<off-topic> I love using wildcards with ISA, but I am hearing that the new
Extended Validation (EV) certs will not support the use of wildcards. I can see
the security failings with wildcards, but the manageability they provide for
big ISA publishing scenarios is great...</off-topic>
Maybe as ISA and IAG merge into UAG, this will be less of an issue...
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thomas W Shinder
Sent: 08 October 2007 15:04
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
Looks like the solution in a CNAME config is a wildcard cert.
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> Sent: Monday, October 08, 2007 8:55 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
>
> Hmmm...this is not what Steve implied though:
>
> > This way when Outlook 2007 is on the internet and asks
> > joeblow_nameserver for autodiscover.domain.com it will be
> > sent to your external DNS entries where it will find
> > autodiscover.domain.com which is an alias for
> > mail.domain.com, the exact details of why outlook accepts it
> > i am not sure, but it doesn't give me any complaints. So this
> > way you don't need multiple external IPs (expensive), nor SAN
> > SSL certificates (unnecessary and expensive), nor create
> > multiple internal websites (unnecessary).
>
> I was just having a dig around about CNAMEs and SSL as you
> guys posted because I was surprised this seems so easy to fix...
>
> Steve - you got magic certs? :-)
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: 08 October 2007 14:49
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
>
> CNAME works fine for SSL connections *as long as* the
> destination certificate includes a name matching the original
> FQDN and the client can find it.
> For Tom's concern, a mail server with mail.domain.tld in the
> cert subject and no SAN would break an
> autodiscover.domain.tld connection, but if the cert has a SAN
> entry that includes autodiscover.domain.tld (and the client
> can find it), the connection will proceed just fine.
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> Sent: Monday, October 08, 2007 6:46 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
>
> Actually, CNAME shouldn't work for SSL connections. What name
> is the client going to end up using in the SSL session
> negotiation when you use CNAME records?
>
> Thomas W Shinder, M.D.
> Site: www.isaserver.org
> Blog: http://blogs.isaserver.org/shinder/
> Book: http://tinyurl.com/3xqb7
> MVP -- Microsoft Firewalls (ISA)
>
>
>
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> > Sent: Monday, October 08, 2007 8:42 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Ah, good point...so assuming you are using default ports, the
> > CNAME idea sounds like a better option then?
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > Sent: 08 October 2007 14:39
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Because only a SRV record can describe a protocol and port
> > from a DNS query.
> > Lots of folks use custom SSL ports and a SRV record is the
> > only way it can be found "automagically".
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Moffat
> > Sent: Monday, October 08, 2007 6:22 AM
> > To: ISAPros Mailing List
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Because they didn't know?
> >
> > :)
> >
> > Because they never tried it??
> >
> > :)
> >
> > Because they like making things harder than they need tp?
> >
> > :)
> >
> > S
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> > Sent: Monday, October 08, 2007 4:55 AM
> > To: ISAPros Mailing List
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Ok, now I am confused. If you can simply add a CNAME to
> > redirect autodiscover.domain.com to your chosen URL, why did
> > the Outlook team bother to create the hotfix to use SRV records???
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Moffat
> > Sent: 06 October 2007 20:51
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Just to muddy the waters...:)
> >
> > I pass this information on, that it may be of help to others
> > (including myself in remembering what i did!)
> >
> > Preamble: This is my setup, so i cannot guarantee that this
> > will work for you, I have for this setup, 1 server running
> > Windows 2003 x64. If you want to install Exchange 2007 you
> > will need it on either Windows 2003 x64 or 2007 x64 bit
> > versions, the 32bit (x86) will not work. I also have one
> > static public (external) IP. Most of the configurations i
> > came across for Exchange will talk about multiple web sites
> > (with different internal IPs) the thing they rarely mention
> > is that you will need multiple external IPs to map to these
> > internal IPs. If you have multiple external IPs then it is
> > probably better that you assign 1 for autodiscover.domain.com
> > so that you have more choices down the road instead of
> > locking it to the same IP as your main CAS IP. If however you
> > are restricted to 1 external IP this may help you.
> > A little note about SSL certificates, Exchange 2007 is a bit
> > of a nightmare for SSL certificates, by default you have a
> > self-signed certificate made by exchange, which is ok if you
> > have no one accessing any external services like OWA,
> > activesync, RPC over HTTP (OutlookAnywhere). However this
> > scenario is probably unlikely. If you do have these services
> > then you either can install this self-signed certificate on
> > every computer that needs to access these services not to
> > mention telling people to click through the IE7 stupid "There
> > is a problem with this website's security certificate",
> > needless to say this is really not a viable option for most
> > people. So pretty much the only real option is a commercial
> > SSL certificate. Trying to find the most economical way to do
> > things, i tried StartCom's free (yes really free, not trial)
> > SSL certificate, problem is that it is trusted by almost
> > everyone INCEPT Internet Explorer, needless to say it becomes
> > a pain to teach people the same thing about untrusted
> > certificates. OK - other choices - for Exchange 2007 you are
> > talking about 2 SSL (I'll show you the bypass to get it to 1
> > later), one for mail.domain.com and another for
> > autodiscover.domain.com, that means if you've done any
> > research on the subject that you need an SSL cert that
> > supports SAN (Subject Alternative Name). At present the
> > cheapest one is $200/year, others are considerably more
> > expensive. Better but even $200/year i find a little steep if
> > all you need is just a CAS certificate (exchange 2003
> > front-end certs are easily <$100). On top of this you may
> > already have a mail.domain.com cert that would now be
> > useless. I have a mail.domain.com cert from GoDaddy which
> > cost $20/year (or less) and that is the one that i will be using.
> > Getting Started:
> > To start off I did a clean install of windows 2003 x64, setup
> > DNS, WINS (if necessary), DHCP, IIS in that order, a fairly
> > typical PDC. Then a standard install of Exchange 2007, there
> > a few extra programs and hotfixes to install but the install
> > program is good about telling you what you need. A little
> > note, you can install the Exchange tools on a 32 bit machine
> > to do most of the administration from a client machine. Ok so
> > you have a clean Exchange install, let's configure it.
> > To allow Exchange to accept connections from other mail
> > server, open Exchange Management Shell (EMS)
> > Run the following command;
> > Set-RecieveConnector -Identity "Default <ServerName>"
> > -PermissionGroups "AnonymousUsers"
> > Replace <ServerName> with your CAS name. Close the EMS
> > To allow Exchange to send mail to other mail servers, open
> > Exchange Management Console (EMC), open Organization
> > Configuration->Hub Transport, click on 'Send Connectors',
> > Right click (RC) in the 'Send Connectors' box and select 'New
> > Send Connector', choose a name, for example 'All Outgoing
> > Connector', leave the 'Select the intended...' as Custom, for
> > the Address Space click the 'Add' button and enter * in the
> > Add Address Space window marked Domain, to accept SMTP
> > connections from all domains, leave the 'Include all
> > subdomains' unchecked. In Network settings leave all values
> > at their default settings, in 'Source Server' again leave the
> > default values, and finally in 'New Connector' click on 'New'
> > to create the connector.
> > At this point Exchange should be able to send & receive mail.
> > At this point if you are going to support Outlook with RPC
> > over HTTP you will need to install that service, go to
> > Control Panel->Add/Remove Programs->Add/Remove Windows
> > Components, Select Networking Services, click on details,
> > click the 'RPC over HTTP Proxy', click 'ok', Click 'next',
> > make sure Windows has access to the install source, after the
> > proxy is installed, click 'Next'.
> > Now you need to remove the Exchange self-signed cert, Open up
> > IIS manager (Administrative Tools->Internet Information
> > Services (IIS) Manager), Open the Server subfolder, open the
> > 'Web Sites' folder, and open the 'Default Web Site', there
> > will be several virtual directories (VD) below the DWS
> > including owa, and Autodiscover. RC the DWS and select
> > Properties, then click the 'Directory Security' tab, then
> > click 'Server Certificate' and then click 'Next' at the SSL
> > welcome wizard. The next step depends if you already have an
> > SSL certificate for mail.domain.com or not. If you do then
> > click 'Replace the current certificate' and follow the
> > instructions. If you do not have an SSL certificate then
> > select the 'Remove the current certificate'. The latter will
> > only remove the certificate from the DWS, it will stay in the
> > windows certificate store so if you ever need it in the
> > future you can always get it back. After you remove the
> > certificate, re-run the wizard and it should ask you to go
> > through the process of asking for an SSL certificate, follow
> > the wizard which will create an certreq.txt file which you
> > will need to make the application at a Certification
> > Authority (CA) company, such as GoDaddy or others. I will
> > leave this to you to follow since the process varies a bit
> > from CA to CA (ie for GoDaddy you need to install an
> > intermediate certificate, which may not be necessary for more
> > expensive CAs. I am using a turbo ssl cert which is
> > registered for mail.domain.com and costs $20/year.
> > At this point you should have your mail.domain.com cert on
> > the DWS, and any other intermediate certs installed.
> > Next lets change owa so you need to just enter your username
> > and not domain\username; In EMC go to Server
> > Configuration->Client Access, RC the owa (DWS) click
> > Properties, click the authentication tab, select the 'use
> > forms-based authentication:' and then select the 'User name
> > only', then click on Browse and choose your logon domain.
> > Click 'Ok' to exit.
> > To install Outlook Anywhere in EMC go to Server
> > Configuration->Client Access, RC the server and select
> > 'Enable Outlook Anywhere', for the External host name use:
> > mail.domain.com , External authentication methods: choose
> > NTLM authentication, do not select 'Allow secure channel
> > (SSL) offloading', click Finish to exit.
> > Next we need to change the URLs used autodiscover so that all
> > services point to mail.domain.com.
> > In EMC go to Server Configuration->Client Access choose the
> > Offline Address Book (OAB) Distribution tab, RC the OAB (DWS)
> > and select properties, Click on the URLs tab and put in:
> > https://mail.domain.com/oab for both both internal and
> > external URLs. Click 'Ok' to accept and exit.
> > Do the same for owa by going to Server Configuration->Client
> > Access (Outlook Web Access tab) andRC the owa (DWS) and
> > choose properties, on the General tab change the Internal and
> > External URLs to: https://mail.domain.com/owa , click
> > 'Apply', an extra feature you may want to give is access to
> > network shares through owa, this is available on the
> > Documents box in owa, if you do then go to the 'Remote File
> > Servers' tab and click the 'Configure' button on the bottom,
> > enter the domain you are using, ie for mail.domain.com you
> > would put domain.com, click 'add' then click 'ok' to exit.
> > Then click on the 'Allow' button and enter the FQDN of your
> > CAS, ie if the CAS computer name is mx1.domain.com, then
> > enter mx1.domain.com and click 'add' then 'ok'. This will
> > give owa users access to any network shares that exist on
> > mx1. Click 'ok' to save and exit. If you do not want this
> > then disregard that previous procedure and click 'ok' to exit.
> > Next we'll change the URLs for the Unified Messaging, while
> > this step is probably not necessary for most people, it will
> > look better at the end. However to change the URLs we need to
> > go to the EMS.
> > Open the EMS and enter the following command;
> > Set-UMVirtualDirectory "UnifiedMessaging (Default Web Site)"
> > -InternalURL
> > https://mail.domain.com/Unifiedmessaging/Service.asmx
> > -ExternalURL https://mail.domain.com/Unifiedmessaging/Service.asmx
> > Next we change the URLs of the Availability service which
> > will also be the same for OOF, in EMS enter the following command;
> > Set-WebServicesVirtualDirectory -Identity "EWS*" -InternalURL
> > https://mail.domain.com/EWS/Exchange.asmx -ExternalURL
> > https://mail.domain.com/EWS/Exchange.asmx
> > Finally we set the autodiscover URL, now this is a little
> > special since it is not possible to set the external URL of
> > autodiscover. Outlook 2007 is set to look for
> > autodiscover.domain.com or domain.com/autodiscover, and this
> > is in my opinion where all the security alert mess comes
> > from. Anyways in the EMS enter the following command;
> > Set-ClientAccessServer -Identity "your CAS server name (ie
> > mx1)" -AutoDiscoverServiceInternalUri
> > https://mail.domain.com/autodiscover/autodiscover.xml
> > Ok all done with EMS, you can close it and go to your DNS
> > management, Administrative tools->DNS. First in the Foward
> > Lookup Zone (FLZ) for domain.com, RC the domain.com and
> > select 'New Host (A)', enter: mail ,for the name and input
> > the Internal IP of your CAS. Next RC the FLZ under your
> > server and select 'New Zone', click 'Next' at the wizard
> > introduction, leave the zone type as Primary and
> > ActiveDirectory integrated, click 'Next', leave the zone
> > replication on the default, which is to all domain dns
> > servers, click 'Next', For the name enter:
> > autodiscover.domain.com , click 'Next', for the dynamic
> > updates change the setting to 'Allow both unsecure and secure
> > dynamic updates, click 'next then click 'Finish'. Now RC the
> > new autodiscover.domain.com and select 'New Alias (CNAME)',
> > leave the name field blank and just click on the Browse
> > button, In the new browse window, double-click (DC) the
> > server name, DC the FLZ folder, DC domain.com and then select
> > the mail entry, click 'ok' to complete. You can now close DNS.
> > I would recommend restarting the server to insure that the
> > new settings are accepted. One thing you will want to check
> > after the restart is to go to EMC->Server
> > Configuration->Mailbox, RC the mailbox database, select
> > properties, click on the 'Client Settings' tab and verify
> > that you have the 'Default Offline Address Book' listed in
> > the Offline address Book window, if not click on the Browse
> > button and select it. If it was not there then restart the
> > server again after you have selected it.
> > Ok almost done! You should be able to start up a Outlook 2007
> > client and when adding an exchange mail account it should use
> > the autodiscover feature to get all the URLs. Hopefully
> > everything should work, if you do get a Security Alert
> > windows then try restarting the client and server, also
> > verify that the SSL cert is accepted on the client. If
> > everything did go well then Outlook can connect and
> > send/receive from exchange. Now you can check that all the
> > URLs are pointing to mail.domain.com, while holding down the
> > left 'Ctrl' button RC the Outlook icon in the system tray,
> > this should give you a menu which has 'Test e-mail
> > Autoconfiguration' in the test window, enter your email (ie
> > user@xxxxxxxxxx), unselect the "use guesssmart" and "secure
> > guesssmart authentication" then click 'Test'
> > If everything goes well then you should have 2 sections after
> > the results come in, one for Exchange RPC and the other
> > Exchange HTTP. The RPC is for LAN connections and HTTP is for
> > HTTP connections. In both sections all the URLs should start
> > https://mail.domain.com
> > If this is not the case then go back and find the problem.
> > Another test to do is to verify that your OWA is working
> > internally. If you open Internet Explorer (IE) and enter
> > https://mail.domain.com/owa , don't forget to change domain
> > to whatever your domain is. This should give you the OWA
> > login webpage, if not then go back and find the problem. You
> > should not have any Security Alerts with the OWA.
> > If this is ok then your 200x Outlook clients should be
> > working ok internally and your 2003 clients should be ok
> > externally. However if you try your Outlook 2007 clients from
> > the internet you will probably find that they give a Security
> > Alert, and that is because they are looking for either an SSL
> > with a name of autodiscover.domain.com or domain.com. Since
> > yours is for mail.domain.com it will give a name mismatch
> > error. To resolve this you must access your external dns
> > entries which are usually handled by your hosting provider.
> > For your external DNS you will have a MX record for where
> > your mail is sent and probably entries for www, ftp, etc.
> > These are the way that computers on the internet find
> > domain.com resources. Usually it takes 4 to 24 hours for
> > adding or changing the external DNS entries to actually start
> > redirecting clients, so don't expect just because you changed
> > the MX record that your email will be redirected right away.
> > The setup is very similar to the DNS entries for the internal
> > network, for the external DNS entries you will have the MX
> > record to point to mail.domain.com (MX cannot point to an
> > IP), you will need a Host record (A) that is for
> > mail.domain.com which points to your external IP and finally
> > an Alias (CNAME) entry for autodiscover.domain.com which will
> > point to mail.domain.com.
> > This way when Outlook 2007 is on the internet and asks
> > joeblow_nameserver for autodiscover.domain.com it will be
> > sent to your external DNS entries where it will find
> > autodiscover.domain.com which is an alias for
> > mail.domain.com, the exact details of why outlook accepts it
> > i am not sure, but it doesn't give me any complaints. So this
> > way you don't need multiple external IPs (expensive), nor SAN
> > SSL certificates (unnecessary and expensive), nor create
> > multiple internal websites (unnecessary).
> > I have been using this for a few weeks now and everything
> > appears normal and stable, i have been using Outlook 2007, i
> > have not tested this on Outlook 2003 however i do not think
> > there should be any problems. The OWA and Outlook clients
> > have no problems connecting, the only thing which i find a
> > bit un-normal is that it seems to take about 2 minutes for
> > Outlook to connect and synchronize, with Exchange 2003 and
> > Outlook 2003 it seems to be quite a bit faster, if anyone can
> > comment on this I'd appreciate any insight.
> > I have tested this also with Windows Mobile 2003SE and the
> > activesync works well, if you have the GoDaddy cert you will
> > need to add the CA cert to the WM2003 trusted root store,
> > then after that it connects fine.
> > Most of this information is around the internet but I thought
> > this would be useful to write down in one place since i
> > didn't find much information about external DNS settings. I
> > did leave out some extra information about redirecting the
> > OWA URL, which allows users to log into the port 80 http owa
> > url and then get redirected to the 443 https url, however i
> > am not really satisfied with the current method of the
> > redirect html page. If i find something i'll post back.
> > Anyways i hope this give some insight for some and will help
> > with the installation.
> >
> > Heh heh...Steve
> >
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> > Sent: Thursday, September 20, 2007 11:16 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > The fact is you just can't be sure, in my book, that makes is
> > useless if you want to provide a robust solution and not have
> > to worry about use location/infrastucture...anyhow, just
> > testing my logic before I decide what to tell customers...
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > Sent: 20 September 2007 15:05
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > That's kinda myopic...
> > Your statement suggests that you think all OL clients will be
> > found behind CERN or SOCKS proxies. That just ain't true.
> > Most folks at home use some CompIsUs $25 toy that barely
> > qualifies as a NAT device; much less a firewall or proxy. In
> > this case, the SRV record lookup will (may?) work.
> >
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> > Sent: Thursday, September 20, 2007 7:00 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > How about we look at it like this; the SRV solution, in
> > reality, is useless! :-P
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > Sent: 20 September 2007 14:48
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > I see what you mean.
> > Look at it this way - the benefit for a SRV record in this
> > case is to specify a non-standard port if one is required.
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> > Sent: Thursday, September 20, 2007 3:29 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > From what I can tell, OA looks for the A record first, this
> > is the bit that seems silly...especially when combined with
> > the issues of SRV and CERN proxies.
> >
> > Quote from KB:
> >
> > In this example, the Autodiscover service does the following
> > when the client tries to contact the Autodiscover service:
> >
> > 1. Autodiscover posts to
> > https://contoso.com/Autodiscover/Autodiscover.xml. This fails.
> > 2. Autodiscover posts to
> > https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml
> > . This fails.
> > 3. Autodiscover performs the following redirect check:
> > GET http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml
> > This fails.
> > 4. Autodiscover uses DNS SRV lookup for
> > _autodiscover._tcp.contoso.com, and then "mail.contoso.com"
> > is returned.
> > 5. Outlook asks permission from the user to continue with
> > Autodiscover to post to
> > https://mail.contoso.com/autodiscover/autodiscover.xml.
> > 6. Autodiscover's POST request is successfully posted to
> > https://mail.contoso.com/autodiscover/autodiscover.xml.
> >
> > The Outlook 2007 "Test E-Mail Auto Configuration" utility
> > also follows the same sequence of doing A records first.
> >
> > JJ
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > Sent: 20 September 2007 01:03
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Actually, what I'm saying is that if OL 2003/7 is operating
> > as a CERN proxy client, it performs absolutely no name
> > queries at all; regardless of whether the name is listed as
> > an A, SRV, TXT, CNAME, etc. record. This is the basic nature
> > of a CERN proxy client; it sends a "gimme this, wouldya?"
> > request without regard for how the endpoint might be
> > resolved. Thus, OL will never communicate with a DNS server
> > in this scenario.
> >
> > The egress proxy will seek an A record, since there is no way
> > for the CERN proxy client to specify how the proxy should
> > resolve the destination (it's just not part of the protocol).
> >
> > You're correct that you have to maintain A as well as SRV
> > records if you intend to support CERN proxy as well as
> > direct-connected clients. I'm not sure how "silly" this is,
> > since CERN proxy mechanisms existed long before OL started
> > using autodiscover. AFAIK, OL will seek the SRV record
> > first, since this is much more informative than the A record.
> >
> > Jim
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> > Sent: Tuesday, September 18, 2007 3:42 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Hi Jim,
> >
> >
> >
> > So, in reality, we are saying that you can never be sure
> > Outlook 2007 will work correctly with SRV records if you are
> > unsure if the client will ever be working from behind a CERN proxy??
> >
> >
> >
> > This seems a little silly as the SRV check is the last in the
> > list, so therefore you will always need an A record for
> > autodiscover.domain.com to cater to clients that *may* be
> > behind a proxy. If this A record exists, surely Outlook will
> > never actually use the SRV record (as it is only used if the
> > A record cannot be found) and you still need ISA publishing
> > and certs for autodiscover.domain.com to allow for "behind
> > proxy" outlook clients...
> >
> >
> >
> > As we provide solution for customers, I cannot really afford
> > to deploy a solution that may or may not work depending on
> > whether the Outlook client is behind a proxy or not. So I
> > feel forced to have to go with the A record method
> > (reluctantly) to avoid potentially embarrassing questions
> > when a CEO cannot get OA to work when at an internet café
> > that uses a CERN proxy...
> >
> >
> >
> > Am I way off base here or does the logic seem wrong to you???
> >
> >
> >
> > Cheers
> >
> >
> >
> > JJ
> >
> >
> >
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > Sent: 31 August 2007 15:00
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> >
> >
> > The problem is that many applications operating behind CERN,
> > SOCKS or Socket proxies can't use SRV records.
> >
> > 1. CERN proxy clients *never* perform name resolution
> > for themselves other than to determine if a host is local or
> > remote. When it comes time to make the connection, OL (for
> > instance), will simple send a "GET
> > http://autodiscover.domain.tld/autodiscover.xml"; via its
> > local CERN proxy. The proxy assumes that it should resolve
> > "autodiscover.domain.tld" using an A record query and
> > continues on that basis If all you build is a SRV record,
> > this connection will fail.
> >
> > 2. SOCKS proxy clients *may* self-resolve names; it
> > depends on the SOCKS version in use by the application and
> > SOCKS proxy. For the record, ISA operates as SOCKS 4.3A,
> > meaning that it is capable of performing name resolution on
> > behalf of the client. If the application knows that it is
> > speaking to a SOCKS4.3a proxy, it will make the connection
> > request using the hostname. In this case, the proxy handles
> > name resolution in the same way that a CERN proxy does. If
> > the SOCKS proxy is operating as SOCKS4 or earlier and the
> > application knows this, the application is required to
> > perform its own name resolution.
> >
> > 3. Socket proxy (think FWC) clients will perform name
> > resolution as if they had access to the 'Net. How this
> > process is handled depends on how the client makes the name
> > lookup request. If it (as OL does) makes a Winsock
> > GetHostByname or GetAddrInfo call, they don't specify the
> > type of record they want, and Winsock (and the Winsock
> > LSP/BSP) will send it to the proxy as received.
> >
> >
> >
> > IOW, it's a rare case where a proxy-served client will even
> > seek; much less receive the SRV record.
> >
> >
> >
> > Jim
> >
> >
> >
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> > Sent: Friday, August 31, 2007 6:42 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> >
> >
> > Hi Jason,
> >
> >
> >
> > OK, that makes perfect sense and it's the scenario I'm
> > testing today. One listener, one rule for Outlook Anywhere
> > and one rule for Autodiscovery, correct?
> >
> >
> >
> > So I was right that you can't use the /AutoDiscover path that
> > is included in the Outlook Anywhere rule since the Outlook
> > Anywhere rule doesn't respond to the public name
> > autodiscover.domain.com. The Outlook Autodiscover rule would
> > respond to autodiscover.domain.com and forward to the
> > /AutoDiscover path.
> >
> >
> >
> > The SRV record solution will solve ALL of this complexity
> > because it will bypass the need for a second URL and second
> > IP address and second certificate. However, its a hotfix that
> > you have to call PSS to download and will be included with
> > Office 2007 SP1.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Thanks!
> >
> > Tom
> >
> >
> >
> > Thomas W Shinder, M.D.
> > Site: www.isaserver.org <http://www.isaserver.org/>
> > Blog: http://blogs.isaserver.org/shinder/
> > Book: http://tinyurl.com/3xqb7
> > MVP -- Microsoft Firewalls (ISA)
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> > Sent: Friday, August 31, 2007 8:15 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Yep - one listener, two IPs, each IP assigned a
> > different SSL cert.
> >
> >
> >
> > Not sure if the SRV record will negate the need for
> > the autodiscover URL and hence allow us to get away with a
> > single SSL cert - have to check this...
> >
> >
> >
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> > Sent: 31 August 2007 14:13
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> >
> >
> > Hi Jason,
> >
> >
> >
> > One Web listener, but two IP addresses are being used
> > by the Web listener, correct?
> >
> >
> >
> > Thanks!
> >
> > Tom
> >
> >
> >
> > Thomas W Shinder, M.D.
> > Site: www.isaserver.org <http://www.isaserver.org/>
> > Blog: http://blogs.isaserver.org/shinder/
> > Book: http://tinyurl.com/3xqb7
> > MVP -- Microsoft Firewalls (ISA)
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> > Sent: Friday, August 31, 2007 6:50 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Hi Tom,
> >
> >
> >
> > Managed to get this working today too,
> > although I am using two individual certs on the same external
> > web listener. The internal cert on Exchange is SAN'd up and
> > ISA publishes everything to the internal cert common name
> > irrespective of the public URL.
> >
> >
> >
> > The key to most of it working is defining
> > correct URLs in Exchange where is defines "External URLs" for
> > things like OOF, OAB, EWS etc.
> >
> >
> >
> > Now we have all exchange 2k7 services (and
> > all the new funky stuff) working externally...had to do a lot
> > of it by investigation and cobbling blog entries together,
> > not ideal, but go there at last.
> >
> >
> >
> > We currently have it working without SRV
> > records, but just waiting for the ISP to add these records to
> > test if that is a better solution...
> >
> >
> >
> > Cheers
> >
> >
> >
> > JJ
> >
> >
> >
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> > Sent: 31 August 2007 00:32
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> >
> >
> > I'd think that Jim might need to update his
> > SAN article. The article implies that ISA doesn't support
> > SANs on the Web listener, however I have a guy who has the
> > autodiscover FQDN as a second SAN on the certificate bound to
> > his Web listener and he's shown me strong evidence that it
> > actually works, even though it shouldn't.
> >
> >
> >
> > I wish the Exchange or ISA UE teams could get
> > it together to explain how to get autodiscovery working
> > correctly and more importantly, show us how it works with and
> > without DNS SRV records. It looks like once you have DNS SRV
> > records, its a no brainer.
> >
> >
> >
> > Tom
> >
> >
> >
> > Thomas W Shinder, M.D.
> > Site: www.isaserver.org <http://www.isaserver.org/>
> > Blog: http://blogs.isaserver.org/shinder/
> > Book: http://tinyurl.com/3xqb7
> > MVP -- Microsoft Firewalls (ISA)
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> > Sent: Wednesday, August 29, 2007 2:38 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Never mind :)
> >
> >
> >
> > I found it:
> >
> >
> >
> > http://support.microsoft.com/kb/940881
> >
> >
> >
> > Thomas W Shinder, M.D.
> > Site: www.isaserver.org
> > <http://www.isaserver.org/>
> > Blog: http://blogs.isaserver.org/shinder/
> > Book: http://tinyurl.com/3xqb7
> > MVP -- Microsoft Firewalls (ISA)
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From:
> > isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
> > Sent: Wednesday, August 29,
> > 2007 2:35 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA
> > and SAN Certs
> >
> > OK, that's an interesting
> > sentence in a KB OL update article. But there's no mention of
> > this anywhere else on the ms.com site.
> >
> >
> >
> > In addition, how do we
> > configure the SRV records?
> >
> >
> >
> > Service?
> >
> > Protocol?
> >
> > Priority?
> >
> > Weight?
> >
> > Port number?
> >
> > Host offering this service?
> >
> >
> >
> > cid:image001.jpg@01C7F522.ABDB5600
> >
> >
> >
> > I try to read minds best as I
> > can, but I'm flailing on this one :))
> >
> >
> >
> >
> >
> >
> >
> > Thomas W Shinder, M.D.
> > Site: www.isaserver.org
> > Blog:
> > http://blogs.isaserver.org/shinder/
> > Book: http://tinyurl.com/3xqb7
> > MVP -- Microsoft Firewalls (ISA)
> >
> >
> >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx
> > >
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > Sent: Wednesday, August 29,
> > 2007 2:27 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: ISA
> > and SAN Certs
> > >
> > > DatzDeWun! O'curse it
> > works in real life; I tested it.
> > >
> > >
> > http://support.microsoft.com/kb/939184
> > > OL 2K7 seeks a
> > "autodiscovery" SRV record first, and only if
> > > that fails,
> > > it'll seek the A record.
> > This is based on the same domain suffix as
> > > specified in the mail domain.
> > > If your OL client is behind
> > a CERN proxy (and it knows it), it can't
> > > specify that the proxy
> > should look up a SRV record for
> > > autodiscover.sfx.
> > > The proxy assumes that any
> > CERN request will be for a "host"
> > > and makes a
> > > DNS query for an A record.
> > >
> > > OL 2K7 uses the SRV record
> > to discover the host
> > >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx
> > >
> > [mailto:isapros-bounce@xxxxxxxxxxxxx]
> > > On Behalf Of Thomas W Shinder
> > > Sent: Wednesday, August 29,
> > 2007 12:15 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: ISA
> > and SAN Certs
> > >
> > > BAM!!!!
> > >
> > > I think I get it. On the TO
> > tab for the autodiscover.msfirewall.org, I
> > > can still use
> > owa.msfirewall.org since it resolves to the same IP
> > > address as
> > autodiscover.msfirewall.org on the internal network -- and
> > > the path is going to
> > /autodiscover, so that's cool. It's all making
> > > sense on paper -- now to
> > see if it works in real life :)
> > >
> > > BTW -- why do I need a SRV
> > record for OL autodiscovery? I haven't seen
> > > any documentation on that
> > requirement on the Exchange side.
> > >
> > > Thanks!
> > > Tom
> > >
> > > Thomas W Shinder, M.D.
> > > Site: www.isaserver.org
> > > Blog:
> > http://blogs.isaserver.org/shinder/
> > > Book: http://tinyurl.com/3xqb7
> > > MVP -- Microsoft Firewalls (ISA)
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From:
> isapros-bounce@xxxxxxxxxxxxx
> > > >
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > > Sent: Wednesday, August
> > 29, 2007 2:09 PM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] Re:
> > ISA and SAN Certs
> > > >
> > > > Yes; I'd forgotten about
> > the OL client's "SAN problem".
> > > > It amazed me how much
> > noise the Exch folks make about the same
> > > > limitation for ISA..
> > ..but I digress.
> > > >
> > > > "Web Publishing Rule that
> > is publishing the
> > > >
> > autodiscover.msfirewall.org/autodiscover path must be
> > > > configured on the
> > > > TO tab to use
> > autodiscover.msfirewall.org " - how do you
> > > cone to that
> > > > contusion?
> > > > Why do you think you need
> > to use "autodiscover" in the ISA rule
> > > > published hostname? Use
> > whatever works for ISA and let the
> > > > client be as
> > > > stupid as you want.
> > > >
> > > > -----Original Message-----
> > > > From:
> isapros-bounce@xxxxxxxxxxxxx
> > > >
> > [mailto:isapros-bounce@xxxxxxxxxxxxx]
> > > > On Behalf Of Thomas W Shinder
> > > > Sent: Wednesday, August
> > 29, 2007 12:05 PM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] Re:
> > ISA and SAN Certs
> > > >
> > > > Hi Jim,
> > > >
> > > > CIL...
> > > >
> > > > Thomas W Shinder, M.D.
> > > > Site: www.isaserver.org
> > > > Blog:
> > http://blogs.isaserver.org/shinder/
> > > > Book: http://tinyurl.com/3xqb7
> > > > MVP -- Microsoft Firewalls (ISA)
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From:
> > isapros-bounce@xxxxxxxxxxxxx
> > > > >
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > > > Sent: Wednesday, August
> > 29, 2007 1:49 PM
> > > > > To: isapros@xxxxxxxxxxxxx
> > > > > Subject: [isapros] Re:
> > ISA and SAN Certs
> > > > >
> > > > > All good points, but
> > really orthogonal to the question of how ISA
> > > > > handles SAN certs.
> > Actually, I wrote that because some folks were
> > > > > whining about how ISA
> > handled SAN certs in general. In
> > > > fact, I tried
> > > > > not to delve into the
> > variant forms of self-inflicted ISA
> > > manglement
> > > > > pain that were filling
> > other blogs.
> > > > >
> > > > > Q1 - Why do you need a
> > second listener? Use your DNS to point
> > > > > autodiscover to the
> > same Exch listener. The public name is a
> > > > > rule; not
> > > > > a listener arttribute.
> > > >
> > > > TOM: We need a second
> > listener because we can't have two
> > > certificates
> > > > with different common
> > names listening on the same listener using the
> > > > same IP address. OK, in
> > ISA 2006 I *can* use multiple
> > > > certificates using
> > > > the same listener, but
> > each of the certificates must be
> > > assigned to a
> > > > different IP address, so
> > no big deal there -- so I create two
> > > > different
> > > > Web Publishing Rules --
> > one for owa.msfirewall.org and a second Web
> > > > Publishing Rule for
> > autodiscover.msfirewall.org. So far so
> > > > good and SANs
> > > > aren't even an issue.
> > > >
> > > > > Q2 - why does the
> > external OL client give a rats bahootie
> > > > > what's listed
> > > > > in the cert used at the
> > CAS? It never sees it.
> > > >
> > > > TOM: That's true and I
> > didn't mean to imply that it did. The
> > > > concern is
> > > > that common name and the
> > first SAN on the Web site
> > > > certificate bound to
> > > > the Client Access Server
> > site is owa.msfirewall.org. The
> > > second SAN is
> > > > autodiscover.msfirewall.org
> > > >
> > > >
> > > > > Q3 - why is the lack of
> > the autodiscover.suffix public
> > > name make the
> > > > > /autodiscover path
> > "useless"? "Incomplete" perhaps, but
> > > > > hardly useless.
> > > >
> > > > TOM: Because the OWA
> > publishing rule is listening for
> > > > owa.msfirewall.org, NOT
> > autodiscover.msfirewall.org. Since
> > > > there are two
> > > > certificates involved
> > here, one with the common name
> > > > owa.msfirewall.org
> > > > and a second with
> > autodiscover.msfirewall.org -- we have to use two
> > > > different IP addresses,
> > and owa.msfirewall.org is NOT going
> > > to resolve
> > > > to the same IP address as
> > autodiscover.msfirewall.org. Thus,
> > > > adding the
> > > > /autodiscover path to the
> > owa.msfirewall.org Web Publishing
> > > Rule won't
> > > > work and is extraneous.
> > The /autodiscover path only applies to the
> > > >
> > autodiscover.msfirewall.org Web Publishing Rule.
> > > >
> > > > >
> > > > > IOW, create your SRV
> > and A records for autodiscover.suffix, add
> > > > > "autodiscover.suffix"
> > to the public names (ISA 2006 only) and
> > > > > make sure
> > > > > the cert used in the
> > ISA web listener includes
> > > > > "autodiscover.suffix" in
> > > > > the SAN.
> > > >
> > > > Again, the issue isn't
> > with the Web listeners, I have no
> > > problem with
> > > > that. The issue is with
> > the connection between the ISA
> > > > Firewall and the
> > > > Client Access Server. The
> > Web site certificate bound to the Client
> > > > Access Server has a
> > common name and a first SAN name of
> > > > owa.msfirewall.org and a
> > second SAN name of
> > > > autodiscover.msfirewall.org.
> > > >
> > > > Given that, the Web
> > Publishing Rule that is publishing the
> > > >
> > autodiscover.msfirewall.org/autodiscover path must be
> > > > configured on the
> > > > TO tab to use
> > autodiscover.msfirewall.org -- HOWEVER, and
> > > this is THE
> > > > QUESTION -- with the ISA
> > Firewall when establishing the SSL channel
> > > > between itself and the
> > Client Access Server, be able to use
> > > the SECOND
> > > > SAN on the Client Access
> > Server Web site certificate to allow the
> > > > connection?
> > > >
> > > > Make sense?
> > > >
> > > >
> > > > >
> > > > > Jim
> > > > >
> > > > > -----Original Message-----
> > > > > From:
> > isapros-bounce@xxxxxxxxxxxxx
> > > > >
> > [mailto:isapros-bounce@xxxxxxxxxxxxx]
> > > > > On Behalf Of Thomas W Shinder
> > > > > Sent: Wednesday, August
> > 29, 2007 11:33 AM
> > > > > To: isapros@xxxxxxxxxxxxx
> > > > > Subject: [isapros] Re:
> > ISA and SAN Certs
> > > > >
> > > > > This is a good step in
> > understanding some of the issues,
> > > > but I suspect
> > > > > the major problems
> > people are running into relates to
> > > publishing the
> > > > > autodisocvery site.
> > You'll notice that when you run the Exchange
> > > > > Publishing Wizard in
> > ISA 2006 that is includes an
> > > > /autodiscover path,
> > > > > which is completely
> > useless, since the client is looking for
> > > > >
> > autodiscover.domain.com/autodiscover and not the Client
> > > > Access Server
> > > > > Public Name, which
> > would be something like owa.domain.com.
> > > > >
> > > > > OK, easy problem to
> > solve, right? All we need to do is
> > > > create a second
> > > > > Web listener on a
> > second IP address and configure it to listen for
> > > > > public name
> > autodiscover.company.com. HOWEVER, the Client Access
> > > > > Server's common/subject
> > name and first SAN is owa.company.com. The
> > > > > second SAN is
> > autodiscover.company.com.
> > > > >
> > > > > So, if we put on the TO
> > tab autodiscover.company.com, will
> > > > ISA 2006 be
> > > > > able to "consume" the
> > second SAN to support to the Outlook 2007
> > > > > autodiscovery service?
> > > > >
> > > > > Thanks!
> > > > > Tom
> > > > >
> > > > > Thomas W Shinder, M.D.
> > > > > Site: www.isaserver.org
> > > > > Blog:
> > http://blogs.isaserver.org/shinder/
> > > > > Book: http://tinyurl.com/3xqb7
> > > > > MVP -- Microsoft
> Firewalls (ISA)
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From:
> > isapros-bounce@xxxxxxxxxxxxx
> > > > > >
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> > > > > > Sent: Wednesday,
> > August 29, 2007 1:10 PM
> > > > > > To: isapros@xxxxxxxxxxxxx
> > > > > > Subject: [isapros]
> > ISA and SAN Certs
> > > > > >
> > > > > >
> > > > > > Another isablog for
> > your reading pleasure.
> > > > > >
> > > > > >
> > > > > >
> > http://blogs.technet.com/isablog/archive/2007/08/29/certificat
> > > > > > es-with-mu
> > > > > >
> > ltiple-san-entries-may-break-isa-server-web-publishing.aspx
> > > > > >
> > > > > > All mail to and from
> > this domain is GFI-scanned.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > All mail to and from
> > this domain is GFI-scanned.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > All mail to and from this
> > domain is GFI-scanned.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > All mail to and from this
> > domain is GFI-scanned.
> > >
> > >
> > >
> > >
> >
> > All mail to and from this domain is GFI-scanned.
> >
> >
> > All mail to and from this domain is GFI-scanned.
> >
> >
> >
> >
> >
> > All mail to and from this domain is GFI-scanned.
> >
> >
> >
> >
> >
> > All mail to and from this domain is GFI-scanned.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
Other related posts:
