Solved

UCC Cert errors

Posted on 2014-02-06
31
328 Views
Last Modified: 2014-02-15
Good morning Experts!

I'm currently running into an issue that I am having a hard time finding the resolution to.

2 years ago in Feb., I purchased a UCC Security Cert from Starfield which contained 4 Subject Alternative Names (SAN) both internet and intranet domain names.  Well you could probably guess where I'm going with this.  In July of 2012, the certificate industry made a significant change to disallow the use of intranet domains as a SAN.  Fast forward 2 years to today I go to renew my cert and had to do so without our intranet domain name.  I figure it was not a problem since I already have local self signed certs using Microsoft CA.  Well it is a problem.  Now I get the dreaded "Security Alert" window every time you open Outlook.  

I contacted Starfield and after a long explanation (since the person I was talking to had no clue what I was talking about) let me know of the change and how to avoid the issue by sending me a KB article.

The article directed me to create a local dns zone that mimicked our public dns zone. Fortunately I had already done that to make sure there was only one OWA, EWS, etc., site for all services.  The article also had me reconfigure Exchange's internal url's to point to our internet FQDN as opposed to our intranet FQDN.

After doing all of this, it still does not work. Something is still trying to communicate to the new cert but using our intranet FQDN.  I can't find the culprit.



Any assistance would be greatly appreciated!
0
Comment
Question by:40hz
  • 16
  • 13
  • 2
31 Comments
 

Author Comment

by:40hz
ID: 39839057
Also, I have verified that the following Virtual Directories are pointing to the public domain:

OAB
Autodiscover
EWS
UM
ECP
OWA
Active Sync

Could my DNS zone be the problem?  I am using a CNAME record mail.publicdomain.com -> server.domain.local
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39839076
Hello,

What is the error that you are getting?
What is your Exchange version?

From outlook client, on taskbar hold ctrl and click on the outlook icon on a client machine,

outlook control config to test outlook connection.

Did you create "autodiscover"  A record as well in your split dns?

What does your domain.com DNS zone look like?
0
 

Author Comment

by:40hz
ID: 39839136
I've attached the security cert error.

Cert Error
We're using Exchange 2010 with Outlook 2013.  I've previously ran the AutoConfiguration and Connection Status and all was well.  Nothing stood out and there were no errors in configuration.

I ran a script that assisted me in changing ALL of the virtual directories to point to the internet domain name that I found in a previous answer.

http://nathanwinters.co.uk/2010/05/30/script-to-set-internalurl-and-externalurl-for-all-exchange-2010-virtual-directories/

It only made one change, which was to the UM virtual directory, we are not currently using UM.

Thanks!
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39839160
What about your split DNS, can you post your records?

Also output from "test email autoconfig" please.

Your dns should look something like:

domain.com

mail/remote/email (external name for your exchange).. internal exchange IP
autodiscover.......internal exchange IP
www....external IP of your website etc
0
 
LVL 5

Assisted Solution

by:Jullez
Jullez earned 500 total points
ID: 39839208
Also:

To make sure all your directories are correct:


Check EWS: Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl

Both internal and external need to point to your external url.

To set: Set-WebServicesVirtualDirectory -Identity “yourexchange\EWS (Default Web Site)” -InternalUrl https://mail.domain.com/EWS/Exchange.asmx -BasicAuthentication:$true

same for external if needed.

Get-AutodiscoverVirtualDirectory

To see the settings

Get-ClientAccessServer |fl identity,autodiscoverserviceinternaluri

To fix:

Set-ClientAccessServer -Identity yourexchange -AutoDiscoverServiceInternalUri https://mail.domain.com/Autodiscover/Autodiscover.xml
0
 

Author Comment

by:40hz
ID: 39839234
publicdomain.com
  --mail.publicdomain.com (MX) -> server.privatedomain.com
  --mail.publicdomain.com (A) -> 192.1.1.1
  --autodiscover.publicdomain.com (CNAME) -> server.privatedomain.com

AutoConfig-XML-Log.txt
0
 

Author Comment

by:40hz
ID: 39839240
I'm starting to think, it has something to do with the public folders as that is the only record in the log that points to server.privatedomain.local

