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 An integral part of a PKI (Public Key Infrastructure). Digital certificates (also called X.509 certificates) are issued by a certificate authority (CA), which ensures the validity of the information in the certificate. Each certificate contains identifying information about the certificate owner, a copy of the certificate owner's public key (used for encrypting and decrypting messages and digital signatures), and a digital signature (generated by the CA based on the certificate contents). The digital signature is used by a recipient to verify that the certificate has not been tampered with and can be trusted. , 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 Used to confirm the authenticity and integrity of a transmitted message. Typically, the sender holds the private key of a public/private key pair and the recipient holds the public key. To create the signature, the sender computes a hash from the message, and then encrypts this value with its private key. The recipient decrypts the signature using the sender's public key, and independently computes the hash of the received message. If the decrypted and calculated values match, the recipient trusts that the sender holds the private key, and that the message has not been altered in transit. 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 Also called a message digest, a hash or hash value is a fixed-length number generated from variable-length digital data. The hash is substantially smaller than the original data, and is generated by a formula in such a way that it is statistically unlikely that some other data will produce the same hash value. 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.