Your browser does not support HTML5 local storage or you have disabled it. Some functionality on this site, including saving your privacy settings and offering you special discounts, uses local storage and may not work with local storage disabled. We recommend allowing the use of local storage in your browser. In some browsers, it is the same setting used for disabling cookies.
Server authentication is performed using the Diffie-Hellman key exchange. This is what happens when certificates are used:
The server sends its certificate (which includes its public key) to the client. The packet also contains random data unique to the session and signed by the server's private key.
As the server certificate is signed with the private key of a certification authority (CA), the client can verify the validity of the server certificate by using the CA certificate.
The client checks that the certificate contains the fully qualified domain name of the server. (This check can be disabled by setting the Cert.EndpointIdentityCheck option in the client configuration file to no.)
The client verifies that the server has a valid private key by checking the signature in the initial packet.
When certificates are used, a man-in-the-middle attack is no longer a threat during key exchange, because the system checks that the server certificate has been issued by a trusted CA.
During authentication the system checks that the certificate has not been revoked. This can be done either by using the Online Certificate Status Protocol (OCSP) or a Certificate Revocation List (CRL), which can be published either in an LDAP or HTTP repository.
OCSP is automatically used if the certificate contains a valid Authority Info Access extension. Correspondingly, CRLs are automatically used if the certificate contains a valid CRL Distribution Point extension. If LDAP is used as the CRL publishing method, the LDAP repository location can also be defined in the ssh2_config file (see below).