none
SSL cert chain trust issue on Windows Server 2012 and Windows 8.1. RRS feed

  • Question

  • Greetings and thank you for reading this.

    I have a WCF restful self hosted service that receives http posted messages and supports SSL connections.  We have this deployed successfully in several places and OS's up to Windows Server 2012 and Windows 8.1.  On these systems we are returning a 403 Forbidden error, and do not seem to be handling their certificate as expected.  Here is an excerpt from a trace.  This line reveals a problem:

    System.Net.HttpListener Verbose: 0 : [6496] Exiting HttpListenerRequest#44313942::GetClientCertificate() -> (null)

        DateTime=2015-05-01T17:27:32.5046907Z
    System.Net.HttpListener Verbose: 0 : [6496] HttpListener#44223604::BeginGetContext()
        DateTime=2015-05-01T17:27:32.5046907Z
    System.Net.HttpListener Verbose: 0 : [6496] HttpListener#44223604::BeginGetContext(IAsyncResult#51288387)
        DateTime=2015-05-01T17:27:32.5046907Z
    System.Net.HttpListener Information: 0 : [6496] HttpListenerContext#7141266::.ctor(httpListener#44223604 requestBlob=43453856)
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Information: 0 : [6496] HttpListenerRequest#44313942::.ctor(httpContext#7141266 memoryBlob# 43453856)
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Information: 0 : [6496] Associating HttpListenerRequest#44313942 with HttpListenerContext#7141266
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Information: 0 : [6496] HttpListenerRequest#44313942::.ctor(httpContext#7141266 RequestUri:https://xxx.xxx.xxx.xxx:xxx/MyURL Content-Length:5594 HTTP Method:POST)
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Information: 0 : [6496] HttpListenerRequest#44313942::.ctor(HttpListenerRequest Headers:
    	Content-Length : 5594
    	Content-Type : Multipart/related; type="multipart/related"; boundary="----=_Part_4185471_4268264.1430501251714"
    	Accept : image/gif, */*
    	Host : xxx.xxx.xxx.xxx:xxx
    )
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Warning: 0 : [6496] HttpListener#44223604::HandleAuthentication() - Received a request with an unmatched or no authentication scheme. AuthenticationSchemes:Anonymous, Authorization:<null>.
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] HttpListener#44223604::EndGetContext(IAsyncResult#59817589)
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] Exiting HttpListener#44223604::EndGetContext() 	-> HttpListenerContext#7141266 RequestTraceIdentifier#00000000-0000-0000-f001-0080000000fd
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] HttpListenerRequest#44313942::GetClientCertificate()
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] Exiting HttpListenerRequest#44313942::GetClientCertificate() 	-> (null)
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] HttpListenerContext#7141266::Response()
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Information: 0 : [6496] HttpListenerResponse#34106743::.ctor()
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Information: 0 : [6496] Associating HttpListenerResponse#34106743 with HttpListenerContext#7141266
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] Exiting HttpListenerContext#7141266::Response() 
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] HttpListenerContext#7141266::Response()
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] Exiting HttpListenerContext#7141266::Response() 
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] HttpListenerRequest#44313942::InputStream_get()
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] Exiting HttpListenerRequest#44313942::InputStream_get() 
        DateTime=2015-05-01T17:27:32.8479050Z
    System.Net.HttpListener Verbose: 0 : [6496] HttpResponseStream#47362231::Close()

    As a little more background,

    • I have the other party's complete certificate chain and it is installed by a tool we have developed so it is consistent from system to system. 
    • I have also manually installed the certificates and verified each one in the Local System - Trusted Root Certification Authorities.  Each one says the certificate is ok. 
    • I have verified each certificate has Server Authentication and Client Authentication purposes selected. 
    • The other party is a large trading partner that has many other companies receiving their posted messages, using the same certificates, etc. from their end. 
    • I have several other installations receiving posts from this partner with same software, just none using Server 2012/Windows 8.1. 

    Here is something weird - As I follow the client certificate chain up through to the root self signed cert, I find different results in the Certificate Console (MMC) than if I examine the certificate files that were provided by the other party.  I don't want to give the specifics but here is the gist. 

    Provided by the other party are -
       * VeriSign root cert (self signed) 
          * VeriSign G5 cert
             * Symantec cert
                * abc.theirdomain.com cert

    When I open their installed certificate in the MMC, and to the trust chain tab, I get this
       * VeriSign root cert (self signed)(different from that provided)
          * Symantec cert (matches the one from other party)
             * abc.theirdomain.com (matches the one from other party)

    Within our service, we set the ServiceHost.ClientCertificate.Authentication.CertificateValidationMode to ChainTrust but have also experimented with None and a CustomValidator.  Within my custom validator class, I have added some logging but we never hit the function.  We are not getting up to the application, this failure is happening at a lower layer. 

    Thank you again for reading this, and again for your expert advice. 

    Thursday, May 21, 2015 8:00 PM

Answers

All replies

  • it is not a trusted root certificate, but that it is not able to verify up the chain to a trusted certificate. If any part of the chain is broken, untrusted, or missing, you will receive such an error. The error that I get with an untrusted, self-signed root is this: This CA root certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities store. But for you, it says it cannot verify up to a trusted root certificate. This may be that during the self-signing process, you may have told openssl to sign the certificate with a different root (not self-sign), or it may not have been set as a root CA. If it's the first, you must trust the root it was signed with instead. If it's the latter, it's a matter of setting a few properties in openssl.conf.
    Friday, May 22, 2015 9:59 AM
  • Thank you for your reply. I with to clarify that we did not generate any certiciftes with OpenSSL, etc. These certs are provided by our trading partner and they have been generated by Symantec and Verisign. By self signed, I was noting that these represent the root CA certs from VeriSign. The set of provided certs work on windows 7 and Server 2008 and older environments. But when we follow the same installation procedures on new OSs it fails. All four provided certs are installed in the trusted root certification authorities folder in the local system. How does windows relate one cert to the next in the cert chain? Why would the Mmc show a different cert chain than the provided certiciftes?
    Friday, May 22, 2015 5:27 PM
  • I was able to resolve this issue with a support case from Microsoft. The root issue is documented here under Management of trusted issuers for client authentication.

    https://technet.microsoft.com/en-us/library/hh831771.aspx?f=255&MSPPError=-2147217396

    • Marked as answer by G Holden Tuesday, May 26, 2015 3:26 PM
    Tuesday, May 26, 2015 3:26 PM