Your browser does not allow storing cookies. We recommend enabling them.

Tectia

Server Authentication with Certificates

Server authentication with certificates happens similarly to server authentication with public keys, except that the possibility of a man-in-the-middle attack during the first connection to a particular server is eliminated. The signature of a certification authority in the server certificate guarantees the authenticity of the server certificate even in the first connection.

A short outline of the server authentication process with certificates is detailed below:

  1. The server sends its certificate (which contains a public key) to the client. The packet also contains random data unique to the session, signed by the server's private key.

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

  3. The client checks that the certificate matches the name or the IP address of the server. When end-point-identity-check is enabled in the Connection Broker configuration, the client compares the server's hostname or IP address to the Subject Name or Subject Alternative Name (DNS Address) specified in the server certificate.

    If end-point-identity-check is disabled in the Connection Broker configuration, the fields in the server host certificate are not verified and the certificate is accepted based on the validity period and CRL check only.

    [Caution]Caution

    Disabling the endpoint identity check on the client is a security risk. Then anyone with a certificate issued by the same trusted CA that issues the server host certificates can perform a man-in-the-middle attack on the server.

  4. The client verifies that the server has a valid private key by checking the signature in the initial packet.

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, or an OCSP responder has been separately configured. If no OCSP responder is defined or the OCSP connection fails, CRLs are used. If LDAP is used as the CRL publishing method, the LDAP repository location can also be defined in the ssh-broker-config.xml file.


 

 
What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.



    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH



    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now