none
Test-WebServicesConnectivty - Remote certificate is invalid according to the validation procedure. RRS feed

  • Question

  • Context: I recovered a server using the setup /m:serverrecover option.

    I reinstalled the third party certificate with the following names:

    - mail.mydomain.net

    - autodiscover.mydomain.net

    Import-ExchangeCertifcate and Enable-ExchangeCertificate were apparently successful.

    Get-ExchangeCertificate shows both the original self-signed cert and the third party cert.

    *

    CertificateDomains for self-signed cert are:

    EX1, EX1.mynet.lan

    Services: SMTP

    Status: Valid

    *

    CertificateDomains for 3rd party cert are:

    mail.mydomain.net, autodiscover.mydomain.net

    Services: IMAP,POP, IIS, SMTP

    Status: Valid

    *

    There are no certificate prompts for Outlook, OWA or an OAB download.

    ExBPA produces no errors or warnings having to do with certificates.

    Test-ServiceHealth, Test-SystemHealth, Test-OWAConnectivity, Test-MAPIConnectivity all pass.

    *

    But... when I run the command in the subject line, the test fails on "Get-Folder" with the following error:

    [System.Net.WebException]: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. Inner error [System.Security.Authentication.AuthenticationException]: The remote certificate is invalid according to the validation procedure.

    *

    *

    Is it possible the test is using the self-signed cert?

    -------

    NOTE: just determined that the self-signed cert is not trusted (???). So the cert issued by Mailserver1 is not trusted by Mailserver1 because it is not in the Trusted Root Certification Authorities Store - Certificates (Local Computer).

    -------

    As I said, the 3rd party cert works fine with OWA. No errors or cert prompts there at all.

    When I look at the cert information on the OWA website, the certifcate status for the 3rd party cert states: "This certificate is OK". The certification path has no red x'es. All is well. The subject alternate names appears as listed above: mail.mydomain.net and autodiscover.mydomain.net

    Any ideas?

    *

    Note: I cannot seem to trigger the creation of any entries in Event Viewer when running the command - may need to increase logging level?


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.


    Thursday, January 10, 2013 1:38 AM

Answers

  • Right, but as this is for testing, I'm willing to modify settings to understand how this works, which I would not do on production equipment (where I am not having the problem anyway).

    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Wednesday, January 16, 2013 12:20 PM
  • Right, but as this is for testing, I'm willing to modify settings to understand how this works, which I would not do on production equipment (where I am not having the problem anyway).

    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.


    Good! :)

    Pretty sure that if you install a new certificate with the Server(s) internal FQDN in the certificate, you will not get the SSL Errors when running Test-WebServicesConnectivty (and/or Test-OutlookWebServices)

    Martina Miskovic

    Wednesday, January 16, 2013 12:32 PM

