X.509 Certificate based authentication

Discussion in 'ASP .Net Security' started by gudujarlson@gmail.com, May 18, 2007.

  1. Guest

    I want to use X.509 certificates to authenticate and then subsequently
    authorize HTTP requests between a Windows Forms client and a ASP.NET
    server. So far I have accomplished all of the following:

    - created and installed a server certificate
    - setup a virtual directory to require client certificates
    - created a ASP.NET web form that displays information about the
    client certificate
    - created and installed a client certificate
    - created a Windows Form application that looks up and passes the
    client certificate in a HTTP request to the server

    Here's the guts of my client:

    Dim aRequest As System.Net.HttpWebRequest =
    CType(System.Net.WebRequest.Create("https://localhost/ssl/
    default.aspx"), System.Net.HttpWebRequest)
    aRequest.ClientCertificates.Add(certificate)

    Here's the guts of my web form:

    Dim cs As HttpClientCertificate = Request.ClientCertificate
    Response.Write("Certificate = " & cs.Certificate.ToString() &
    "<br>")

    All is working well. The cert gets passed over the wire and the
    server can read its contents. Now what?

    How do I authenticate the client?

    How to I use information from the certificate to identify the client?
    In other forms of authentication there is user identifier. What is
    the analogy with X.509 certificates? My first guess was that the
    "subject" property is the identifier, but I'm not sure that is correct
    because it does not appear to be globally unique. For example, the
    subject of my client cerificate is "localhost". I'm guessing I am not
    the only person on the planet with the same subject. How do I verify
    that the client is the _right_ "localhost"?

    How do I validate that the certificate was sent to me by it's owner?

    Does calling System.Net.HttpWebRequest.ClientCertificates.Add() cause
    the HTTP request to be signed or does it simple cause the certificate
    to be passed in the request?

    Does IIS do anything with the certificate or does it just pass it
    through the web form? I.e. does it perform any sort of validation/
    authentication?

    All help will be greatly appreciated.
    , May 18, 2007
    #1
    1. Advertising

  2. Joe Kaplan Guest

    Basically, you need to go by subject and issuer. The assumption is that
    the issuer of a certificate will guarantee the uniqueness of the subjects
    that it issues and you can restrict the list of issuers that you will accept
    certificates from.

    It is also possible that you can use certificate mapping in IIS to map
    client cert users to Windows users and do your security processing, although
    that might not be feasible.

    You have to assume that if a user successfully does client cert
    authentication with you, only that user has the private key for that
    certificate. It is basically equivalent to a user's password, so if someone
    else has the private key, they are essentially that user as well.

    HTH,

    Joe K.

    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    <> wrote in message
    news:...
    >I want to use X.509 certificates to authenticate and then subsequently
    > authorize HTTP requests between a Windows Forms client and a ASP.NET
    > server. So far I have accomplished all of the following:
    >
    > - created and installed a server certificate
    > - setup a virtual directory to require client certificates
    > - created a ASP.NET web form that displays information about the
    > client certificate
    > - created and installed a client certificate
    > - created a Windows Form application that looks up and passes the
    > client certificate in a HTTP request to the server
    >
    > Here's the guts of my client:
    >
    > Dim aRequest As System.Net.HttpWebRequest =
    > CType(System.Net.WebRequest.Create("https://localhost/ssl/
    > default.aspx"), System.Net.HttpWebRequest)
    > aRequest.ClientCertificates.Add(certificate)
    >
    > Here's the guts of my web form:
    >
    > Dim cs As HttpClientCertificate = Request.ClientCertificate
    > Response.Write("Certificate = " & cs.Certificate.ToString() &
    > "<br>")
    >
    > All is working well. The cert gets passed over the wire and the
    > server can read its contents. Now what?
    >
    > How do I authenticate the client?
    >
    > How to I use information from the certificate to identify the client?
    > In other forms of authentication there is user identifier. What is
    > the analogy with X.509 certificates? My first guess was that the
    > "subject" property is the identifier, but I'm not sure that is correct
    > because it does not appear to be globally unique. For example, the
    > subject of my client cerificate is "localhost". I'm guessing I am not
    > the only person on the planet with the same subject. How do I verify
    > that the client is the _right_ "localhost"?
    >
    > How do I validate that the certificate was sent to me by it's owner?
    >
    > Does calling System.Net.HttpWebRequest.ClientCertificates.Add() cause
    > the HTTP request to be signed or does it simple cause the certificate
    > to be passed in the request?
    >
    > Does IIS do anything with the certificate or does it just pass it
    > through the web form? I.e. does it perform any sort of validation/
    > authentication?
    >
    > All help will be greatly appreciated.
    >
    Joe Kaplan, May 22, 2007
    #2
    1. Advertising

  3. Guest

    On May 22, 10:13 am, "Joe Kaplan"
    <> wrote:
    > Basically, you need to go by subject and issuer. The assumption is that
    > the issuer of a certificate will guarantee the uniqueness of the subjects
    > that it issues and you can restrict the list of issuers that you will accept
    > certificates from.


    Thanks for your response. If the subject is guaranteed to be unique,
    how do you explain the subject of "localhost" I obtained from a
    commercial CA? Is it because subject is not unique on 30-day
    evaluation certificates? Is it documented anywhere that subject is
    unique? Should I look for such a guarantee on the CA's website? I've
    looked around a couple websites and I have not found such a
    guarantee. Why does makecert.exe allow me to create certificates with
    non-unique subjects? I'm not saying you're wrong. I'm just wondering
    why this fact is not stated very clearly somewhere.

    > It is also possible that you can use certificate mapping in IIS to map
    > client cert users to Windows users and do your security processing, although
    > that might not be feasible.


    Do you know how this works? Does IIS map the public key to a windows
    user? The subject? Something else? How does IIS identify a
    certificate uniquely?

    > You have to assume that if a user successfully does client cert
    > authentication with you, only that user has the private key for that
    > certificate. It is basically equivalent to a user's password, so if someone
    > else has the private key, they are essentially that user as well.


    What you say makes common sense to me, however an experiment I did
    does not support this. I exported my client certificate without the
    private key and then passed the public-key-only certificate along with
    my HTTPS call (System.Net.HttpWebRequest.ClientCertificates.Add). IIS
    accepted the certificate and mapped it to a windows user ID. I
    expected it to not accept it since the caller did not have the private
    key. One guess is that the .NET framework looked up the private key
    in the cert store even though I did not pass it in.
    , May 22, 2007
    #3
  4. > Basically, you need to go by subject and issuer. The assumption is
    > that the issuer of a certificate will guarantee the uniqueness of the
    > subjects that it issues and you can restrict the list of issuers that
    > you will accept certificates from.


    i would not recommend that - either use the thumbprint (which changes when
    renewing a cert) - or better use the subject key identifier.


    -----
    Dominick Baier (http://www.leastprivilege.com)

    Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

    > Basically, you need to go by subject and issuer. The assumption is
    > that the issuer of a certificate will guarantee the uniqueness of the
    > subjects that it issues and you can restrict the list of issuers that
    > you will accept certificates from.
    >
    > It is also possible that you can use certificate mapping in IIS to map
    > client cert users to Windows users and do your security processing,
    > although that might not be feasible.
    >
    > You have to assume that if a user successfully does client cert
    > authentication with you, only that user has the private key for that
    > certificate. It is basically equivalent to a user's password, so if
    > someone else has the private key, they are essentially that user as
    > well.
    >
    > HTH,
    >
    > Joe K.
    >
    Dominick Baier, May 22, 2007
    #4
  5. Joe Kaplan Guest

    I guess what I was trying to suggest is that you need to map the key
    (thumbprint, subject key identifier, raw public key) to some sort of an
    identity. That's the purpose of the certificate. You can either maintain a
    table of your own that maps the key to a specific user or you go by some
    data in the certificate like the subject name or subject alternative name.
    Otherwise you don't really have a way to know who is associated with the
    key.

    How would you approach this?

    Joe K.

    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    "Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote in
    message news:...
    >> Basically, you need to go by subject and issuer. The assumption is
    >> that the issuer of a certificate will guarantee the uniqueness of the
    >> subjects that it issues and you can restrict the list of issuers that
    >> you will accept certificates from.

    >
    > i would not recommend that - either use the thumbprint (which changes when
    > renewing a cert) - or better use the subject key identifier.
    >
    >
    > -----
    > Dominick Baier (http://www.leastprivilege.com)
    >
    > Developing More Secure Microsoft ASP.NET 2.0 Applications
    > (http://www.microsoft.com/mspress/books/9989.asp)
    >
    >> Basically, you need to go by subject and issuer. The assumption is
    >> that the issuer of a certificate will guarantee the uniqueness of the
    >> subjects that it issues and you can restrict the list of issuers that
    >> you will accept certificates from.
    >>
    >> It is also possible that you can use certificate mapping in IIS to map
    >> client cert users to Windows users and do your security processing,
    >> although that might not be feasible.
    >>
    >> You have to assume that if a user successfully does client cert
    >> authentication with you, only that user has the private key for that
    >> certificate. It is basically equivalent to a user's password, so if
    >> someone else has the private key, they are essentially that user as
    >> well.
    >>
    >> HTH,
    >>
    >> Joe K.
    >>

    >
    >
    Joe Kaplan, May 22, 2007
    #5
  6. Joe Kaplan Guest

    Inline below

    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    <> wrote in message
    news:...
    > On May 22, 10:13 am, "Joe Kaplan"
    > <> wrote:
    >
    > Thanks for your response. If the subject is guaranteed to be unique,
    > how do you explain the subject of "localhost" I obtained from a
    > commercial CA? Is it because subject is not unique on 30-day
    > evaluation certificates? Is it documented anywhere that subject is
    > unique? Should I look for such a guarantee on the CA's website? I've
    > looked around a couple websites and I have not found such a
    > guarantee. Why does makecert.exe allow me to create certificates with
    > non-unique subjects? I'm not saying you're wrong. I'm just wondering
    > why this fact is not stated very clearly somewhere.
    >


    I guess I should say that it is not typical for a CA to issue a client
    certificate with a duplicate name, but I suppose it could happen. Like
    Dominick said in his other post, the only thing that is guaranteed to be
    unique is the public key, so that or the thumbprint or subject key
    identifier would need to be used to tell different certs with the same
    subject apart. What I should have said was that the subject (or the subject
    alternative name) is the only thing you get from the cert that gives you any
    identity information about "who" owns the private key for the cert's public
    key.

    >
    > Do you know how this works? Does IIS map the public key to a windows
    > user? The subject? Something else? How does IIS identify a
    > certificate uniquely?
    >


    IIS has some flexibility in how it does this as you can create your own
    mappings in IIS to control this. At the AD level, the cert can contain an
    alternate name with the user's AD UPN in it or the AD user object might have
    the cert's subject set up as an alternate security identity name. To be
    honest, I've never done a lot with cert mapping to Windows users, so this
    isn't an area where I have a ton of expertise.

    >
    > What you say makes common sense to me, however an experiment I did
    > does not support this. I exported my client certificate without the
    > private key and then passed the public-key-only certificate along with
    > my HTTPS call (System.Net.HttpWebRequest.ClientCertificates.Add). IIS
    > accepted the certificate and mapped it to a windows user ID. I
    > expected it to not accept it since the caller did not have the private
    > key. One guess is that the .NET framework looked up the private key
    > in the cert store even though I did not pass it in.
    >


    This should not have been possible. You can't do client certificate
    authentication unless you have the private key available. Are you certain
    that the private key was not available when you did this? If you ran this
    code on the same machine, it is likely the case that the .NET client just
    looked up the certificate you supplied in the file in the store on your
    machine and accessed the private key that way. The file just serves as a
    hint on how to look up the private key. Thus I think your guess is correct
    here.
    Joe Kaplan, May 22, 2007
    #6
  7. OK - i see. Maybe i misunderstood you then.

    Right - first of all you need a list of approved=registered=trusted certs
    - i guess i would use the hash of the public key for that.

    This could be the primary key of the table - from there on you can link additional
    data (stuff that cannot be found in the cert).


    -----
    Dominick Baier (http://www.leastprivilege.com)

    Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

    > I guess what I was trying to suggest is that you need to map the key
    > (thumbprint, subject key identifier, raw public key) to some sort of
    > an identity. That's the purpose of the certificate. You can either
    > maintain a table of your own that maps the key to a specific user or
    > you go by some data in the certificate like the subject name or
    > subject alternative name. Otherwise you don't really have a way to
    > know who is associated with the key.
    >
    > How would you approach this?
    >
    > Joe K.
    >
    Dominick Baier, May 22, 2007
    #7
  8. Guest

    Thanks for all the replies. What I hear you saying are the following:

    - I cannot assume that anything is unique except the public key (or
    public key hash), unless the CA specifically asserts it is unique.
    - I can assume that IIS does authenticate that the sender of the
    certificate is the owner of the private key.
    - In general, I have to do my own identification of the client and
    subsequent authorization.

    Can you refer me to an authoritative general reference on the subject
    (e.g. a book)?

    One further question... does IIS need to talk to the Certificate
    Authority in order to authenticate the client? If not, what exactly
    am I paying for when I buy a certificate from a commercial Certificate
    Authority? Why can't I make my own certificates? I'm used to making
    my own private-public key pairs for SSH.
    , May 23, 2007
    #8
  9. Joe Kaplan Guest

    That's basically right. I'd rephrase your second point to say that the
    client "has" the private key. Ownership is more of a loaded word since it
    implies that something can be stolen but still owned by someone else. :)
    Essentially, the client signs some data using the private key during the
    exchange with the server and the server verifies the signature using the
    public key in the certificate that the client sends.

    The advantage of using commercial CAs is that they typically chain up to
    certificates that are built in to the Windows trusted root certificate
    store, so they will be trusted as coming from a known source. Certificates
    issued by roots that don't chain to a known trusted root will not verify
    automatically unless both parties choose to accept the root CA as a trusted
    root.

    If your system is issuing the client certificates, then they can be issued
    by any CA you want as long as you can convince your clients to trust the
    certificate and you configure your servers to do the same. However, if you
    need to accept arbitrary certificates, this becomes impractical.

    The primary benefit of using certificates and PKI over raw keys is that
    there is this hierarchical notion of trust that allows you to know something
    about the owners of the keys without having to exchange them manually in
    advance. Certificates also attempt to associate some identity info with a
    key as well as a validity period and usage restrictions.

    The only reason why either party would attempt to contact any of the CAs in
    the chain would be to check the certificate revocation list (CRL) of any of
    the CAs to see whether or not a particular certificate has been revoked.
    Everything else is already in the certificate itself.

    I'm not sure about a book, but perhaps Practical Cryptography would be a
    good start?

    Joe K.

    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    <> wrote in message
    news:...
    > Thanks for all the replies. What I hear you saying are the following:
    >
    > - I cannot assume that anything is unique except the public key (or
    > public key hash), unless the CA specifically asserts it is unique.
    > - I can assume that IIS does authenticate that the sender of the
    > certificate is the owner of the private key.
    > - In general, I have to do my own identification of the client and
    > subsequent authorization.
    >
    > Can you refer me to an authoritative general reference on the subject
    > (e.g. a book)?
    >
    > One further question... does IIS need to talk to the Certificate
    > Authority in order to authenticate the client? If not, what exactly
    > am I paying for when I buy a certificate from a commercial Certificate
    > Authority? Why can't I make my own certificates? I'm used to making
    > my own private-public key pairs for SSH.
    >
    Joe Kaplan, May 23, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    300
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
    Aug 18, 2005
  2. emrefan
    Replies:
    6
    Views:
    3,121
    emrefan
    Aug 29, 2006
  3. Ken Yee
    Replies:
    0
    Views:
    457
    Ken Yee
    Jul 28, 2007
  4. GaryDean

    how to sign an x.509 certificate?

    GaryDean, Sep 9, 2008, in forum: ASP .Net
    Replies:
    2
    Views:
    322
    Steven Cheng [MSFT]
    Sep 9, 2008
  5. keith

    Encrypt/Decrypt SOAP message by X.509 Certificate

    keith, Nov 26, 2008, in forum: ASP .Net Web Services
    Replies:
    1
    Views:
    1,254
    Gustavo Arellano
    Dec 15, 2008
Loading...

Share This Page