SSL certificate question

BeGentleWithMe-INeedHelp
BeGentleWithMe-INeedHelp used Ask the Experts™
on
I guess I really don't know what I am doing.

Working on an SBS 2011 Standard machine on subnet 192.168.1.0.

There's a vpn to a remote location 192.168.2.0

A new laptop at the remote site with windows 10 / office 2016 keeps getting an error about the autodiscover.domain.com certificate.  It says the name on the security cert is invalid or does not batch the name of the site.

Clicking on view cert, it says it's issued to: domain.com   issued by let's encrypt authority x3 with valid date of 8/14/18 to 11/12/18

WE DO have a certifficate for the domain issued by comodo.  From a browser, if you type remote.domain.com/owa, you get to the owa page and it says it's secured with the comodo cert.

anyone know where the lets encrypt certificate is coming from?

Other laptops at that remote location are working fine for email.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Distinguished Expert 2018
Commented:
The most likely scenario is that the remote site has a DHCP server (router or similar) that is only giving out DNS entries that are "public" DNS servers.  And we have to go back to one of the basic tenets of Active Directory.  Thou shalt not use DNS servers that are not a part of Active Directory.

So you are probably getting the certificate for your public website because there is a wildcard record for *.domain.com that is capturing any and all requests that should be local, and that is hosing autodiscover from working properly.
MASEE Solution Guide - Technical Dept Head
Most Valuable Expert 2017

Commented:
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 : )
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

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?
Distinguished Expert 2018

Commented:
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
Distinguished Expert 2018

Commented:
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?
Distinguished Expert 2018

Commented:
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
Distinguished Expert 2018

Commented:
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
Distinguished Expert 2018

Commented:
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?
David FavorFractional CTO
Distinguished Expert 2018

Commented:
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.
David FavorFractional CTO
Distinguished Expert 2018

Commented:
+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.

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