All replies

  • The command is successful with the -TrustAnySSLCertificate switch so, as suspected, the problem is with the cert.

    But what exactly?

    Neil Hobsen mentions the error in his article here but does not speak of a solution:

    http://www.msexchange.org/articles-tutorials/exchange-server-2007/monitoring-operations/testing-exchange-2007-powershell-part2.html

    *

    Get-WebServicesVirtualDirectory shows...

    https://mail.mydomain.net/EWS/Exchange.asmx

    for the Internal and External URLs.

    *

    *

    *

    Very similar problem here but with no solution:

    http://social.technet.microsoft.com/Forums/en-US/exchangesvrmobilitylegacy/thread/522c37f3-5670-4728-bc16-75393a5fc78f


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.



    Thursday, January 10, 2013 1:48 AM
  • Since you have third-party certificate on the server, I suggest you follow these steps to have a try:

    <1> Enable smtp service for your third-party certificate.

    <2> Remove the self-signed certificate.

    <3>Then check this issue will occur or not.

    Thanks,

    Evan


    Evan Liu
    TechNet Community Support

    Thursday, January 10, 2013 3:10 PM
    Moderator
  • Thanks Evan,

    Please note that SMTP service *is* enabled for the 3rd party cert.

    ***************

    CertificateDomains for 3rd party cert are:

    mail.mydomain.net, autodiscover.mydomain.net

    Services: IMAP,POP, IIS, SMTP

    Status: Valid

    ***************

    I'll try removing the self-signed cert though.

    ---

    On the production Exchange server I manage (also E2K7 SP3 Ru8v2), self-signed cert status is "invalid" but... the self-signed cert is not trusted either.

    However, the Test-Web... command runs just fine. Test-ActiveSync... also works. 


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Thursday, January 10, 2013 3:52 PM
  • Just tried this - same error!

    *

    I removed the self-signed cert with the Remove-ExchangeCertificate cmdlet.

    Apparently successful.

    Get-ExchangeCertificate now only shows the third party cert:

    ----------------

    Status = Valid

    Services = POP, IMAP, IIS, SMTP

    ----------------

    I've tried once again with Outlook, OAB download, OWA and there are *NO* cert error messages.

    So this has been very consistent.

    Test-ServiceHealth, Test-OWAConnectivity, Test-MAPIConnectivity all pass.

    ExBPA shows nothing having to do with WebServices or certificates.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Thursday, January 10, 2013 11:58 PM
  • I ran - again - the

    Enable-ExchangeCertificate thumbprint -Services IMAP,POP,IIS,SMTP

    cmdlet for good measure.

    Also, I noticed there was an error in Event Viewer, probably due to my removing the self-signed cert, the the "Default EX1" receive connector did not have a certificate matching "EX1.mynet.lan".

    *

    Microsoft Exchange could not find a certificate that contains the domain name EX1.mynet.lan in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default EX1 with a FQDN parameter of EX1.mynet.lan. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

    *

    So I changed the HELO/EHLO setting there to:

    mail.mydomain.net

    I restarted the entire mail server.

    Same error...

    I'm up to "Expert Mode" for  Server Diagnostic Logging Properties but apparently Test-WebServiceConnectvity does not trigger any entries. Am trying Expert Mode for Availability Service now.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.



    Friday, January 11, 2013 12:39 AM
  • [System.Net.WebException]: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. Inner error [System.Security.Authentication.AuthenticationException]: The remote certificate is invalid according to the validation procedure.

    Hi,
    Everybody that doesn't have the InternalServerFQDN in the Certificate gets that error message when running Test-WebServicesConnectivity, so nothing to worry about.

    It has to do the value for InternalNLBBypassUrl configured on WebServicesVirtualDirectory that has the InternalServerFQDN set.


    Martina Miskovic

    Friday, January 11, 2013 5:39 AM
  • Ah! That could be. At work, our cert has the server FQDN among the subject alternate names so the InternalNLBBypassUrl is covered. So at work, the Test-WebServicesConnectivity always passes.

    I think I'll try changing that setting to see what happens, then change it back. Since I'm doing this for practice (and learning) I'm willing to "tinker" with settings I would not play with in production. 


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Friday, January 11, 2013 2:07 PM
  • Well, I changed the value to mail.my-domain.net, restarted the server... and still get the same error. I re-ran - once again - Enable-ExchangeCertificate thumbprint -Services IMAP,POP,IIS,SMTP

    Unless it really wants the server FQDN for same reason.

    It did not add te server FQDN to the cert, understanding that you really only need:

    mail.my-domain.tld

    autodiscover.my-domain.tld

    ***

    Other detail:

    When recovering the server (setup /m:recoverservr), I had to reimport the private key (fortunately exported for ISA) because the recovered server was not (exactly) the same server that requested the key (some files must have been lacking).

    Yet, once again, all other test-* cmdlets tried work and ExBPA has no errors having to do with certs (some old driver warnings, etc.). 


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Monday, January 14, 2013 11:28 AM
  • Well, I changed the value to mail.my-domain.net, restarted the server... and still get the same error. I re-ran - once again - Enable-ExchangeCertificate thumbprint -Services IMAP,POP,IIS,SMTP

    Unless it really wants the server FQDN for same reason.

    It did not add te server FQDN to the cert, understanding that you really only need:

    mail.my-domain.tld

    autodiscover.my-domain.tld


    Note: It's not recommended to change the default  value configured in InternalNLBBypassUrl.

    Martina Miskovic

    Wednesday, January 16, 2013 9:29 AM
  • Right, but as this is for testing, I'm willing to modify settings to understand how this works, which I would not do on production equipment (where I am not having the problem anyway).

    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Wednesday, January 16, 2013 12:20 PM
  • Right, but as this is for testing, I'm willing to modify settings to understand how this works, which I would not do on production equipment (where I am not having the problem anyway).

    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.


    Good! :)

    Pretty sure that if you install a new certificate with the Server(s) internal FQDN in the certificate, you will not get the SSL Errors when running Test-WebServicesConnectivty (and/or Test-OutlookWebServices)

    Martina Miskovic

    Wednesday, January 16, 2013 12:32 PM
  • I honestly don't see that as an answer.

    What if you can't put the FQDN of the internal CAS servers on the certificate (For example the internal namespace is different from external one and we don't own the internal domain name on the internet).

    Such scenario -->

    Internal domain: company.int --> Don't own it externally

    External domain: company.com  --> Own it externally

    ????
    • Edited by Kman2k Thursday, June 13, 2013 4:35 PM correction/reasoning
    Thursday, June 13, 2013 4:07 PM