Mutual authentication using certificates

Mutual authentication using certificates

Authentication using digital certificates takes place in two stages:

  • The Web server where the plug-in is located identifies itself to SSL clients with its server-side certificate.
  • The Web server uses its database of Certificate Authority (CA) root certificates to validate clients accessing the server with client-side certificates. The following process takes place:
  1. An SSL client requests a connection with a Web server through the plug-in.
  2. In response, the Web server sends its public key using a signed server-side certificate. This certificate has been previously signed by a trusted third-party certificate authority (CA).
  3. The client checks whether the certificate’s issuer is one that it can trust and accept. The client’s browser usually contains a list of root certificates from trusted CAs. If the signature on the Web server’s certificate matches one of these root certificates, then the server can be trusted.
  4. If there is no match for the signature, the browser informs its user that this certificate was issued by an unknown certificate authority. It is then the user’s responsibility to accept or reject the certificate.
  5. If the signature matches an entry in the browser’s root certificate database, session keys are securely negotiated between the client and the Web server.The end result of this process is a secure channel over which the client can authenticate (for example, using a user name and password). After successful authentication, the client and server can continue to communicate securely over this channel.
  6. The client sends its public key certificate through the plug-in to the Web server.
  7. The Web server attempts to match the signature on the client certificate to a known CA using the Web server’s certificate store.
  8. If there is no match for the signature, an SSL error code is generated and sent to the client.
  9. If there is a match for the signature, then the client can be trusted. Authentication of the client takes place, resulting in a Tivoli(R) Access Manager identity.
  10. Session keys are securely negotiated between the client and the Web server. The end result of this process is a secure and trusted communication channel between the mutually authenticated client and server.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: