Server Authentication using Certificates

Certificate authentication solves some of the problems presented by public key authentication. With public key host authentication, the system administrator must either add the host public key for every server to each client's list of known hosts, or count on client users to confirm the host identity correctly when they connect to an unknown host. Certificate authentication avoids this problem by using a trusted third party, called the certification authority (CA), to verify the validity of information coming from the host.

Like public key authentication, certificate authentication uses public/private key pairs to verify the host identity. However, with certificate authentication, public keys are contained within digital certificates, and in this case, two key pairs are used; the host holds one private key and the CA holds a second. The host obtains a certificate from the CA. This certificate contains identifying information about the host, a copy of the host public key, and a digital signature created using the CA's private key. This certificate is sent to the client during the authentication process. To verify the integrity of the information coming from the host, the client must have a copy of the CA's public key, which is contained in the CA root certificate.

Installing CA root certificates to verify the host identity has several advantages over installing and configuring host public keys:

• A single CA certificate can be used to authenticate multiple servers.

• Administrators can use Windows Group Policies to install CA certificates on Windows clients.

• Root certificates for commercially obtained certificates may already be available on client computers. Windows computers have some root certificates pre-installed for use by Internet Explorer. For SSL/TLS connections, Reflection checks for certificates in this certificate store by default.

• If necessary, the host can obtain a new certificate from the same CA with no change required on client systems.

Server certificate authentication uses the following sequence of events:

1. The Secure Shell client initiates a connection.

2. The host sends its certificate to the client.

3. The client uses the CA root certificate to verify the validity of the server certificate.

   note

   The client must already have a copy of the CA certificate in the trusted root store. (A single CA certificate can be used to authenticate multiple servers.)

4. The client checks that the server information in the host's certificate matches the host being contacted.

5. To confirm that the host holds the private key that corresponds to the public key in the certificate, the client sends a challenge (an arbitrary message) to the server and computes a hash based on this message text.

6. The server creates a digital signature based on the challenge message — the server independently computes the message hash, and then encrypts the computed hash using its private key. Next, the server attaches this digital signature to the challenge and returns this signed message to the client.

7. The client decrypts the signature using the server's public key and compares the hash with its own computed hash. If the values match, host authentication is successful.

   note

   The Reflection client can verify host certificates using either the Reflection certificate store or the Windows certificate store.