fstinc
asked on
autodiscover certificate error
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.n
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.n
Testing-RPC.docx
Testing-Autodiscover.docx
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.n
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.n
Testing-RPC.docx
Testing-Autodiscover.docx
ASKER
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>
<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>
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.
ASKER
I checked it only shows mail.mailserver.net
ASKER
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?
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"
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"
ASKER
yeah the only thing that it shows is DNS Name=mail.mailserver.net
ASKER
should it show autodiscover.mailserver.ne
ASKER
what should i do?
ASKER
why/how does autodiscover work internally?
ASKER
ha! nevermind - it just came up on outlook internally as well,
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:
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.
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>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.
ASKER
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?
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.