Certificate mismatch

Infrastructure
2x Domain Controler with local IP with domain.local name Domain has split DNS for local and external IPs
2x Exchange 2013 servers with local IP and external IP with domain.com name
2x Webservers running IIS with local IP and external IP
Both external IPs for webserver and exchange are different.
Both Exchange servers respond to name email.domain.com both internaly and externaly. Internal and external virtual directories are set to email.domain.com address. Outlook providers are set to email.domain.com
I have trusted computer outside the domain and it is using Outlook 2013. It has installed my CA certificate. This Outlook is showing Security alert about certificate. The certificate from alert comes from webserver. I need it to use only one certificate
from exchange server. How to do that? I looked for Autodiscover settings and outlook anywhere. What am I missing?

Hi,
Please run the following command to check the Certificate configuration in your Exchange server:
Get-ExchangeCertificate | fl
Make sure the certificate which includes email.domain.com has been assigned with IIS service. Also conform if the issue only happens to specific users such as all external users or internal users. In the problematic client side, please run the Test E-mail
AutoConfiguration tool to check the service URLs in the Results tab and find out which service is using the mismatched namespace. To run this tool, please do:
Open Outlook - press CTRL key - right click on the Outlook icon from right bottom corner taskbar - Test Email AutoConfiguration. Put your email address - uncheck use guessmart and secure guessmart authentication - click Test to check your Autodiscover service.
Additionally, please run the following command to configure your Outlook Anywhere:
Set-OutlookAnywhere -Identity "Exch13\Rpc (Default Web Site)" -InternalHostname email.domain.com -ExternalHostname email.domain.com -InternalClientAuthenticationMethod Ntlm -ExternalClientAuthenticationMethod Basic -ExternalClientsRequireSsl
$True -InternalClientsRequireSsl $true
Here is a article about how to troubleshooting certificate issue: 
https://social.technet.microsoft.com/Forums/en-US/fa78799b-5c55-4c71-973b-0e186612ff6f/checklist-for-exchange-certificate-issues?forum=exchangesvrgeneral
Regards,
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]
Winnie Liang
TechNet Community Support

