Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

SSH Tectia 
PreviousNextUp[Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server (M) >>
    Using SSH Tectia Server (M) >>
    Troubleshooting SSH Tectia Server (M) >>
    Configuration >>
    Authentication >>
        Server Authentication with Public Keys >>
        Server Authentication with Certificates
            Server Configuration
            Client Configuration
        User Authentication with Passwords
        User Authentication with Public Keys >>
        User Authentication with Certificates >>
        Host-Based User Authentication >>
        User Authentication with Keyboard-Interactive >>
        User Authentication with GSSAPI >>
    Application Tunneling >>
    Sample Files >>
    Man Pages
    Log Messages >>

Server Authentication with Certificates

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).

Server Configuration

Client Configuration

PreviousNextUp[Contents] [Index]


[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2005 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice

===AUTO_SCHEMA_MARKUP===