autodiscover certificate error

fstinc
fstinc used Ask the Experts™
on
I installed a public ssl certificate on my server. first i was getting a bunch of certificate errors, so i did this > http://support.microsoft.com/kb/940726

that solved most of the except now i keep getting a "autodiscover.domain.net" error ONLY when running outlook outside the network on a laptop. Internally seems to work fine.

"autodiscover.mailserver.net"

the security is from a trusted authority (passed)
the cert date is valid (passed)
the name on the security certificate is invalid or does not match the name of the site (failed).

I've attached a couple of test results. it mentions something not having a valid ssl. I'm pretty sure i selected autodiscover.emailserver.net when i ordered it. so not sure why it's saying that it's invalid.
Testing-RPC.docx
Testing-Autodiscover.docx
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Jim MillardSenior Solution Engineer

Commented:
Although you feel confident that you ordered the cert correctly, please use a browser to check the certificate that's being delivered to external systems.
Open the following URL in a browser that's on the outside network: https://autodiscover.mailserver.net/AutoDiscover/AutoDiscover.xml

Don't worry about receiving an invalid response in the XML data; that's to be expected when you aren't using OLK and authenticating.

With luck, you'll get a cert error, too. That means you're replicating the problem that both OLK and the ExRCA is reporting.

Acknowledge the error and proceed to the page. Once there, use your browser's certificate viewer to inspect the certificate details. The item you're looking for is the "Subject Alternative Names" (SAN) record. This record will list all the DNS names that the certificate will seamlessly protect, not just the Common Name that is the primary DNS for the cert.

If you don't see the autodiscover.mydomain.net or mydomain.net names, you will have discovered the root of your problem.

Note from the ExRCA results that the first thing that's tested is https://mydomain.net/, followed by https://autodiscover.mydomain.net/

You also have the options to try and work up the HTTP redirect method, which requires you to have the special DNS name redirected to the URL that is listed in the cert. Last, you can create a DNS SRV record to point to a DNS name listed in the cert.

My recommendation is to get the cert corrected so that it has the correct SAN names.

Author

Commented:
i get this:

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response>
<Error Time="20:32:56.1575517" Id="3007185755">
<ErrorCode>600</ErrorCode>
<Message>Invalid Request</Message>
<DebugData/>
</Error>
</Response>
</Autodiscover>
Jim MillardSenior Solution Engineer

Commented:
As I indicated, that error is to be expected. Once you have that screen, you need to look at the browser's certificate details, specifically the "subject alternative names" record.

Author

Commented:
I checked it only shows mail.mailserver.net

Author

Commented:
am confused because when i ordered the cert - it had several other domains that were going to be protected, including internal dns names. but it only shows the common name?
Jim MillardSenior Solution Engineer

Commented:
The "Common Name" (CN) is a different record from the "Subject Alternative Name" (SAN). You will see the value for the CN included in the SAN list; it will be the only entry on a basic cert, but one of several on a multi-line SAN cert.

Take a look at the cert for facebook.com, and you'll see what I mean. The CN is "www.facebook.com", but the SAN has records for both "www.facebook.com" and "facebook.com"

Author

Commented:
yeah the only thing that it shows is DNS Name=mail.mailserver.net

Author

Commented:
should it show autodiscover.mailserver.net too?

Author

Commented:
what should i do?

Author

Commented:
why/how does autodiscover work internally?

Author

Commented:
ha! nevermind - it just came up on outlook internally as well,
Jim MillardSenior Solution Engineer

Commented:
The ideal is to have the certificate's common name (which is used when the CSR is created for submission to the CA) set to the public name of the mailserver. That public name can be anything, but it should be whatever you're going to use in your highest-priority MX record for the domain.

The SAN record should then include--at a minimum--the following:
1) autodiscover.mydomain.net
2) internal.name.of.host

That's if you're going to go the route of using a SAN certificate. Autodiscover will permit the two other methods discussed above: HTTP redirect and DNS SRV records. HTTP redirect requires you to put a new default page that will be delivered whenever a client tries to connect w/o using SSL:
<html>
<head>
<title>HTML Redirection to https:</title>
<META HTTP-EQUIV="Refresh"
CONTENT="1; URL=https://mail.mailserver.net/">
</head>
<body>
This page is attempting to redirect you to <a href="https://mail.mailserver.net
/">https://mail.mailserver.net</a><br>
If you are not redirected within a few seconds, please click the link above to access Outlook Anywhere Autodiscover.
</body></html>

Open in new window

If you go that route, you'll also need to tweak the permissions on the default page so it can be delivered to anonymous connections.

The other route--assuming you have access to your DNS domain records--is to create a special SRV record in the mailserver.net zone:

_autodiscover._tcp SRV mail.mailserver.net.

Author

Commented:
no, i think i will just start over.

what steps should i take?

1) delete current cert from exchange.  Is there any cleaning up to do (EMC or through shell) after deleting cert?

2) get new cert and start the whole process from scratch?
Senior Solution Engineer
Commented:
Removing the cert from Exchange won't necessarily delete the cert from the system. I usually manage the certs from IIS Manager, then use EMC to select the correct cert to use for the various services. Keep that part in mind: just because the cert is properly installed on the system doesn't mean that all services will automatically use it.

Don't delete the old cert until you have the new cert in place. Anyone using the system will immediately have errors of one flavor or another if there's no cert associated with various services, and it doesn't hurt to have multiple certs on the system. Only one cert can be used by a given service at any time, so you just move things around as needed, and delete the old cert only once everything is reconfigured for the new one.

By using IIS, it's also easy to make sure you've got the details correct: add the cert to IIS, change the bindings of the Default Web Site to use the new cert for port 443, then browse the default page for the host. If you use "https://localhost", you'll get the cert error, but once you get to the page, you can review the details like before. If you see the SAN entries you expect, proceed with changing the other bindings in IIS, then jump over to EMC and change the certificate being used by the other server services.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial