mikeshaver
asked on
The name on the security certificate is invalid or does not match the name of the site
I have an Exchange 2010 server with the domain of www.mydomain.com. I have clients on this server, using email addresses such as user@notmydomain.com, and otheruser@someotherdomain. com.
I have an SSL certificate installed from GoDaddy for mail.mydomain.com. Its not a UCC certificate. Just the single domain. OWA works fine, no error messages and clients connect to it via https://mail.mydomain.com/owa
Issue is within Outlook 2007 or 2010. When offsite clients (not connected to the domain system) connect to Outlook using Outlook anywhere, they receive the "Security Alert" about the certificate not matching the name of the site, for the domain autodiscover.notmydomain.c om.
The message makes sense, because the name doesn't match...because their email addresses are on a different domain (user@notmydomain.com), but the certificate is for mail.mydomain.com
If the client clicks "YES" at the "do you want to proceed" everything works fine...
I tried installing the certificate to the client machines into the trusted root certification authority but the error still persists for these clients.
I would change to a UCC certificate to include autodiscover.mydomain.com, however I don't think this will solve the issue...?
Tips?
I have an SSL certificate installed from GoDaddy for mail.mydomain.com. Its not a UCC certificate. Just the single domain. OWA works fine, no error messages and clients connect to it via https://mail.mydomain.com/owa
Issue is within Outlook 2007 or 2010. When offsite clients (not connected to the domain system) connect to Outlook using Outlook anywhere, they receive the "Security Alert" about the certificate not matching the name of the site, for the domain autodiscover.notmydomain.c
The message makes sense, because the name doesn't match...because their email addresses are on a different domain (user@notmydomain.com), but the certificate is for mail.mydomain.com
If the client clicks "YES" at the "do you want to proceed" everything works fine...
I tried installing the certificate to the client machines into the trusted root certification authority but the error still persists for these clients.
I would change to a UCC certificate to include autodiscover.mydomain.com,
Tips?
ASKER
If I get the UCC certificate, can I add ALL the domains to it, like this:
mail.mydomain.com
autodiscover.mydomain.com
autodiscover.otherdomain.c om
autodiscover.differentdoma in.com
autodiscover.yetanotherone .com
Etc?
And will this prevent the error on all clients? Or would I still have to setup something else?
mail.mydomain.com
autodiscover.mydomain.com
autodiscover.otherdomain.c
autodiscover.differentdoma
autodiscover.yetanotherone
Etc?
And will this prevent the error on all clients? Or would I still have to setup something else?
the domain name you have removed is it @mydomain.com or @notmydomain.com ?
ASKER
Its @notmydomain.com (but it does the same thing for autodiscover.mydomain.com as well).
the ucc certificate will solve the @mydomain.com not the @myotherdomain.com
is autodiscover.mydmain.com and autodiscover.notmydomain.c om resolvale in dns?
is autodiscover.mydmain.com and autodiscover.notmydomain.c
ASKER
Damn on the UCC thing. Thought I could throw some money at this and make it go away.
Yes, autodiscover.notmydomain.c om can be resolved in DNS. I created an A record for it. It resolves to the IP of my mail server at mail.mydomain.com
Yes, autodiscover.notmydomain.c
well remove it from DNS and it will go away....
ASKER
Yes, but then I assume the autodiscover services won't work for myotherdomain.com, and thus I won't be able to use Out of office replies? (I was getting a "server not found" from Out of Office before I went down the configuration of autodiscover path...)
?
?
it is not working now anyway :)
it won't work if it is not trusted
here is what you can do to solve your problem without putting money on the UCC certificate
replace both A records for autodiscover with srv records pointing to mail.mydoamin.com
it won't work if it is not trusted
here is what you can do to solve your problem without putting money on the UCC certificate
replace both A records for autodiscover with srv records pointing to mail.mydoamin.com
ASKER
OK, so just so I am clear...I should:
At my DNS provider (GoDaddy):
1 - Erase the A record for autodiscover.mydomain.com which is currently pointing to the IP of the mail server.
2 - I already have an SRV record with the following which I will leave intact?:
service: _autodiscover
Protocol: _tcp
Name: mail (this is the netbios name of my server)
Priority and weight: 0
Port: 443
Target: mail.mydomain.com
TTL: 1 hour
3 - In the DNS manager for otherdomain.com, remove the A record for autodiscover which points at the IP of the mail server for mail.mydomain.com
4 - I already have an SRV record for myotherdomain.com with these settings, I leave this intact as well?
service: _autodiscover
Protocol: _tcp
Name: mail (this is the netbios name of my server)
Priority and weight: 0
Port: 443
Target: mail.mydomain.com
TTL: 1 hour
I would repeat step 4 for every otherdomain such as myotherdomain.com, differentdomain.com etc?
Yes/No/Maybe so?
At my DNS provider (GoDaddy):
1 - Erase the A record for autodiscover.mydomain.com which is currently pointing to the IP of the mail server.
2 - I already have an SRV record with the following which I will leave intact?:
service: _autodiscover
Protocol: _tcp
Name: mail (this is the netbios name of my server)
Priority and weight: 0
Port: 443
Target: mail.mydomain.com
TTL: 1 hour
3 - In the DNS manager for otherdomain.com, remove the A record for autodiscover which points at the IP of the mail server for mail.mydomain.com
4 - I already have an SRV record for myotherdomain.com with these settings, I leave this intact as well?
service: _autodiscover
Protocol: _tcp
Name: mail (this is the netbios name of my server)
Priority and weight: 0
Port: 443
Target: mail.mydomain.com
TTL: 1 hour
I would repeat step 4 for every otherdomain such as myotherdomain.com, differentdomain.com etc?
Yes/No/Maybe so?
1- ok
2-
service: _autodiscover
Protocol: _tcp
Name: @
Priority and weight: 0
Port: 443
Target: mail.mydomain.com
TTL: 1 hour
3. create the same record that in 2
2-
service: _autodiscover
Protocol: _tcp
Name: @
Priority and weight: 0
Port: 443
Target: mail.mydomain.com
TTL: 1 hour
3. create the same record that in 2
ASKER
Kinda makes sense...
Your point 1 is clear obvioulsy, delete the A record for autodiscover.mydomain.com
On Point 2, we are still talking about the SRV record for mydomain.com, correct?
As for point 3, that is refering to otherdomain.com, where I change the SRV record to be identical to the SRV record for mydomain.com
Yes?
Your point 1 is clear obvioulsy, delete the A record for autodiscover.mydomain.com
On Point 2, we are still talking about the SRV record for mydomain.com, correct?
As for point 3, that is refering to otherdomain.com, where I change the SRV record to be identical to the SRV record for mydomain.com
Yes?
yes but in your SRV record the name is @ not netbios name of computer
ASKER
Got that. Thanks.
And I still remove the A record for autodiscover in ALL domains, including mydomain.com and otherdomain.com
If so...I'm going to try it...?
And I still remove the A record for autodiscover in ALL domains, including mydomain.com and otherdomain.com
If so...I'm going to try it...?
yes remove all the A records and replace them with SRV records
the easiest way is to test with a domain that has no A record to avoid dns replication time
the easiest way is to test with a domain that has no A record to avoid dns replication time
ASKER
Great, will try it now and post back!
ASKER
Once DNS settings are updated/propogated, should a ping to autodiscover.myotherdomain .com and autodiscover.mydomain.com resolve and reply? I would assume so?
no :) it is an SRV record not a cname record
nslookup _autodiscover._tcp.otherdo main.com
should give back some info with mail.mydomain.com at the end
nslookup _autodiscover._tcp.otherdo
should give back some info with mail.mydomain.com at the end
ASKER
I added the SRV to a domain that didn't have the autodiscover A record in place before. As well as removing the A record for autodiscover.mydomain.com
NSlookup that you gave above gives back:
Name: _autodiscover._tcp.otherdo main.com (nothing more?)
NSlookup that you gave above gives back:
Name: _autodiscover._tcp.otherdo
ASKER
Just reran the nslookup and got this:
*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available
for _autodiscover._tcp.myother domain.com
Maybe I just need some patience?
*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available
for _autodiscover._tcp.myother
Maybe I just need some patience?
ok try
nslookup
set type=srv
_autodiscover._tcp.myother domain.com
nslookup
set type=srv
_autodiscover._tcp.myother
ASKER
That worked!
Just remoted into my client machine at myotherdomain.com, and there was an outlook popup asking to allow the server to configure the client. Clicked OK and checked the box to not ask again.
No cert errors!
Awesome! Thanks for the huge help!
Just remoted into my client machine at myotherdomain.com, and there was an outlook popup asking to allow the server to configure the client. Clicked OK and checked the box to not ask again.
No cert errors!
Awesome! Thanks for the huge help!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Awesome!!!!
Refer this article:
http://support.microsoft.com/kb/940726
and verfiy your settings.
NOte: Better to have UCC Certificate.
Hope this helps,
Shree