I have verified that all virtual directories are pointing to the correct location.
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39839247
In your DNS forward zone for your publicdomain.com

A record autodiscover---------internal IP
A record mail----------internal IP
www-------external IP (your web host for your website)


Should be all set after that.
0
 

Author Comment

by:40hz
ID: 39839251
Interestingly enough when I run the command:

Get-AutodiscoverVirtualDirectory

I get the following output:

Name                                                  Server                                  InternalUrl
----                                                       ------                                  -----------
Autodiscover (Default Web Site)         <servername>

but when I run:

Get-ClientAccessServer |fl identity,autodiscoverserviceinternaluri

I get the following output:

Identity                       : <servername>
AutoDiscoverServiceInternalUri : https://mail.publicdomain.com/Autodiscover/Autodiscover.xml
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39839265
So Get-AutodiscoverVirtualDirectory gives you an empty field in InternalUrl?
0
 

Author Comment

by:40hz
ID: 39839289
Yes sir, totally empty.  

I have changed the autodiscover A record to point to the IP address and still no resolution.

I left the mail A record alone since it was already pointing to the IP address.

Should I change the MX record to also point to the IP address?
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39839326
Try to run:

Get-AutodiscoverVirtualDirectory -server <yourserver>  | Set-AutodiscoverVirtualDirectory -InternalUrl 'https://mail.publicdomain.com/Autodiscover/Autodiscover.xml' -ExternalURL 'https://mail.publicdomain.com/Autodiscover/Autodiscover.xml'


You can remove the MX record, never had to set it for any of my clients in spint dns, how is your send connector configured?
0
 

Author Comment

by:40hz
ID: 39839371
I ran the cmdlet and now when I run:

Get-AutodiscoverVirtualDirectory

It does show the internal url as: mail.publicdomain.com.

When I close and open Outlook, I no longer get the error message. But when I ask a client to check, they still get the error.
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39839398
Can they close outlook, make sure it is not running in "Task manager" then open it again please?
0
 

Author Comment

by:40hz
ID: 39839411
I just got back from having them try that along with programs dependent on Outlook - FAIL.

I had them restart their computer as well and still to no avail.  

I'm going to do an iisreset /noforce on the exchange server and see if that changes anything.
0
Are end users causing IT problems again?

You’ve taken the time to design and update all your end user’s email signatures, only to find out they’re messing up the HTML, changing the font and ruining the imagery. What can you do to prevent this? Find out how you can save your signatures from end users today.

 
LVL 5

Expert Comment

by:Jullez
ID: 39839484
On that client machine, run the "test email autoconfig", see where is it pointing.

If you view certificate from the error you are getting, is it the right certificate?

Are you getting  SSL Certificate error when browsing owa inside your network?
0
 

Author Comment

by:40hz
ID: 39839586
When I run the autoconfig test, the only anomalies that are pointing internally are these:

<Server>exchangeserver.privatedomain.local</Server>

<PublicFolderServer>exchangeserver.privatedomain.local</PublicFolderServer>

<AD>domaincontroller.privatedomain.local</AD>

Yes, it is indeed the right certificate but it is still looking for a private fqdn.  But I do not get any errors going through OWA.
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39839598
And on your cert you have autodiscover listed as alternativel name, correct?
0
 

Author Comment

by:40hz
ID: 39839614
No, the main name of the cert is autodiscover, I have mail.publicdomain as one of the alt names
0
 

Author Comment

by:40hz
ID: 39839657
I went into IIS of the server and saw these binding entries for the Default Web Site.

Type   HostName   Port   IP                 Cert
http     <blank>       80      127.0.0.1
https   <blank>      443      127.0.0.1    autodiscover.publicdomain.com
http     <blank>       80      *
https   <blank>      443      *                 autodiscover.publicdomain.com

I've lost my marbles on this error.  It's gotta be something simple and easily overlooked.
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39839955
Bindings look correct.

Certificate shows up under Server configuration in Exchange management console with SMTP, IMAP, IIS services I assume?

So we checked - dns - a records for mail and autodiscover only (for now), no cname or mx records.

When running nslookup on client machine for mail.publicdomain.com - resolves to internal IP?

EWS, Autodiscover, Outlook Web Apps, Exchange Control Panel, Exchange ActiveSync, Offline Address book, all setup correctly.
0
 