Similar Messages

  • Certificate Mismatch RDS Session Host

    I've been banging my head against this for the last few days. I have a server 2012 remote desktop setup as follows:
    1 Gateway Server
    1 RD Web Access Serve
    1 Session Broker, which is also a session host
    1 Additional Session host
    I'm using remote app to publish applications rather than desktops. I've got a wildcard certificate for the external domain, which works fine for the gateway and web access server, the problem comes with the session hosts, which are giving me a certificate mismatch
    error because connections are made to the internal name (which is a .local address) which obviously does not match the external certificate.
    I have a DNS zone for the external name setup on this domain, so that machines can be resolved by internal or external names.
    I've made some progress by following the steps here - http://serverfault.com/questions/524092/rds-rdweb-and-remoteapp-how-to-use-public-certificate-for-launching-apps-on-s, and things now work fine if I only have the session host that is also the broker
    enabled. Once I add the second session host, any requests that go to that get the certificate error. Connections to the first session host still work fine.
    Does anyone know a way to have requests be made to the external name of the session host?

    Hi,
    1. After making the DNS change, did you flush the DNS cache on the RD Gateway server?  Or even better restart the whole server?
    2. Do you have DNS round robin for any of the other servers in your deployment?  You should
    not.  Additionally, do you have any NLB or other hardware/software load balancing solution in place?
    3. To make sure I have the facts correct, please let me know if the following items are correct:
    a. You are launching a RemoteApp from within RD Web Access using IE running on a Windows 8 PC
    b. When you launch a RemoteApp, the prompt has the following on it (for Calculator in this example):
    Publisher: *.domain.com
    Type: RemoteApp program
    Path: calc
    Name: Calculator
    Remote computer: rdbroker.domain.com
    Gateway server: gateway.domain.com
    c. After clicking Connect it goes through several status messages and then you get a Certificate error saying essentially:
    Name mismatch
         Requested remote computer:
         rd02.domain.local
         Name in the certificate from the remote computer:
         *.domain.com
    Certificate errors
      The following errors were encountered while validating the remote
      computer's certificate:
         The server name on the certificate is incorrect.
    d. In Deployment Properties, RD Gateway tab, Bypass RD Gateway server for local addresses is
    unchecked.
    4. Do you have multiple configured network cards in each server, or just a single NIC that has an ip address?
    5. Have you modified the default firewall configuration of your servers?  In other words, can I assume they are on the same subnet and are able to communicate with each other in the default domain configuration, or have changes been made and/or is
    there a third-party firewall software or device in place that could be affecting things?  I ask because normally the broker will authenticate the destination server using Kerberos and if something interferes with this you can get unexpected errors.
    I believe you are close to solving this now.
    Thanks.
    -TP

  • RDS VDI Certificate Mismatch

    Hi,
    I have a 2012 R2 RDS farm deployed and users are able to log onto the personal desktops successfully.  However, when the user launches the VDI from RDWEB, they receive a certificate mismatch.  The certificate being presented is self signed from
    the VDI.
    Is this normal behaviour for the VDI connection? Or am I missing something here?

    Hi,
    When running App\VDI from RD web we have to use the trusted certificate for proper connection. If you are receiving certificate mismatch error then there are certain reason to occur. When publishing RDS externally, you will see a certificate mismatch as the
    internal server FQDN’s/IP addresses will show externally during the connection process to RemoteApps or RemoteDesktops.
    There are certain solution to resolve this issue.
    • Can create a new DNS zone, .COM to allow split-brain DNS (so that internal clients can resolve external names internally)
    • Create a relevant DNS entry to point to the RDS environment’s internal IP address
    • Create a relevant DNS entry in external DNS to point to the firewall which is publishing RDS’s external IP address
    • Use the following script to change the FQDN of the RDP files provided by RD Web Access / RemoteApp and Desktop connection feed
       https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
    You can also refer beneath article for information.
    Configuring RDS 2012 Certificates and SSO
    Hope it helps!
    Thanks.
    Dharmesh Solanki
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected]

  • SSL Certificate Mismatch with AnyConnect client

    Hello,
    We are having a problem with the AnyConnect client when connecting to our VPN.  We are running the following:
    AnyConnect v2.4.0202
    (2 each) ASA v8.2(1) -- active/standby failover
    AnyConnect Essentials Licensing
    NOTE:  We are not using certificates for authentication.
    Primary clients:  Windows XP and Windows 7
    Problem
    We have purchased an Entrust certificate for our ASA failover cluster called "vpn.company.com" and the it is attached to the outside interface on the ASA.
    Steps to Reproduce
    Install the AnyConnect (AC) client via https://vpn.company.com/.  Connection occurs here without issue.
    Once the AC client is installed and we try to use it in stand-alone mode (i.e., w/o hitting the ASA w/ a browser), a certificate mismatch occurs, and AC brings up the Windows/IE Security Alert dialog (see attachment CertError.jpg).
    The user must press Yes to bypass mismatch.
    PROBLEM:  On Windows 7, the user must have administrative privileges and run the AC client as administrator -- otherwise, they get a dialog saying "Unable to establich VPN" (see attachment Unable.jpg).
    The issue is we have a valid certificate that should be used for the connection.  However, when looking at the connections made by the AC client with Fiddler, it would appear that the AC client is trying to connect directly to the ASA's IP address, and not the name.  This is a nuisance for XP users, and a show-stopper for Win7 users as they do not have admin privileges.
    I have not been able to find any documentation on Cisco.com relating to this issue.  In short, how do I get the AC client to use "vpn.company.com" so there is no Cert mismatch?
    Thanks,
    -Matt

    Tim,
    I will read through the article more thoroughly; I've already been through parts of it -- won't hurt to go through again.  I did initially have the IP address in my XML file, and immediately removed it when I noticed that it was using the IP address in the FIddler dump.  It hasn't had any effect unfortunately -- even with uninstalling and re-installing the AC client locally.
    The only other article/post I've come across on Cisco's site that comes close is here:
    Cisco Support Community: ASA VPN Load Balancing/Clustering with Digital Certificates Deployment Guide
    which seems to suggest that I will need a UCC certificate (which seems ridiculous) to do some of what I need to do.  However the issue with that post is that it still wouldn't fix the issue where the AC client is using the IP address.
    I will let you know if I find any smoking guns in the doco link you sent.  Any other thoughts appreciated.  I can't believe Cisco made the setup of the AC client this convoluted.
    Thanks!
    -Matt

  • Certificate mismatch Outlook Anywhere

    Hi,
    When connecting an Outlook 2013 client to Exchange 2013 I am getting a certificate mismatch error.
    SSL Certificate is for the external name (exch.domain.com) has no SAN's and Outlook is looking for servername.local.  
    I have configured all virtual directories for Exchange to use the above url (exch.domain.com) for internal and external access.
    Have a local DNS record resolving the external name (exch.domain.com) to the internal IP of the exchange server.
    Operating a single public IP using ARR and Windows Server 2012 Essentials
    Have set up a SRV record in DNS for autodiscovery.
    Outlook Anywhere in the ECP is configured to NTLM authentication
    In Outlook, the advanced connection properties I was getting authentication prompts until I added https://exchange.domain.com as a proxy server.
    Any help would be appreciated thanks.

    I am having the same issue with my Outlook 2013 clients.
    All virtual directories are set to the mail.company.com.  The Godaddy certificate is for mail.company.com and is used for the SMTP, IIS, POP3, IMAP services.
    The client gives a security alert about the certificate name for servername.company.com not matching the certificate mail.company.com.  The client account settings show the server as a
    [email protected] and the Exchange proxy settings as mail.company.com and connect using SSL only with msstd:mail.company.com for the principal name.
    Doing a Connection status check on the Outlook, it shows the Proxy server of mail.company.com and server name as the
    [email protected] for Exchange Directory and Exchange Mail.
    I have tried putting the server name in the virtual directory internal url's but it still isn't working correctly.
    I had used a cert form our internal CA for testing and am still using it for the UM and UMCallRouter functions, although the SMTP, IMAP, POP3 are still checked for it.
    Outlook functions fine after clearing the Security Alert.
    Not sure what I am missing.  Thanks for any help.

  • Certificate - Mismatched Address

    All, I am getting several of these messages preventing me going to certain pages in CallManager 5.1? The error is in the toolbare: Certificate, Mismatched Address: The security certificate presented by this website was issued for a different website's address.
    Anyone ever had this?

    If you are using IP address instead of hostname, the mismatched address message is because the certificate was created with the CM server hostname.
    Point the DNS with the correct hostname.

  • Exchange 2007 Autodiscover certificate mismatch

    Hello, the company that I work for is trying to switch from Exchange 2007 SP1 to Office 365.  However, when we try the cutover migration, 365 doesn't recognize our Exchange server.  After a bit of research, I discovered that there is a certificate
    mismatch that is causing the problem.  
    I've been searching for a way to solve this problem for a couple of days now and have not yet found a solution.  We'd like to keep the autodiscover location, but change the certificate that is bound to it.  We
    have a matching certificate installed, but for some reason, Autodiscover keeps pointing toward the wrong certificate (that doesn't even exist).
    Any help would be greatly appreciated

    We purchased new certs from GoDaddy and inserted them into exchange (overwriting the old certs and CAs), and this seemed to correct the certificate mismatch.  However, when I run the Remote Connectivity Analyzer, I get this:
    Connectivity Test Failed
    Test Details
    <input class=" __ecpStyleButton" id="testSelectWizard___CustomNav3_buttonStartOver" name="testSelectWizard$__CustomNav3$buttonStartOver"
    style="padding:8px 8px 8px 29px;text-align:left;border-style:none;cursor:pointer;background-image:url(https;background-background-repeat:no-repeat;" type="submit" value="Start Over" /><input class=" __ecpStyleButton"
    id="testSelectWizard___CustomNav3_buttonRunAgain" name="testSelectWizard$__CustomNav3$buttonRunAgain" style="padding:8px 8px 8px 29px;text-align:left;border-style:none none none solid;cursor:pointer;border-left-color:#cccccc;border-left-width:1px;background-image:url(https;background-background-repeat:no-repeat;"
    type="submit" value="Run Test Again" />
    <input class=" __ecpStyleButton" id="testSelectWizard_ctl12_btnExpandAll" name="testSelectWizard$ctl12$btnExpandAll" style="padding:8px 8px 8px 29px;text-align:left;border-style:none
    solid none none;cursor:pointer;border-right-color:#cccccc;border-right-width:1px;background-image:url(https;background-background-repeat:no-repeat;" type="submit" value="Expand All" /><input class="ecpStyleButtonImageOnly
    __ecpStyleButton" id="testSelectWizard_ctl12_btnSaveXml" name="testSelectWizard$ctl12$btnSaveXml" style="padding-padding-bottom:6px;padding-text-align:left;border-style:none;cursor:pointer;background-image:url(https;background-background-repeat:no-repeat;"
    title="Save as XML" type="submit" value="" /><input class="ecpStyleButtonImageOnly __ecpStyleButton" id="testSelectWizard_ctl12_btnSaveHtml" name="testSelectWizard$ctl12$btnSaveHtml" style="padding-padding-bottom:6px;padding-text-align:left;border-style:none;cursor:pointer;background-image:url(https;background-background-repeat:no-repeat;"
    title="Save as HTML" type="submit" value="" />
    The Microsoft Connectivity Analyzer is attempting to test Autodiscover for [email protected].
    Testing Autodiscover failed.
    Additional Details
    Elapsed Time: 7624 ms.
    Test Steps
    Attempting each method of contacting the Autodiscover service.
    The Autodiscover service couldn't be contacted successfully by any method.
    Additional Details
    Elapsed Time: 7624 ms.
    Test Steps
    Attempting to test potential Autodiscover URL https://paidwarranty.com:443/Autodiscover/Autodiscover.xml
    Testing of this potential Autodiscover URL failed.
    Additional Details
    Elapsed Time: 1237 ms.
    Test Steps
    Attempting to resolve the host name paidwarranty.com in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: 12.192.135.43, 50.232.20.50
    Elapsed Time: 129 ms.
    Testing TCP port 443 on host paidwarranty.com to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 152 ms.
    Testing the SSL certificate to make sure it's valid.
    The certificate passed all validation requirements.
    Additional Details
    Elapsed Time: 342 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server paidwarranty.com on port 443.
    The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
    Additional Details
    Remote Certificate Subject: CN=www.paidwarranty.com, OU=Domain Control Validated, Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US.
    Elapsed Time: 247 ms.
    Validating the certificate name.
    The certificate name was validated successfully.
    Additional Details
    Host name paidwarranty.com was found in the Certificate Subject Alternative Name entry.
    Elapsed Time: 1 ms.
    Certificate trust is being validated.
    The certificate is trusted and all certificates are present in the chain.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=www.paidwarranty.com, OU=Domain Control Validated.
    One or more certificate chains were constructed successfully.
    Additional Details
    A total of 1 chains were built. The highest quality chain ends in root certificate CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US.
    Elapsed Time: 39 ms.
    Analyzing the certificate chains for compatibility problems with versions of Windows.
    Potential compatibility problems were identified with some versions of Windows.
    Additional Details
    The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
    Elapsed Time: 5 ms.
    Testing the certificate date to confirm the certificate is valid.
    Date validation passed. The certificate hasn't expired.
    Additional Details
    The certificate is valid. NotBefore = 2/24/2014 3:11:57 PM, NotAfter = 2/24/2016 3:11:57 PM
    Elapsed Time: 0 ms.
    Checking the IIS configuration for client certificate authentication.
    Client certificate authentication wasn't detected.
    Additional Details
    Accept/Require Client Certificates isn't configured.
    Elapsed Time: 371 ms.
    Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
    Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
    Additional Details
    Elapsed Time: 241 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://paidwarranty.com:443/Autodiscover/Autodiscover.xml for user [email protected].
    The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
    Additional Details
    A Web exception occurred because an HTTP 404 - NotFound response was received from IIS7.
    HTTP Response Headers:
    Content-Length: 5401
    Cache-Control: private
    Content-Type: text/html; charset=utf-8
    Date: Mon, 02 Mar 2015 14:58:45 GMT
    Server: Microsoft-IIS/7.5
    X-Powered-By: ASP.NET
    Elapsed Time: 241 ms.
    Attempting to test potential Autodiscover URL https://autodiscover.paidwarranty.com:443/Autodiscover/Autodiscover.xml
    Testing of this potential Autodiscover URL failed.
    Additional Details
    Elapsed Time: 5175 ms.
    Test Steps
    Attempting to resolve the host name autodiscover.paidwarranty.com in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: 157.56.234.137, 157.56.244.217, 157.56.236.89, 157.56.232.9
    Elapsed Time: 327 ms.
    Testing TCP port 443 on host autodiscover.paidwarranty.com to ensure it's listening and open.
    The specified port is either blocked, not listening, or not producing the expected response.
     <label for="testSelectWizard_ctl12_ctl06_ctl00_ctl01_ctl01_tmmArrow">Tell
    me more about this issue and how to resolve it</label>
    Additional Details
    A network error occurred while communicating with the remote host.
    Elapsed Time: 4847 ms.
    Attempting to contact the Autodiscover service using the HTTP redirect method.
    The attempt to contact Autodiscover using the HTTP Redirect method failed.
    Additional Details
    Elapsed Time: 995 ms.
    Test Steps
    Attempting to resolve the host name autodiscover.paidwarranty.com in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: 157.56.234.137, 157.56.244.217, 157.56.236.89, 157.56.232.9
    Elapsed Time: 16 ms.
    Testing TCP port 80 on host autodiscover.paidwarranty.com to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 111 ms.
    The Microsoft Connectivity Analyzer is checking the host autodiscover.paidwarranty.com for an HTTP redirect to the Autodiscover service.
    The redirect (HTTP 301/302) response was received successfully.
    Additional Details
    Redirect URL: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
    HTTP Response Headers:
    Connection: close
    Pragma: no-cache
    Cache-Control: no-cache
    Location: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
    Elapsed Time: 137 ms.
    Attempting to test potential Autodiscover URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
    Testing of this potential Autodiscover URL failed.
    Additional Details
    Elapsed Time: 729 ms.
    Test Steps
    Attempting to resolve the host name autodiscover-s.outlook.com in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: 132.245.64.242, 132.245.3.130, 132.245.92.226, 132.245.82.50, 132.245.81.194, 132.245.81.130, 132.245.88.194
    Elapsed Time: 17 ms.
    Testing TCP port 443 on host autodiscover-s.outlook.com to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 53 ms.
    Testing the SSL certificate to make sure it's valid.
    The certificate passed all validation requirements.
    Additional Details
    Elapsed Time: 221 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server autodiscover-s.outlook.com on port 443.
    The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
    Additional Details
    Remote Certificate Subject: CN=outlook.com, OU=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=WA, C=US, Issuer: CN=Microsoft IT SSL SHA1, OU=Microsoft IT, O=Microsoft Corporation, L=Redmond, S=Washington, C=US.
    Elapsed Time: 127 ms.
    Validating the certificate name.
    The certificate name was validated successfully.
    Additional Details
    Host name autodiscover-s.outlook.com was found in the Certificate Subject Alternative Name entry.
    Elapsed Time: 1 ms.
    Certificate trust is being validated.
    The certificate is trusted and all certificates are present in the chain.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=outlook.com, OU=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=WA, C=US.
    One or more certificate chains were constructed successfully.
    Additional Details
    A total of 1 chains were built. The highest quality chain ends in root certificate CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE.
    Elapsed Time: 38 ms.
    Analyzing the certificate chains for compatibility problems with versions of Windows.
    Potential compatibility problems were identified with some versions of Windows.
    Additional Details
    The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
    Elapsed Time: 5 ms.
    Testing the certificate date to confirm the certificate is valid.
    Date validation passed. The certificate hasn't expired.
    Additional Details
    The certificate is valid. NotBefore = 1/21/2015 10:45:26 PM, NotAfter = 1/21/2016 10:45:26 PM
    Elapsed Time: 0 ms.
    Checking the IIS configuration for client certificate authentication.
    Client certificate authentication wasn't detected.
    Additional Details
    Accept/Require Client Certificates isn't configured.
    Elapsed Time: 158 ms.
    Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
    Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
    Additional Details
    Elapsed Time: 277 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml for user [email protected].
    The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
    Additional Details
    An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name
    (UPN).
    HTTP Response Headers:
    request-id: d823479c-c259-4474-8b3f-df60b4898533
    X-CasErrorCode: UnauthenticatedRequest
    X-FEServer: BY2PR12CA0033
    Content-Length: 0
    Cache-Control: private
    Date: Mon, 02 Mar 2015 14:58:53 GMT
    Set-Cookie: ClientId=GILRU7BQ40ROHZE90FEIA; expires=Tue, 01-Mar-2016 14:58:54 GMT; path=/; secure; HttpOnly
    Server: Microsoft-IIS/8.0
    WWW-Authenticate: Basic Realm=""
    X-AspNet-Version: 4.0.30319
    X-Powered-By: ASP.NET
    Elapsed Time: 276 ms.
    end
    I've enabled basic authentication on the RPC virtual directory on the Exchange CAS in IIS and then restarted IIS, as suggested in another forum (https://social.technet.microsoft.com/Forums/exchange/en-US/69d83444-0528-4e39-a5e9-eb9040501be1/remote-connectivity-analyzer-problem?forum=exchangesvr3rdpartyappslegacy)
    and am still getting the same results from the Remote Connectivity analyzer.
    On a side note, we have reviewed multiple Exchange Deployment Assistance, including the one that you referred to, and are attempting a cutover migration.

  • Certificate mismatch for internal RDSH

    Im sure this question has been asked/addressed over a dozen times. I do apologize in advanced for the repeat.
    I have RDS setup on a 2008R2 box with a single certificate for the RDG. When users connect, they obviously get a mismatch certificate warning upon connecting to the internal RDSH server (RDSH.domain.local).
    Besides using an internal CA, what other options do i have? I guess i can technically use a wildcard certificate and use a split DNS, but that's currently not an option.
    Thanks

    Hi,
    As you have installed RDS role on single server, you can use single certificate for RDS server roles. You also need to open TCP port 443 and UDP port 3391 which point to RD Gateway Server. You can change the published FQDN of the server for that also need to
    create DNS A record on network that points to server IP address. You can able to change the FQDN name by below command mention in link.
    Change published FQDN for Server 2012 or 2012 R2 RDS Deployment
    Also check that you have correctly set RD RAP & RD CAP policy under RD Gateway manager. Also you can select “Allow users to connect to any resource” under Network Resource tab in RD Gateway manager. (Quoted from below thread answered by TP).
    More information:
    Windows 2012 RDS Certificate mismatch
    Hope it helps!
    Thanks,
    Dharmesh

  • RDS 2012 R2 - RemoteApp - Certificate Mismatch

    Hi!
    We have a newly built RDS 2012 R2 setup.
    It consists of the following:
    1 x Server with the Gateway and the Web Access role
    2 x Servers running a Connection Broker HA cluster
    3 x Servers running as Session Hosts
    The internal domain name is example.local
    We have purchased a wildcard certificate for the entire setup. (called *.example.com)
    An external DNS record - RDS.example.com - has been created and it NAT to the Gateway and Web Access server.
    We have used the script from
    https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80 to publish the FQDN. The name we have publised is Broker.example.com. We have created a split-brain DNS internally so that the clients can resolve external names internally.
    Whenever we try to launch a RemoteApp externally we get the dreaded "Name mismatch" (and it takes about 30 seconds before we get the prompt):
    Any ideas how to solve this issue?

    Hi TP.
    Thank you for your advice.
    I've updated the Windows 7 client to RDP 8.1 and it did the trick! Thank you.
    But we have several external users - and we don't have any chance of controlling if they are running RDP 8.1. I tried to import the wildcard certificate to all RDSH servers
    - using the script in this link: https://social.technet.microsoft.com/Forums/windowsserver/en-US/475fb55f-e394-45d9-a6bd-a37e2a5fe86c/rds-2012-session-host-certificate-assignment?forum=winserverTS
    However - that is when I see the "Name mismatch" warning when launching a RemoteApp (as mentioned in my original post). I suppose this is because the certificate is valid
    only for *.example.com - and not for *.example.local?
    Is there any solution to this?

  • Internal server name .local and having a certificate mismatch

    I have one RD server with all the roles on it and I'm receiving a SSL certificate error because my internal server name is a .local and the SSL has been assigned to my apps.domainname.com address.
    I've ran the powershell cmdlet Set-RDPublishedName to reflect the apps.domainname.com, but this doesn't seem to make a difference.

    Hi Bill,
    1. We know Set-RDPublishedName worked because it shows apps.domainname.com for Remote computer in the prompt.
    2. In Server Manager -- RDS -- Overview -- Tasks -- Deployment Properties -- Certificates tab, please make sure you have set your certificate for all purposes (RDCB Single Sign On, RDCB Publishing, RDWeb, RDG).  We know it is not set (at least) for
    publishing because you are seeing the Unknown publisher warning.
    3. On the client PC, please make sure you have mstsc.exe version 6.2.9200 or later installed.  For Windows 7 you need to download and install the DTLS and RDP 8.0 updates.  Windows 8 and later already includes the new client.
    4. On your server, please enter the following in an administrator command prompt:
    wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="e2f034c171b92afc96b23b7f4da15728c1e461a9"
    Substitute your certificate's thumbprint for the Hash listed above.  The quickest way to get your cert's thumbprint is to open the certificate, on the Details tab highlight the thumbprint with your mouse, press Ctrl-C to copy it, then paste it
    into the command prompt using the system menu Edit--Paste command.  After pasting simply delete out the spaces in the thumbprint using backspace and the left arrow key.
    5. For best results with RD Web Access, please use IE and Allow and Run the Activex control when prompted.  Selecting the Private option on the RD Web logon page is preferred.
    Once you finished with the above items please test again and reply back here with your results, whether positive or negative.
    Thanks.
    -TP

  • Checklist for Exchange Certificate issues

    Checklist for Exchange Certificate issues
    1. 
    Why certificate is important for Exchange and What are Certificates used for
    Exchange is now using certificates for more than just web, POP3, or IMAP. In addition to
    securing web services, it has also incorporated Transport Layer Security (TLS) for session based authentication and encryption.
    Certificates are used for several things on Exchange Server. Most customers also use certificates
    on more than one Exchange server. In general, the fewer certificates you have, the easier certificate management becomes.
    IIS (OWA, ECP, EWS, EAS, OA, Autodiscover, OAB, UM)
    POP/IMAP
    SMTP
     2. 
    Common symptoms for
    certificate issue
    Here we can see three different types of the certificate warning, mainly from the Outlook
    side.
    a.
    Certificate mismatch issue
    b.
    Certificate trust issue
    c.
    Certificate expiration issue
    3. 
    Checklists
    In this section, checklists will be provided according to the three different scenarios:
    Certificate Mismatch Issue
    [Analysis]:
    This issue mainly occurs because the URL of the web services Outlook tries
    to connect does not match the host name in the certificate.
    [Checklist]:
    Firstly make sure how many host name in your certificate the certificate. Run “Get-ExchangeCertificate | select certificatedomain”.
    Secondly, check the web services URLs which Outlook are trying to connect to. Run “Test Email AutoConfiguration”
    In this scenario, you need to check the host name for the following services:
    Autodiscover
    EWS
    OAB
    ECP
    UM
    If any of the urls above does not match the one in the certificate, refer to the following article to change
    it via EMS:
    http://support.microsoft.com/kb/940726
     1.
    Do not forget to restart the IIS service after applying the changes above.
     2. Make sure a valid certificate is enabled on the IIS service.
    Certificate Trust Issue
    [Analysis]:
    For the self-signed and PKI-based (Enterprise)
    certificates, they are not automatically trusted by the client computer or mobile device, you must make sure that you import the certificate into the trusted root certificate store on client computers and devices. On the other hand, Third-party or commercial
    certificates do not have this problem. Most commercial CA certificates are already trusted because the certificate already resides in the trusted root certificate store. Because the issuer is trusted, the certificate is also trusted. Using third-party certificates
    greatly simplifies deployment.
    [Checklist]:
    If it’s an Enterprise CA certificate, manually install the root certificate to the “Trusted Root Certification Authorities” folder:
    If it is a 3<sup>rd</sup>-party certificate, first remove and reinstall the certificate. Check whether the Windows Certificate Store on the local
    client is corrupted. If it still does not work, please contact the third-party CA support to verify the certificate.
    Certificate Expiration Issue
    [Checklist]:
    When a certificate is about to expired, we just need to renew it by referring the following article:
    Renew an Exchange Certificate
    http://technet.microsoft.com/en-us/library/ee332322(v=exchg.141).aspx
    To avoid any conflictions, it’s recommended to remove the expired certificate from the certificate store.
    [How to set a reminder to alert the administrator when a certificate is about to expired]:
    It’s easy to fix the certificate expire issue. But it should be more important to set a reminder before the
    certificate expiration. Or there can be a large user impacts.
    Generally, the Event ID “^(24|25)$” will appear in Application log when a certificate is about to expire.
    If it’s not quite visible, we can refer to the following solution:
    http://blogs.technet.com/b/nexthop/archive/2011/11/18/certificate-expiration-alerting.aspx
    OWA certificate revoked issue
    [Analysis]:
    IE
    includes support for server certificate revocation which verifies that an issuing
    CA has not revoked a server certificate. This feature checks for CryptoAPI revocation when certificate extensions
    are present. If the URL for the revocation information is unresponsive, IE cancels the connection.
    [Solution or workaround]:
    1. Contact CA provider and check whether the questioned certificate is in the Revoked List.
    2. If not, check whether the certificate has a private key.
    3. Remove the old certificate and import the new one.
    Workaround:
    IE Internet Options -> Advanced tab -> Clear the "Check for server certificate revocation"
    checkbox.
    4. 
    More References
    Digital Certificates and SSL
    http://technet.microsoft.com/en-us/library/dd351044(v=exchg.150).aspx
    More on Exchange 2007 and certificates - with real world scenario
    http://blogs.technet.com/b/exchange/archive/2007/07/02/3403301.aspx

    (Reported previous post with link to SIS package to moderator)
    This is not the correct SIS package for the N73. The package shown is for S60 3.2 devices, but the N73 is not S60 3.2, I believe it is S60 3.0.
    Most features may work with this SIS, but if you experience strange problems, try using the S60 3.0 version.
    But there are no significant difference between 2.5.3 and 2.5.5 with regard to attachments. The only changes were with localization (languages).
    At this point, try 2.7.0 which is out now:
    http://businesssoftware.nokia.com/mail_for_exchange_downloads.php
    Make sure to pick the right phone on the drop down list. It does matter! There are 4 different packages. This list makes sure you get the right one.
    I have seen some issues with attachments not completing that seem to be carrier dependent. You can test this my using Wifi (if possible).
    Message Edited by m4e_team_k on 28-Sep-2008 12:25 AM

  • Webdispatcher SSL load balance server mismatch errors

    We are setting up a webdispatcher to access an Enterprise Portal with multiple instances.  Currently it is working but we are having to overide host mismatches.  in webdispacther log we see
    [Thr 4856] Mon Mar 07 11:38:02 2011
    [Thr 4856] MatchTargetName("aaa.mycompany.com", "CN=bbb.mycompany.com, OU=xxx, O=ooo, L=ccc, SP=sss, C=US") FAILS
    [Thr 4856] SSL NI-sock: local=##.21.13.137:50746 peer=##.21.13.131:51001
    [Thr 4856] <<- ERROR: SapSSLSessionStart(sssl_hdl=0000000008565100)==SSSLERR_SERVER_CERT_MISMATCH
    The Portal instances are on
    aaa.mycompany.com
    bbb.mycompany.com
    Currently have a CA approved certificate for each server installed in the portal.  Dispatcher on aaa uses aaa cert, dispatcher on bbb uses bbb cert.
    Message server is on aaa, but it will load balance and place you on either instance.
    have following related parameters
    wdisp/ssl_encrypt = 2
    wdisp/ssl_auth = 2
    wdisp/ssl_cred = C:\usr\sap\XXX\W00\sec\XXX.pse
    wdisp/ssl_certhost = aaa.mycompany.com
    wdisp/ssl_ignore_host_mismatch = TRUE
    C:\usr\sap\XXX\W00\sec\XXX.pse has ssl cert of both aaa and bbb servers.
    All seems to be working, as users are load balancing.  They are not getting certificate mismatches in their browser anymore.  We are getting the SSSLERR_SERVER_CERT_MISMATCH errors, but the messages do not seem to cause an issue since we have wdisp/ssl_ignore_host_mismatch set.
    Can we eliminate those mismatch errors instead of masking the problem with wdisp/ssl_ignore_host_mismatch?
    Should each portal instance have their own ssl cert, or is there a way to use one cert such as the aaa.mycompany.com cert on each portal instance?  It seems like that might eliminate the mismatch errors.  However, what happens when you go directly to the bbb.mycompany.com portal instance? there is a certificate error if you specify aaa's and you go to bbb.  I was wondering if the wdisp/ssl_auth and wdisp/ssl_certhost are valid in the portal system so that each server uses the aaa server and certificate.  I could not tell if this parameter is valid for java-only portal systems.
    Thanks for your help.
    Edited by: Fett Patrick on Mar 7, 2011 8:35 PM

    Thank you Martin for your prompt reply.  Can you clarify please, can we use the wdisp/ssl_certhost parameter in the instance profiles of the portal instances?  I wasn't sure if that is only valid for webdispatchers or can also be used in abap/java systems?
    We orginally had the aaa server certificate listed for each dispatcher in the portal under ssl provider runtime server identity.  That caused a browser "certificate error" when accessing the bbb server.  So we then installed an ssl certificate for bbb for its dispatcher.  We could then go to either server with no browser "certificate mismatch" error.
    Then when we added the webdispatcher, we started getting the server mismatch errors at the webdispatcher level.  If the wdisp/ssl_certhost can be used in the portal profiles, then that would hopefully resolve direct access or via web dispatcher aceess mismatches.  I.E. only the aaa ssl certificate would be used and parameters would be set at both the webdispatcher and portal profiles
    Thanks, Pat.

  • Outlook 2013: There is a problem with the proxy server's certificate

    Hello!
    One more question regarding Outlook 2013/Exchange2013SP1:
    There are three lab PCs: DC, Exch1, Exchange2. There's a wildcard certificate installed on Exch1 (https://social.technet.microsoft.com/Forums/en-US/6a440c99-47bd-4f48-8cc5-9f92e6b06496/wildcard-certificate-for-exchange-2013?forum=exchangesvrgeneral).
    OWA works perfect with this wildcard certificate.
    I install Outlook2013 on Exch1 and get the error:
    DC.Entreprise.Local is a computer certificate issued for the computer DC.Enterprise.Local.
    DC.Enterprise.Local IS NOT (and never was) the proxy for Exch1 or Exchange2:
    How Outlook could request DC's certificate if the proxy server = Exch1.Enterprise.Local???
    Thank you in advance,
    Michael

    Hello all,
    Thank you for your replies!
    Since I'm using a wildcard certificate I changed Outlook providers according to this:
    http://blogs.technet.com/b/exchange/archive/2013/08/02/part-2-reverse-proxy-for-exchange-server-2013-using-iis-arr.aspx
    If you do choose to use a wildcard certificate, you should also make sure that you
    change the EXPR Outlook Provider, so that Outlook Anywhere clients can successfully connect to the Exchange Server (this behavior can be a particular issue
    if you have Windows XP clients). If you do not make this change then end users may continue to receive a prompt for a certificate mismatch."
    ...and EXCH and EXPR are both set to *.Enterprise.Local.
    "I install Outlook2013 on Exch1" you mean you install Outlook on top of Exchange?"  - on the same server as Exchange, and in this case Outlook must use SCP, not DNS (the server and the client are in the same AD domain).
    "Without SCP, Exchange  try DNS autodiscover lookup, first site it will try is
    https://emaldomain/autodiscover/autodiscover.xml, which happen to be resolve to your domain controller."  - I think that's the case... I just don't understand why
    an internal client can't find the SCP that does exist and point to exch1.enterprise.local:
    Regards,
    Michael

  • RDS 2012 - Certificate Mistmatch

    I am getting the most annoying error with my RDS 2012 Setup.
    certificate mismatch and double password prompts when trying to connect to my RDS setup.
    I have tried all that's out there and have got no positive results.
    All roles are on identical on 2 servers. the RDCB is in HA Mode.
    I keep getting the Certificate mismatch error.
    Already have a public or external SAN certificate assigned to all roles.
    Ran the powershell and wmi query to ensure the correct url is used when connected to gateway but I still get the double prompt when launching the remoteapps.
    I even tried the approach by cleaning IE's history, data to get the RDPSHplugin and its not helped in my case.
    All servers run 2012.
    I need some urgent assistance, please and thank you
    I have also checked and rebooted the RDS environment multiple times.
    All certs show valid. the mismatch also goes to another cert in my environment which is utilized by OWA.
    Please help me.

    I downloaded the script to C:\ and tried running it - no luck
    PS C:\> .\Set-RDPublishedName.ps1 "remote.domain.com"
    Security warning
    Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your
    computer. Do you want to run C:\Set-RDPublishedName.ps1?
    [D] Do not run  [R] Run once  [S] Suspend  [?] Help (default is "D"): R
    iwmi : Privilege not held.
    At C:\Set-RDPublishedName.ps1:9 char:11
    + $return = iwmi -class "Win32_RDMSDeploymentSettings" -namespace "root\CIMV2\rdms ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidOperation: (:) [Invoke-WmiMethod], ManagementException
        + FullyQualifiedErrorId : InvokeWMIManagementException,Microsoft.PowerShell.Commands.InvokeWmiMethod
    I also tried it from the other HA RDCB server.
    PS C:\> .\Set-RDPublishedName.ps1 "remote.domain.com"
    Security warning
    Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm
    computer. Do you want to run C:\Set-RDPublishedName.ps1?
    [D] Do not run  [R] Run once  [S] Suspend  [?] Help (default is "D"): R
    Set-RDClientAccessName : A valid fully qualified domain name (FQDN) for the server was not specified.
    At C:\Set-RDPublishedName.ps1:22 char:1
    + Set-RDClientAccessName -ConnectionBroker $ConnectionBroker -ClientAccessName $Cl ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
        + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Set-RDClientAccessName
    I also tried is this way- 
    PS C:\Users\administrator.TBCL\Downloads> .\Set-RDPublishedName.ps1
    Security warning
    Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your
    computer. Do you want to run C:\Users\administrator.TBCL\Downloads\Set-RDPublishedName.ps1?
    [D] Do not run  [R] Run once  [S] Suspend  [?] Help (default is "D"): R
    cmdlet Set-RDPublishedName.ps1 at command pipeline position 1
    Supply values for the following parameters:
    (Type !? for Help.)
    ClientAccessName: remote.domain.com
    iwmi : Invalid namespace
    At C:\Users\administrator.TBCL\Downloads\Set-RDPublishedName.ps1:9 char:11
    + $return = iwmi -class "Win32_RDMSDeploymentSettings" -namespace "root\CIMV2\rdms ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidOperation: (:) [Invoke-WmiMethod], ManagementException
        + FullyQualifiedErrorId : InvokeWMIManagementException,Microsoft.PowerShell.Commands.InvokeWmiMethod

  • RDS 2012 R2 RemoteApp Server Name Mismatch

    Hi All,
    I wonder if someone can scratch my head on this.
    Brand new RDS 2012 R2 deployment.
    RDS01 with Connection Broker and Session Host Roles installed
    RDS02 with Web Access and Gateway roles installed
    one ssl certificate with one domain remote.mycompany.com 
    the certificate have been imported to all the servers via the Edit Deployment
    the local domain is mycompany.local
    the problem that i am having is that when i launch RemoteApp after login in the remote.mycompany.com externally, i get Certificate mismatch, because it is contact the local name of the Session host server RDS01.
    What i tried so far.
    Used the Set-PublishName (http://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80) without success
    Try to configure RDS01 certificate via (http://ryanmangansitblog.wordpress.com/2013/03/10/configuring-rds-2012-certificates-and-sso/)
    Check Any resources ( http://social.technet.microsoft.com/Forums/en-US/d1b0ebe4-9e53-47ff-8c75-43fd91ff538a/windows-2012-rds-certificate-mismatch?forum=winserverTS)
    Has anybody out there could shade me some knowledge in how to rectify the mismatch name warning.
    Thanks
    Elton

    Hi -TP,
    Answering your queries.
    1_the Set-RDPublishedName was successful, restarted the servers, refreshed the RDWeb page externally, tried to connect unsuccessfully.
    2_I am using externally windows 8 and internally 7 fully updated
    3_it had the green successful message.
    After, set-rdpublishedname command, i get an erro when try to connecting saying, RemoteApp Disconnected.
    Error:
    Remote desktop cant connect to the computer "remote.mycompany.com"
    1)Your user account is not listed in the RD Gateway Permission ( not true, it was set for domain users and my test user is under that group)
    2)you might have specified the remote computer in netbios format or ip
    Do you reckon i am having this problem because the RDS01 with Connection Broker and Session Host Roles installed?
    Cheers
    Elton

Maybe you are looking for