none
Do WCF clients/servers check certificate's … RRS feed

  • Question

  • Hopefully the following questions will make some sense

    Assume browser A wants to establish a SSL connection with web server B located at url www.xyz.com. When establishing a connection with B, A receives from the other end a X.509 certificate C. When A receives B's certificate, it checks certificate's CN field to match server B's  hostname with domain name specified in C's CN field ( this matching is done by the browser and not by the underlying SSL connection). If B's hostname doesn't match with domain www.xyz.com, then A rejects the connection.

    a) When WCF client receives a certificate C from a WCF service, does it also check C's CN field to match server's hostname with with domain name specified in CN field?

    b) And vice-versa - When WCF service receives a certificate C from a WCF client, does it also check C's CN field to match client's hostname with with domain name specified in CN field?

    c) If answer to the above questions is yes, then I fail to see how it's possible ( as far as I know, it is possible ) to use self-signing certificates SSC with WCF, since to my knowledge SSC's CN field value doesn't match the hostname of a SSC's owner

    thank you

    Wednesday, November 24, 2010 10:37 PM

All replies

  • a) yes. this is not specific to WCF. The .net framework has special classes that verify validity of an x.509 certificate.

    b) yes.

    c) Why do you think that self-signed certificates have a different CN than the WCF service's host name? if for example you create a self-signed certificate for a "localhost" or a "MyMachineName" and you address your WCF service using that host name, it should work and the certificate should be accepted.

    BTW, when you use self-signed certificates, you will receive errors when validating the certificate because the CA is sometimes not authenticated. This is why when using ssc with WCF you either change the authentication level of the certificate to none/peerorchaintrust or supply a validator of your own that overrides the basic checks. Of course you remove these settings when moving to production/QA.

     


    Please mark posts as answers/helpful if it answers your question
    Thursday, November 25, 2010 5:22 PM
  • c) Why do you think that self-signed certificates have a different CN than the WCF service's host name? if for example you create a self-signed certificate for a "localhost" or a "MyMachineName" and you address your WCF service using that host name, it should work and the certificate should be accepted.


    a) I assume WCF client compares the value of CN field only with the domain where server resides and not with the machine name of this server? Thus, if server's self-signed certificate C has CN value set to MyMachineName ( MyMachineName is the name of this server ) and if client contacts this server via url MyMachineName.xyz.com , then client will reject certificate C, since client will compare CN's MyMachineName value with domain name part ( thus with xyz.com ) of a url?

    b) So if WCF client compares CN only with the domain name part of the URL, I fail to understand how exactly can client accept certificate if CN field has value set to »MyMachineName «?

    thank you

    Thursday, November 25, 2010 9:22 PM
  • Hello, the certificate used for transport level security is not validated by WCF. It is validated by System.Net.ServicePoint. ServicePoint also validates certificate in other SSL scenarios, such as when you use HttpWebRequest to request a web site protected by SSL. So SSL certificate doesn't have anything to do with chain/peer trust. To test against a self-signed certificate, use the following line of code to bypass certificate validation:

    ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback((a, b, c, d) => true);

    WCF's chain/peer trust certificate validation occurs when you set client authentication mode to certificate authentication (with or without SSL). In this case, CN is not checked.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, November 26, 2010 2:16 AM
  • a) uhm, I must admit I'm totally lost now. Book provides examples where NetTcpBinding ( using SSL ) sets CertificateValidationMode to PeerTrust, just so the service bypasses the certification path of client's certificate ( which is self-signed ). But you're saying that setting  CertificateValidationModeto PeerTrust is not needed, since SSL certificates don't care about chain/peer trust?

    b) The little I know about SSL is that it always requires certificate to be from trusted authority, so how exactly do SSL certificates get checked/validated by ServicePoint ( thus, where do we put certificates we trust so that ServicePoint finds them )?

     

    totally lost :(

    Friday, November 26, 2010 3:41 AM
  • What book are you reading? Does it happen to authenticate client using a certificate as well? As mentioned above, chain/peer trust is used in scenarios where you specify the client authentication mode to be certificate. You can use certificate authentication together with SSL, or you can use other authentication modes (such as username/password) with SSL. You can also use certificate authentication without SSL.

    Yes, SSL requires certificate to be from trusted authority. This is ensured by ServicePoint. I'm not sure how ServicePoint validates certificate, though.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, November 26, 2010 9:56 AM
  • hi, I apologize for being so thick, but I must admit that I'm totally lost

     

    "What book are you reading?"

    I'm reading Essential WCF

     

    "Does it happen to authenticate client using a certificate as well?"

    Yes, I will post the code at the end of this post

     

    "As mentioned above, chain/peer trust is used in scenarios where you specify the client authentication mode to be certificate"

    Yes, but you've also said that chain/peer trust doesn't have anything to do with SSL certificates, which I'm still confused about :(

     

    Lets break it down:

    Assume WCF service endpoint E ( E uses SSL with NetTcpBinding and with SecurityMode set to Transport ) authenticates the client using certificate ( this client has self-signed certificate C )

    * Now I thought that if we put C inside Trusted People store and set CertificateValidationMode to PeerTrust, then client will be authenticated and thus granted access.

    * But you've said in your original post that that chain/peer trust doesn't work when SSL certificates are used to authenticate the client ( thus client authentication mode is set to certificate ), which I assume it means that there's no point in putting C inside Trusted People store and setting CertificateValidationMode to PeerTrust?!

    * But in your second post you say that when SSL certificates are used to authenticate the client ( thus client authentication mode is set to certificate ), then chain/peer trust validation does occur and thus that we should put C inside trusted People folder and should set CertificateValidationMode to PeerTrust?!

     

    "WCF's chain/peer trust certificate validation occurs when you set client authentication mode to certificate authentication (with or without SSL). In this case, CN is not checked."

    So if CertificateValidationMode is set to PeerTrust, then CN is not checked, but if it is set to some other value, then CN is checked?

     

    Here's the code from the book:

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
     <system.serviceModel>
    
      <services>
       <service name="EffectiveWCF.StockService"
            behaviorConfiguration="MyBehavior">
        <host>
         <baseAddresses>
          <add baseAddress="http://localhost:8000/EffectiveWCF" />
          <add baseAddress="net:tcp//localhost:8001/EffectiveWCF"/>
         </baseAddresses>
        </host>
        <endpoint address=""
             binding="netTcpBinding"
             bindingConfiguration="MyBinding"
             contract="EffectiveWCF.IStockService" />
    
        <endpoint address="mex"
             binding="mexHttpBinding"
             contract="IMetadataExchange" />
       </service>
      </services>
    
      <behaviors>
       <serviceBehaviors>
        <behavior name="MyBehavior">
         <serviceMetadata httpGetEnabled="true" />
         <serviceCredentials>
          <serviceCertificate findValue="localhost"
                    storeLocation="LocalMachine"
                    storeName="My"
                    x509FindType="FindBySubjectName"/>
          <clientCertificate>
           <authentication certificateValidationMode="PeerTrust"/>
          </clientCertificate>
         </serviceCredentials>
        </behavior>
       </serviceBehaviors>
      </behaviors>
    
      <bindings>
       <netTcpBinding>
        <binding name="MyBinding">
         <security mode="Transport">
          <transport clientCredentialType="Certificate"/>
         </security>
        </binding>
       </netTcpBinding>
      </bindings>
      
     </system.serviceModel>
    </configuration>

    Friday, November 26, 2010 7:24 PM
  • Well, imagine you have a scenario where you use SSL without client certificate authentication (you can use username/password authentication). In this case, the server has a SSL certificate (cert A), which will be validated by ServicePoint. In this case, WCF doesn't validate the certificate at all, and the peer/chain trust doesn't apply.

    In another scenario, you do not use SSL. Let's say you're using message security, and client authentication mode is set to certificate. In this case, the client must present a certificate (cert B). But since SSL is not used, this certificate has nothing to do with SSL certificate (cert A). WCF will validate this certificate using peer/chain trust. But ServicePoint is not involved. This ends for the client's story. But the service can (optionally) also be authenticated. You can choose to use username/password to represent service credential, in which case no service certificate is involved. You can choose a service certificate (cert C) to represent service credential. But again, this certificate has nothing to do with SSL certificate (cert A). This certificate will be validated by WCF using peer/chain trust.

    Yet in another scenario, you combine the above two senarios. You use SSL together with client certificate authentication. So the result is: The service must present an SSL certificate (cert A), which is validated by ServicePoint. The client must present a certificate (cert B), which is validated by WCF. The service can also optionally present a credential, using username/password, or using a service certificate (cert C). If you choose to use cert C for service authentication, it will be validated by WCF. Now in this scenario, since both cert A and cert C are provided by the service, you can choose to use different certificates, or use a single certificate (that is, cert A can optionally = cert C). If you choose to use a single certificate, it will be validated by both ServicePoint (since it serves as an SSL certificate), and WCF (since it represents the service credential). But as noted above, cert C is optional. The service credential can be username/password as well.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, November 29, 2010 1:34 AM
  • Hi

    Great answer, but there are still few things I’m quite ( an understatement :( ) confused about. If possible, could you answer my questions directly, since that’s probably the quickest way for me   to connect all the dots:

    1) With chain/peer trust certificate validation the CN field is not checked, which means that we can use self-signed certificates ( and these self-signed certificates should be located in Trusted People folder )?!

    2) You're also saying that ServicePoint doesn't use chain/peer trust for certificate validation.

    But   doesn't that suggest that SSL certificates validated by ServicePoint can't be self-signed, since ServicePoint also checks CN field, which with self-signed certificates isn't valid/trusted?

    3) So essentially, there are two types of certificate validations:

    * type 1 is used only to establish SSL connection

    * type 2 is used on client to validate service's certificate credential, and is also used on the service side to validate client's certificate credential?

    4) "Well, imagine you have a scenario where you use SSL without client certificate authentication (you can use username/password authentication). In this case, the server has a SSL certificate (cert A), which will be validated by ServicePoint. In this case, WCF doesn't validate the certificate at all, and the peer/chain trust doesn't apply."

    a) So type 2 validation is automatically enabled only when service uses SSL together with client certificate authentication?

    b) Why if service uses SSL without client certificate authentication, doesn’t this service also have an option to present certificate credential to the client ( thus an option for service's certificate to be validated using type 2 validation )?

     

     

    5) Assuming service uses   SSL together with client certificate authentication, we can authenticate service ( using certificates ) twice: first when establishing SSL connection and then when providing certificate credentials to the client.

    But is there ever a point or a need for a service to authenticate itself ( via certificates ) twice?


    6) Yet in another scenario, you combine the above two senarios. You use SSL together with client certificate authentication. So the result is: The service must present an SSL certificate (cert A), which is validated by ServicePoint. The client must present a certificate (cert B), which is validated by WCF. The service can also optionally present a credential, using username/password, or using a service certificate (cert C). If you choose to use cert C for service authentication, it will be validated by WCF. Now in this scenario, since both cert A and cert C are provided by the service, you can choose to use different certificates, or use a single certificate (that is, cert A can optionally = cert C). If you choose to use a single certificate, it will be validated by both ServicePoint (since it serves as an SSL certificate), and WCF (since it represents the service credential). But as noted above, cert C is optional. The service credential can be username/password as well.

    a) How do you specify in configuration file which service certificate is to be used to establish SSL connection ( thus is validated by ServicePoint )   and which certificate is to be sent to client as service credential ( thus is validated by WCF )?

    b) Cert A is also validated by ServicePoint, and as already mentioned, certificates validated by ServicePoint can’t be self-signed. Thus, I assume cert A can’t be self-signed?!

    c) I assume credential ( username, password etc ) presented by service be also set at transport security level?

     

    7) And finally, service S ( its code I’ve posted in my previous post) uses SSL with client authentication. According to your explanation, the service certificate C   is validated by both type 1 and type 2 validation mechanisms, but shouldn’t type 1 validation reject C, since C is self-signed?

     

    thank you

    Tuesday, November 30, 2010 8:50 PM
  • 1) Yes. But chain trust is different from peer trust. With peer trust, you only need to make sure the certificate is in the Trusted People store. With chain trust, the certificate chain will be validated. So if the cert is self-signed, you also need to create a self-signed root authority, and install it in Trusted Root store. See http://msdn.microsoft.com/en-us/library/ms733813.aspx for more information.

    2) I'm not sure how exactly ServicePoint validates certificate, but possibly it also validates the certificate chain. If the certificate presents in the client's store and the chain is valid, it should work fine. If it doesn't work, you can always bypass the validation by:

    ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback((a, b, c, d) => true);

    The above code should also work even if the CN validation fails.

    3) Yes.

    4) Sorry I should be more clearer. Service can optionally present a certificate (or username/password or something else) for service credential, with or without SSL.

    5) In SSL scenario, service credential is optional, but the SSL certificate is required. Service credential can be required in other scenarios, such as message authentication.

    6) a) You can't specify SSL certificate in web/app.config. It is configured on the server. If you're using IIS, refer to http://technet.microsoft.com/en-us/library/cc753127(WS.10).aspx. If you're using a self-host WCF service, use the netsh command line tool as described on http://msdn.microsoft.com/en-us/library/ms733791.aspx. The cert representing WCF service credential is configured in web/app.config.

    b) See 2).

    c) Service credential is a WCF specific concept. It can be used with either transport or message security.

    7) See 2).


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, December 1, 2010 1:15 AM
  • hi

    1)

    "1) Yes. But chain trust is different from peer trust. With peer trust, you only need to make sure the certificate is in the Trusted People store. With chain trust, the certificate chain will be validated. So if the cert is self-signed, you also need to create a self-signed root authority, and install it in Trusted Root store."

    "2) I'm not sure how exactly ServicePoint validates certificate, but possibly it also validates the certificate chain. If the certificate presents in the client's store and the chain is valid, it should work fine"

    "6) b) See 2)."

    "7) See 2)."

     

    a) I have self signed certificate MyCert.pfx inside Trusted People store, but I don’t have self-signed root authority installed in Trusted Root store ( which I assume means that chain isn’t valid ), and yet in the code I've posted  ServicePoint still considers MyCert.pfx as valid, which it shouldn’t, since with   ServicePoint peer trust is not validated. So why is MyCert.pfx considered valid?  

    b) Here’s how I’ve created MyCert.pfx :

    makecert –r –pe –sky exchange –n “CN=MyCert” MyCert.cer –sv MyCert.pvk

    Pvk2pfx – pvk Mycert.pvk –spc MyCert.cer –pfx MyCert.pfx

    I’ve then installed the resulting MyCert.pfx file inside Personal store and also inside Trusted People store


    2)

    "a) You can't specify SSL certificate in web/app.config. It is configured on the server. If you're using IIS, refer to http://technet.microsoft.com/en-us/library/cc753127(WS.10).aspx ."

    I’m not using IIS

    "If you're using a self-host WCF service, use the netsh command line tool as described on http://msdn.microsoft.com/en-us/library/ms733791.aspx . The cert representing WCF service credential is configured in web/app.config."

    a) Uhm, isn’t netsh only used to configure SSL via HTTP protocol?

    b) How do I specify SSL certificate if I’m using NetTcpBinding ? You’ve said that we can’t specify SSL certificate in app.config , but in the code I've posted I did just that and it works. What am I missing?

     

    Here's the code:

     <behaviors>
     <serviceBehaviors>
     <behavior name="MyBehavior">
      <serviceCredentials>
      <serviceCertificate findValue="MyCert"
       storeLocation="CurrentUser" storeName="My" x509FindType="FindBySubjectName" />
      </serviceCredentials>
     </behavior>
     </serviceBehaviors>
     </behaviors>
     
     <bindings>
     <netTcpBinding>
     <binding name="MyBinding">
      <security mode="Transport">
      <transport clientCredentialType="None" protectionLevel="EncryptAndSign"></transport>
      </security>
     </binding>
     </netTcpBinding>
     </bindings>
    

     

    Wednesday, December 1, 2010 10:17 PM