Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] more ssl clarifications please.

Expand Messages
  • Dave Pawson
    ... Yes, that s just what I want David. Do the client and server have identical certificates? I d understood that one (classically the server) had a private
    Message 1 of 12 , Jun 12 11:59 PM
    • 0 Attachment
      On 13/06/06, David Cornejo <dave@...> wrote:

      >
      > SSL is configurable to allow different levels of authentication - by default the client authenticates the server against a list of authorities. We set up a local Certificate Authority (CA) and gave both the clients and servers signed certificates and then configure the server to validate the clients certificates in addition to the default client check of the servers certificate.

      Yes, that's just what I want David.
      Do the client and server have identical certificates? I'd understood
      that one (classically the server) had a private and public key in the keystore,
      and the client had the public key?



      > Problems in importing keys usually come down to one of two things: format and a confusion of the difference between a key and a certificate. There are several formats and several quirky implementations of certificate stores, I've always managed to find the right incantation for key format conversion via Google.

      I'm currently using openssl to generate the certificate... holding the key :-)
      I've selected PKCS12 as the format.
      I've heard of, but not yet read of, and other standardised formats, nor
      that IIS or anything else required another format. Any references please?



      >
      > Keys are not the equivalent of certificates - a key is just that, a number you use to unlock the encrypted material, a certificate is a document that is signed by some authority to validate the content of the certificate. In encryption this document contains the key and some sort of identifying information.


      Key as used in GPG, Certificate as in 'signed envelope' round a key?


      Thanks David.

      regards


      --
      Dave Pawson
      XSLT XSL-FO FAQ.
      http://www.dpawson.co.uk
    • Chris Burdess
      ... Right. It s secure in the sense of confidential - 3rd parties cannot (easily) eavesdrop the conversation. There are 3 primary areas of security: 1.
      Message 2 of 12 , Jun 13 1:25 AM
      • 0 Attachment
        Dave Pawson wrote:
        > I'm trying a REST mc - mc transaction, and I guess I want either
        > both way
        > checks, or minimally I want the server to verify the client?
        > this was the opposite of Marks (more usual?) scenario where the client
        > needs to trust the server.
        >
        > I think this is where Nic's story comes in? I need to export
        > (from the server keystore) a public key with an alias for use on
        > the client
        > as Nic suggests.
        >
        > ideally I'd like to use a self certification (using the Java tools)
        > but
        > we couldn't get the java keystore values into the IIS 'store'.
        > Could be that IIS just won't play with Java (Sun).
        >
        >
        > Chris wrote
        > Why do you say "seems little better than using PKI"? It does use PKI.
        >
        > yes, I agree. And in my simplistic mode, I guess that if I could guess
        > the user name and password, then any client could access this 'secure'
        > server - which left me thinking it was too easy.

        Right. It's secure in the sense of confidential - 3rd parties cannot
        (easily) eavesdrop the conversation. There are 3 primary areas of
        security:

        1. authentication - determining the user is who they say they are
        2. authorisation - determining whether they have the right to perform
        the action they want to perform
        3. confidentiality - assuring that unauthorised parties do not have
        access to the communication

        In your example, confidentiality is assured by the use of HTTPS, and
        authentication is via HTTP Basic. You could use SSL client
        certificates instead to perform authentication if you wanted to,
        which would make the credentials more difficult to forge.
        --
        犬 Chris Burdess
        "They that can give up essential liberty to obtain a little safety
        deserve neither liberty nor safety." - Benjamin Franklin
      • David Cornejo
        ... They need to share a common certificate authority - the idea is that both the client and the server have a trust in the CA, so if the CA certifies the two
        Message 3 of 12 , Jun 13 1:42 AM
        • 0 Attachment
          At 08:59 PM 6/12/2006, Dave Pawson wrote:
          >On 13/06/06, David Cornejo <dave@...> wrote:
          >
          >>
          >> SSL is configurable to allow different levels of authentication -
          >> by default the client authenticates the server against a list of
          >> authorities. We set up a local Certificate Authority (CA) and
          >> gave both the clients and servers signed certificates and then
          >> configure the server to validate the clients certificates in
          >> addition to the default client check of the servers certificate.
          >
          >Yes, that's just what I want David.
          >Do the client and server have identical certificates? I'd understood
          >that one (classically the server) had a private and public key in
          >the keystore,
          >and the client had the public key?

          They need to share a common certificate authority - the idea is that
          both the client and the server have a trust in the CA, so if the CA
          certifies the two keys, then the client and server can trust each other.

          Therefor you need a total of three keys: one for the client, one for
          the server, and one for the CA. You use the CA key to sign the
          client and server keys.

          There are also three certificates involved for the same parties. The
          CA certificate (it essentially validates itself), and the client and
          server certificates signed with the CA key.


          >> Problems in importing keys usually come down to one of two
          >> things: format and a confusion of the difference between a key and
          >> a certificate. There are several formats and several quirky
          >> implementations of certificate stores, I've always managed to find
          >> the right incantation for key format conversion via Google.
          >
          >I'm currently using openssl to generate the certificate... holding the key :-)
          >I've selected PKCS12 as the format.
          >I've heard of, but not yet read of, and other standardised formats, nor
          >that IIS or anything else required another format. Any references please?

          Wikipedia actually has a good description: http://en.wikipedia.org/wiki/X.509

          Look for "Certificate file extensions" to see the lists of formats.






          >> Keys are not the equivalent of certificates - a key is just that,
          >> a number you use to unlock the encrypted material, a certificate
          >> is a document that is signed by some authority to validate the
          >> content of the certificate. In encryption this document contains
          >> the key and some sort of identifying information.
          >
          >
          >Key as used in GPG, Certificate as in 'signed envelope' round a key?

          yes



          >Thanks David.
          >
          >regards
          >
          >
          >--
          >Dave Pawson
          >XSLT XSL-FO FAQ.
          >http://www.dpawson.co.uk
        Your message has been successfully submitted and would be delivered to recipients shortly.