UCC Cert errors
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!
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!
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,
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?
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,
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?
ASKER
I've attached the security 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!
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!
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.......interna
www....external IP of your website etc
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.......interna
www....external IP of your website etc
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
publicdomain.com
--mail.publicdomain.com (MX) -> server.privatedomain.com
--mail.publicdomain.com (A) -> 192.1.1.1
--autodiscover.publicdomai
AutoConfig-XML-Log.txt
--mail.publicdomain.com (MX) -> server.privatedomain.com
--mail.publicdomain.com (A) -> 192.1.1.1
--autodiscover.publicdomai
AutoConfig-XML-Log.txt
ASKER
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.
I have verified that all virtual directories are pointing to the correct location.
In your DNS forward zone for your publicdomain.com
A record autodiscover---------inter
A record mail----------internal IP
www-------external IP (your web host for your website)
Should be all set after that.
A record autodiscover---------inter
A record mail----------internal IP
www-------external IP (your web host for your website)
Should be all set after that.
ASKER
Interestingly enough when I run the command:
Get-AutodiscoverVirtualDir
I get the following output:
Name Server InternalUrl
---- ------ -----------
Autodiscover (Default Web Site) <servername>
but when I run:
Get-ClientAccessServer |fl identity,autodiscoverservi
I get the following output:
Identity : <servername>
AutoDiscoverServiceInterna
Get-AutodiscoverVirtualDir
I get the following output:
Name Server InternalUrl
---- ------ -----------
Autodiscover (Default Web Site) <servername>
but when I run:
Get-ClientAccessServer |fl identity,autodiscoverservi
I get the following output:
Identity : <servername>
AutoDiscoverServiceInterna
So Get-AutodiscoverVirtualDir
ASKER
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?
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?
Try to run:
Get-AutodiscoverVirtualDir
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?
Get-AutodiscoverVirtualDir
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?
ASKER
I ran the cmdlet and now when I run:
Get-AutodiscoverVirtualDir
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.
Get-AutodiscoverVirtualDir
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.
Can they close outlook, make sure it is not running in "Task manager" then open it again please?
ASKER
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.
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.
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?
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?
ASKER
When I run the autoconfig test, the only anomalies that are pointing internally are these:
<Server>exchangeserver.pri
<PublicFolderServer>exchan
<AD>domaincontroller.priva
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.
<Server>exchangeserver.pri
<PublicFolderServer>exchan
<AD>domaincontroller.priva
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.
And on your cert you have autodiscover listed as alternativel name, correct?
ASKER
No, the main name of the cert is autodiscover, I have mail.publicdomain as one of the alt names
ASKER
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.
http <blank> 80 *
https <blank> 443 * autodiscover.publicdomain.
I've lost my marbles on this error. It's gotta be something simple and easily overlooked.
Type HostName Port IP Cert
http <blank> 80 127.0.0.1
https <blank> 443 127.0.0.1 autodiscover.publicdomain.
http <blank> 80 *
https <blank> 443 * autodiscover.publicdomain.
I've lost my marbles on this error. It's gotta be something simple and easily overlooked.
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.
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.
ASKER
Yes the certificate does indeed have SMTP, IMAP and IIS associated to it.
I do have an MX record that is pointing to ExchangeServer.PrivateDoma
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.
I do have an MX record that is pointing to ExchangeServer.PrivateDoma
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.
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.
Oh dear.
The postings in this question are just wrong on so many levels.
This suggestion was completely wrong.
Get-AutodiscoverVirtualDir
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, autodiscoverserviceinterna
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.
The postings in this question are just wrong on so many levels.
This suggestion was completely wrong.
Get-AutodiscoverVirtualDir
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, autodiscoverserviceinterna
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.
ASKER
@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-AutodiscoverVirtualDir
@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.
Any suggestions anyone? The simple tasks are never the easy ones. Thank you both for your help thus far!
@Simon- How do I revert the following:
Get-AutodiscoverVirtualDir
@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.Any suggestions anyone? The simple tasks are never the easy ones. Thank you both for your help thus far!
This command should work:
Get-AutodiscoverVirtualDir
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.
Get-AutodiscoverVirtualDir
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.
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)(s
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.
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)(s
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.
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
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
ASKER
@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.
@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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you both for your help! All points awarded to Jullez as they helped me since the beginning.
ASKER
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