none
.NET SSLStream - AuthenticateAsClient - what is targetHost RRS feed

  • Question

  • I was referring to this this method from .NET SSLStreams class

    publicvirtualvoid AuthenticateAsClient(string targetHost,....). What is the "targetHost" value should be ?

    Should it be the DNS/IP of the target(server) computer ? OR

    Should it be the common name(CN) of the Server's certificate(public part) ? If it is this, how can the client application

    gets this value? I'm assuming this field has to be some kind of input to application and user has to read this value from

    ccertificate, which means user will need access to certficate/certstore.

    I read MSDN documentation but felt it did not clarify this point completely. Can any one please provide me more details

    on this and any best practices on the same.

    Thanks,

    Darbha

    Thursday, August 1, 2013 5:47 AM

Answers

  • Hello,

    Welcome to  MSDN forum.

    According  to your description , you have  doubt about  targetHost  is in SslStream.AuthenticateAsClient Method . In fact ,the rules vary slightly depending on the protocol. Cross-protocol harmonisation efforts have been made in RFC 6125: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key nfrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS).

    In short, if the certificate has Subject Alternative Name (SAN) extensions of DNS  type, one of them must be the target host name you're trying to connect to. When there are no such extensions, you must look into the Subject DN of the certificate and find the Common Name (CN) RDN: it must match the target host name.

    Hope these help, have a nice day!

    Best
    regards,

     


    Lilia Gong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.



    • Edited by Lilia gong - MSFTModerator Friday, August 2, 2013 5:14 AM
    • Marked as answer by DarbhaK Friday, August 2, 2013 7:26 AM
    • Unmarked as answer by DarbhaK Friday, August 2, 2013 7:27 AM
    • Marked as answer by DarbhaK Thursday, August 8, 2013 3:01 AM
    Friday, August 2, 2013 5:13 AM
    Moderator
  • Hi DarbhaK,

    Thank you for you reply.

    There's some inconsistency between SSL implementations on how they match wildcards, however you'll need the root as an alternate name for that to work with most clients.

    A "*" wildcard character maybe used as the left-most name component in the certificate. For example,*.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.

    The canonical answer should be in RFC 2818 (HTTP Over TLS) :

    Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., .a.com matches foo.a.com but not bar.foo.a.com. f.com matches foo.com but not bar.com.

    Hope this help, have a nice day.

    Best Regards,


    Lilia Gong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Friday, August 2, 2013 9:17 AM
    Moderator

All replies

  • Hello,

    Welcome to  MSDN forum.

    According  to your description , you have  doubt about  targetHost  is in SslStream.AuthenticateAsClient Method . In fact ,the rules vary slightly depending on the protocol. Cross-protocol harmonisation efforts have been made in RFC 6125: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key nfrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS).

    In short, if the certificate has Subject Alternative Name (SAN) extensions of DNS  type, one of them must be the target host name you're trying to connect to. When there are no such extensions, you must look into the Subject DN of the certificate and find the Common Name (CN) RDN: it must match the target host name.

    Hope these help, have a nice day!

    Best
    regards,

     


    Lilia Gong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.



    • Edited by Lilia gong - MSFTModerator Friday, August 2, 2013 5:14 AM
    • Marked as answer by DarbhaK Friday, August 2, 2013 7:26 AM
    • Unmarked as answer by DarbhaK Friday, August 2, 2013 7:27 AM
    • Marked as answer by DarbhaK Thursday, August 8, 2013 3:01 AM
    Friday, August 2, 2013 5:13 AM
    Moderator
  • Hi,

    Thanks very much for your reply!. Just one follow-up questions

    Is there any wildcard matching on the client side, i.e. could a client specify "*" as targetHost to match any certificate or "*.example.com" to match certificates under the example.com domain? If not, how should a client that doesn't care about the server name proceed to connect to a server?

    Thanks,

    Darbha

    Friday, August 2, 2013 7:31 AM
  • Hi DarbhaK,

    Thank you for you reply.

    There's some inconsistency between SSL implementations on how they match wildcards, however you'll need the root as an alternate name for that to work with most clients.

    A "*" wildcard character maybe used as the left-most name component in the certificate. For example,*.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.

    The canonical answer should be in RFC 2818 (HTTP Over TLS) :

    Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., .a.com matches foo.a.com but not bar.foo.a.com. f.com matches foo.com but not bar.com.

    Hope this help, have a nice day.

    Best Regards,


    Lilia Gong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Friday, August 2, 2013 9:17 AM
    Moderator
  • Thank you very much for you answers. That clarified the subject clearly!!.

    Thanks,

    Darbha.

    Thursday, August 8, 2013 3:02 AM
  • Hi,

    I have hit another question while working on this..

    If I use wildcard "*" for the targetHost, would that match all the certificates in Windows store?

    If yes, I was thinking, I can use RemoteCertificateValidationCallback to identify the required server certificate myself based on my own logic

    Thanks,

    Kiran

    Thursday, August 22, 2013 12:42 PM