Author Comment

by:40hz
ID: 39840144
Yes the certificate does indeed have SMTP, IMAP and IIS associated to it.

I do have an MX record that is pointing to ExchangeServer.PrivateDomain.local.

I've ran nslookup on a computer that does work vs one that does not and I get the same error.

I'm starting to think a server reboot is the next best thing.

I thought that maybe if I delete a users .OST file would help and it did on one computer/account but failed on another computer/account.
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39840293
In your publicdomain.com DNS Zone on your AD server, make sure you only have the 2 A records - mail and autodiscover, pointing to the internal IP.
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 39841430
Oh dear.
The postings in this question are just wrong on so many levels.

This suggestion was completely wrong.

Get-AutodiscoverVirtualDirectory -server <yourserver>  | Set-AutodiscoverVirtualDirectory -InternalUrl 'https://mail.publicdomain.com/Autodiscover/Autodiscover.xml' -ExternalURL 'https://mail.publicdomain.com/Autodiscover/Autodiscover.xml'

The URLs on the Autodiscover virtual directory are not used and should be left blank.
You also do NOT need an internal Autodiscover record unless you have clients on the LAN who are not members of the domain.

If the certificate was installed correctly, then you need to make changes within Exchange and the AD to work with the external name.
I have outlined them here:
http://semb.ee/hostnames

You also MUST deploy a split DNS system so the external host name resolves internally to Exchange.
http://semb.ee/splitdns

That is all that is required, nothing else.
The one that you are probably being caught out on is Autodiscover internally:

get-clientaccessserver | select identity, autodiscoverserviceinternaluri

The internal clients query that value rather than doing a DNS lookup. Then they go to that address. If that is still the .local value then that is the root of your problems. The link I have provided above will show you how to correct it.

Simon.
0
 

Author Comment

by:40hz
ID: 39841813
@Simon- Thank you for chiming in.  I thoroughly read both of the pages that you linked to and all appears to be in order.  I still am getting the same issue.  The only changes that I applied were in DNS: removing the AD replication of my zone and deleting the MX record.

@Simon- How do I revert the following:

Get-AutodiscoverVirtualDirectory -server <yourserver>  | Set-AutodiscoverVirtualDirectory -InternalUrl 'https://mail.publicdomain.com/Autodiscover/Autodiscover.xml' -ExternalURL 'https://mail.publicdomain.com/Autodiscover/Autodiscover.xml'

@Simon- The Exchange powershell will not allow me to set it back to <blank>.

There are a couple of things I noticed but I'm unsure if they are related.

1.  The security alert is a per user problem.  I myself have stopped receiving the error but that does not speak for the rest of the users.  I can log onto another workstation and still not get the alert.  However if another user logs into the same computer using their account and profile, they receive the error.

2.  When using cached exchanged mode; Outlook is stuck on "Updating  Address Book"

I found the below resolution from another forum and it would appear to be similar but I feel like I am chasing my own tail on this one but I'm running out of options.  

Problem:

Users on the Exchange Server "MAIL" using Outlook 2010 client are unable to download OAB and hence the GAL is not being updated.

Environment:

Exchange Server 2010 SP2 running on Windows Server 2008 R2 SP1.

Resolution:

• We opened the IIS manager and found that the Authentication permissions for the Exchange related virtual directories were correct.

• We then found that there was improper redirection for OWA set on the "Default Web Site" and it was also inherited on "OAB" and other Exchange related virtual directories which we removed it.

• In IIS Manager, we highlighted the Default Web Site (DWS) and on the center pane, clicked on contents view. We then right click on iisstart.htm and then selected "Switch to features view". Then on the left hand side, clicked on iisstart.htm and selected HTTP Redirect option in the Features View. We set the redirection and made sure that we selected the option ‘Only redirect requests to content in this directory (not subdirectories)’ and applied the changes. We returned back to the Default Web Site and selected Default Document in the features view. We selected the "iisstart.htm" listed over there and moved it to the very top. We removed SSL from all the virtual directories as he wanted HTTP to HTTPS redirection. We performed iisreset and OWA redirection worked.

• We then restarted the Microsoft Exchange System Attendant and Microsoft Exchange File Distribution Service.

