... 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 1 of 12 , Jun 13, 2006View SourceDave Pawson wrote:
> I'm trying a REST mc - mc transaction, and I guess I want eitherRight. It's secure in the sense of confidential - 3rd parties cannot
> 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)
> 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.
(easily) eavesdrop the conversation. There are 3 primary areas of
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
... 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 twoMessage 1 of 12 , Jun 13, 2006View SourceAt 08:59 PM 6/12/2006, Dave Pawson wrote:
>On 13/06/06, David Cornejo <dave@...> wrote:They need to share a common certificate authority - the idea is that
>> 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
>and the client had the public key?
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 twoWikipedia actually has a good description: http://en.wikipedia.org/wiki/X.509
>> 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?
Look for "Certificate file extensions" to see the lists of formats.
>> Keys are not the equivalent of certificates - a key is just that,yes
>> 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?
>XSLT XSL-FO FAQ.