SSL certificate question

Please check this article. This will help you fix your certificate error issue.
https://www.experts-exchange.com/articles/29657/Exchange-2010-Fix-for-an-Invalid-certificate-and-related-issues.html

Interesting how what I thought was a working system... has so many issues : )

Cliff - as you suspected, IPconfig for this computer (a laptop) is the router at the remote location and it looks like it's giving out 2 public DNS servers.

But being a laptop, it may go home / not be on the remote office LAN at some point and I'd still like it to work. So can we ignore this for now?  Reminds me, there's a hosts file on the machine that includes mail.domain.com 192.168.1.3   and autodiscover.domain.com 192.168.1.3 (the server IP).  Those will break things when the laptop gets off the LAN also.  So pretending this is at a home location, leave the DNS as is and remove the hosts file?

MAS - thanks! my eyes usually gloss over at these long guides on the web for various issues (I have ADD).  But I'm making it through your doc somewhat : )

step 1 - the forward zone is there and has mail.domain.com and autodiscover.domain.com pointing to the server local IP
Step 2 - didn't have to do that
step 3 - suggestion: at the Please use this command to list you SANs/names in the certificate. instruction, you don't say to use the Exchange Management shell. I realized to do that based on the icon in top left corner.

while your Get-ExchangeCertificate | fl Issuer,CertificateDomains  results has 1 line, I have 8?

Besides the comodo cert that has the mail and autodiscover, there's also issuers like CN-domain-mail-ca, A go daddy cert, CN=WMSvc-WIN-SGL3GF28LG9,  and some others, ,  

Which brings up a question - is it good / needed to go through the certificates and delete expired ones?  what about local machine ones?   Is there a wizard to clean those up?  Or manual process?

I love deleting / cleaning up clutter... but also afraid to break things : )

step 4 - Again, where you got 1 line, I got 8.  some have just dots, only one has all IPWS as your example.  And they run off the right side of the screen. Even sending the command to a text file gets the dots on the right side of a line:

97E1B19F930EF72D05E00913B3D8FD9B7E723568  IP..S.     CN=remote.domain.com, OU=PositiveSSL, OU=Domain Control V...
280DED6F93F61837B90C63FFAA1AC75D440FFB74  IP.WS.     CN=mail.domain.com, OU=PositiveSSL Multi-Domain, OU=Domai...
FA462E456B5B6239FFFE1D67800BD065BF41DF16  ......     CN=MAIL.domain.local                                        
E82FC3C01D179AD0BC0775118B280318C92B8006  IP..S.     CN=remote.domain.com                                        
E5CC6ED14BAF1DA3BD0E7AB094B24BBC7480E62B  ......     CN=domain-MAIL-CA                                          
9DB75E0DAB7842A3C14A2932A04D2A5C25CB7D7D  IP..S.     CN=remote.domain.com, OU=Domain Control Validated          
CFA598797C7EBF49F6BEF863AEB1F98CF03A3CA0  ......     CN=WMSvc-WIN-SGL3GF28LG9                                          
4906C7F8A73E914CAB0FEA52A4F0584708654D88  ......     CN=domain-MAIL-CA          

(the server has the name mail AND remote.  They are both in the comodo cert, DNS / seem to be interchangable)

also in step 4, you talk about exchange 2010 and assigning the cert.  What app / snap in are you using for that?

I'm stopping here to wait to hear back before I break something : )

re the last question - is that certificates or certificate authories snap in?

re my last comment : certificate authority - not needed / used since that's for self signed certs, right?  There is the domain-mail-ca listing under there.  Can / should I just delete it?

As long as your DNS is wrong, you will have inexplicably bad behavior.

You have a couple of choices:

1) Edit your remote DHCP server to use a local DNS server that has zones for AD.
2) Edit your remote DHCP server to use a DNS server over the VPN.  

(both of these allows the laptop to "work from home")

3) Create public DNS records for autodiscover.domain.com *and* configure that service to be accessible (aka port forwarding) from the a public IP, and assign a public certificate for autodiscover.domain.com to the service.