• We then tried to download OAB and it succeeded. We then checked the global address list and it got updated contacts.

Open in new window


Any suggestions anyone?  The simple tasks are never the easy ones.  Thank you both for your help thus far!
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 39842020
This command should work:

Get-AutodiscoverVirtualDirectory -server <yourserver>  | Set-AutodiscoverVirtualDirectory -InternalUrl $null -ExternalURL $null

On the users with the problem, check that they have permission inheritance enabled in ADUC. That is a common cause of these problems. Exchange basically cannot "read" the account correctly.

Simon.
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39842172
40hz,

Having these settings is not bad, just not necessary, it will not break anything having them set and its not wrong having them set.

You can read about it here:
 http://blogs.technet.com/b/rmilne/archive/2013/04/02/busting-the-set-autodiscovervirtualdirectory-myth.aspx

If you are having an issue with permissions the cause would be that at some point the user was part of an admin group, their admincount attribute will be flagged with "1" and they won't be able to inherit permissions. To fix the problem for a user object, you have to reset its admincount attribute to 0 (zero) and then check the “Include inheritable permissions from this object’s parent” box.

If you don’t reset admincount, and just check the "Include inheritable permissions" box in Advanced security settings for that user, it will work until the next time that SDPROP runs (every 60 seconds), the box will be cleared.

To find all the users that are flagged you can run this in "windows Power Shell"

Import-Module ActiveDirectory
Get-ADUser -LDAPFilter "(objectcategory=person)(samaccountname=*)(admincount=1)"


Then if the user is flagged, use ADSIEdit to set it to "0", after that you can open "Advanced Security Settings" in AD for that User and check the "inherit permissions" check box.
0
 
LVL 5

Expert Comment

by:Jullez
ID: 39842238
Here is a list of why some accounts got flagged as admins: (One of my clients had all of the users in Printer operators group, that was an interesting 2003 - 2013 Exchange migration)

Account Operators
Domain Admins
Enterprise Admins
Administrators
Schema Admins
Backup Operators
Cert Publishers
Domain Controllers
Enterprise Admins
Krbtgt
Print Operators
Schema Admins
Replicator
Server Operators
0
 

Author Comment

by:40hz
ID: 39842244
@Jullez- No worries friend.  I clearly didn't know what was right or wrong.  I never made that judgement.  Even if it was wrong and did damage,  I am the one responsible.

@Simon- I remember having to do that before in the past.  I decided to try it on one user's account to see if it works.  The account already had it's permissions inherited so I disabled/enabled them.  I'm waiting to hear back from the user and will report back ASAP. Also that cmdlet worked.
0
 

Accepted Solution

by:
40hz earned 0 total points
ID: 39847552
OK.  I'm not entirely sure what went on here but I would call this issue resolved.

I had to re-image a users computer due to hard drive failures and he of course was receiving the "security alert" issue before the re-image.  After I had imaged his PC.  I tested Outlook and everything was kosher, almost like nothing had happened.  So this got me thinking about the .OST files and the temp directory.   Even though I went to the mail control panel and deleted the profile to have it rebuilt, it still did not work.  This is what I did to fix it:

1.

Completely shutdown Outlook

2.

Go to Control Panel | Mail

3.

Delete the default profile

4.

Go to the temp directory where the .ost is stored              C:\Users\<user>\AppData\Local\Microsoft\Outlook

5.

Delete EVERYTHING in the Outlook folder
Once I had done that, Outlook no longer tried to communicate with the server and verify the security cert using SERVERNAME.PrivateDomain.local.
0
 

Author Closing Comment

by:40hz
ID: 39861137
Thank you both for your help!  All points awarded to Jullez as they helped me since the beginning.
0

Featured Post

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

ADCs have gained traction within the last decade, largely due to increased demand for legacy load balancing appliances to handle more advanced application delivery requirements and improve application performance.
This process describes the steps required to Import and Export data from and to .pst files using Exchange 2010. We can use these steps to export data from a user to a .pst file, import data back to the same or a different user, or even import data t…
In this video we show how to create an Address List in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Organization >> Ad…
To show how to create a transport rule in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Rules tab.:  To cr…

706 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now