Daryl Williams wrote:
> oh and christer, i guess i dont know enough about
> certificates either. are you saying that both SSL snd SSH
> certificates are the same thing?
No, they're not the same thing. You could use them in exactly the same
way as an SSH key pair, but SSL X.509 certificates provides for a
powerful additional level of flexibility.
An X.509 certificate contains your public key, metadata (i.e. name,
organization, etc...) and a digital signature. The signer of a
certificate certifies that the information in the certificate is genuine.
This means that you don't have to pre-register the users public key at
the server side, as you need to do with SSH. Normally, you would instead
say "any user who presents a certificate signed by X is trusted", i.e.
the signer acts as a trusted third party. Anyone can act as a signer
(but you do, of course, need to pre-install a copy of X's certificate on
The advantage over a basic public key scheme is thus obviously that you
don't have to distribute the public key to a potentially very large
number of servers everytime you want to authorize a new user.
To mimic the basic public key scheme of SSH, you simply install
everyone's certificate on all the servers, just as you do with the SSH
public key. The user then just have to sign their own certificate to
become authorized (known as a self-signed certificate).
Just as with SSH, you can also skip the certificate (public key)
validation altogether and use an alternative application-provided
authentication mechanism, such as a username/password. The session is
still encrypted by SSL, of course.
This is where HTTPS shines over native SSL as a SOAP transport, since
HTTP provides a standard mechanism for username/password authentication
(which SOAP does not).