OK, I can do those changes on the router (or at least as a test, just put the IP of the DNS server at the home office (across the VPN) into network settings on that laptop...

But how is the current arrangement different from when the laptop is in a coffee shop / gets a public DNS server

Which is where option #3 comes in.  You need to publish a public A record for autodiscover and have that point to a public IP address that acan reach the exchange server somehow.

If you bought "domain.com" and mail is getting to you then  you have a public DNS server/service *somewhere.*  That's where you create the records.

And no, host files often don't work in these scenarios.

thanks. I have an a record for autodiscover.domain.com pointing to the exchange server IP, just like mail.domain.com.  That's been set up.

but to know if the autodiscover.xml file is in the right place / the file has the right info / the correct services on the server are running?

from my house I can ping autodiscover.domain.com... it resolves to the server IP but don't get a reply but that's how the firewall is set.

I can type autodiscover.domain.com/owa from my house and it gets the login page.  and chrome says the page is secure with the correct comodo cert.

If I type autodiscover.domain.com/autodiscover/autodiscover.xml (I saw that URL as part of the microsoft connectiviity test), I get this page:

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response>
<Error Time="18:26:43.8422649" Id="2053059689">
<ErrorCode>600</ErrorCode>
<Message>Invalid Request</Message>
<DebugData/>
</Error>
</Response>
</Autodiscover>

is there a wizard I need to run or something else to correct autodiscover?

No. And you won't get a valid XML if you try manually.  Outlook does "stuff" (HTTP Post as I recall) that you can't mirror with a browser string (which is always an HTTP GET) and is why you can't just fake it with XML on another server.

The remote connectivity analyzer should account for this, but you didn't post the autodiscover.domain.com results (note that the analyzer may test multiple methods and not all need to succeed, but autodiscover.* will be the first method attempted and should succeed WITHOUT warnings.)

I searched autodiscover.xml /s from the root of the C drive on the server and came up with 2 instances of that file. Both dated from 2010.

both have this text in them:

<%@ServiceHost Service="Microsoft.Exchange.Autodiscover.WCF.LegacyAutodiscoverService" %>


These are the 2 files.  There's a D drive also, but searching that drive didn't find any autodiscover.xml.  

These 2 paths aren't the correct ones for them to be accessible at autodiscover.domain.com/autodiscover/autodiscover.xml, right?


 Directory of C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover
07/30/2010  09:21 PM                89 Autodiscover.xml

 Directory of C:\Program Files\Windows Small Business Server\Bin\CMPNENTS\EXCHANGE14_SP1\Setup\ServerRoles\ClientAccess\Autodiscover

07/30/2010  09:21 PM                89 Autodiscover.xml

Your chasing a red herring by looking for static files.  Don't worry about them.

Here's the microsoft  connectivity test.  it doesn't go to autodiscover.domain.com first. it just goes to domain.com/autodiscover/autodiscover.xml, the files not there, but it resolves the IP (of the web server), checks the ssl cert (of the web server), then does the same for autodiscover.domain.com/autodiscover/autodiscover.xml

That also fails, but it resolves the IP, checks the cert, etc....

Seems backward - going to autodetect.domain.com first would make sense.
autodiscover.pdf

The power test is what matters. Does that IP address match? If so that 401 is the issue. Which pretty clearly states is an authentication error. First guess is you are trying to authenticate using some@email.address.com which doesn't ketch the account UPN which is actually account@ad.name.local

So if authentication fails., auto discover won't expose sensitive server info to an unauthenticated client.

Thanks.. been banging on this for hours now : (  Gotta get them to move to office 365 : )

Been noticing this in the microsoft connectivity test:

Attempting to resolve the host name autodiscover.domain.com in DNS.
       The host name resolved successfully.
      Additional Details
IP addresses returned: 192.185.147.155
Elapsed Time: 32 ms.

that IP is NOT the correct IP. That .155 is the web server.  I enter autodiscover.domain.com in https://dnschecker.org/ and it comes back correctly to the exchange / SBS server for all locations that website tests for. I ping that FQDN and it comes back correctly.

Microsoft cached the wrong IP? the zone has all the records set at 14400, which is 4 hours. I guess just go to sleep and try it again tomorrow? I'd think microsoft would clear the cache for each test?

Difficult to answer precisely without an actual domain name.

For example, you mention "keeps getting an error about the autodiscover.domain.com certificate" in the beginning.

To fix this visit https://ssllabs.com/ssltest + fix the cert associated with either...

1) host cert for autodiscover.domain.com

2) wildcard cert for domain.com

Tip: Use https://LetsEncrypt.org for free certs which can be auto-renewed via nightly CRON job.

Wow! Lots of info at https://www.ssllabs.com/ssltest

BEtween that and some other things, it doesn't seem to be an SSL cert issue (at least not now)....

Using:

https://www.priasoft.com/autodiscover-testing-tool/ on my home network (not on the server's lan)

There's 2 lines:  Mailbox SMTP which I enter user@domain.com.

Then there's the authenticate as entry, which I intiially typed user@domain.com.  I'd get a 401 error.

Trying domain\user, Then I get an autodiscover reply...

I just tried outlook on the laptop at location 2 with the DNS server pointing to the domain controller across the VPN.  Outlook is now working / autodiscover worked.

So:  Thanks for the advice to change the DNS server to the domain controller.

But would autodiscover have worked on that laptop if it wasn't on the company network / had a public DNS server?  And maybe outlook on a non domain joined computer?

How do I control what outlook uses for the authenticate as field? Why does user@domain.com NOT work to authenticate (at least at my house / non-domain joined computer.

+1 for your moniker BeGentleWithMe-INeedHelp.

Just to be clear. SSL only works on public sites (host or domain) with a resolvable IP.

To have SSL work, you'll require hosting somewhere + a site (host or domain) which resolves to an IP, then setup an SSL cert, then proceed with your project.