Server Authentication with Certificates

Managing CA Certificates with the Configuration File (Unix)
Managing CA Certificates with the GUI

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:

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.
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 matches the name or the IP address of the server. When endpoint identity check is enabled in the Connection Broker configuration (either in the ssh-broker-config.xml file with the cert-validation attribute end-point-identity-check, or in the Tectia Connections Configuration GUI CA Certificates page with the Enable endpoint identity check option) the client compares the server's host name or IP address to the Subject Name or Subject Alternative Name (DNS Address) specified in the server certificate.

If endpoint 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
	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.

Endpoint identity check can also be configured to make Tectia Client ask the user to either accept or cancel the connection if the server's host name does not match the one in the certificate.

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.

Managing CA Certificates with the Configuration File (Unix)

When configuring the client, it must be set up to trust the CA certificate and to access the certificate revocation list (CRL).

To configure the client to trust the server's certificate, perform the following tasks:

Copy the CA certificate(s) to the client machine. You can either copy the X.509 certificate(s) as such, or you can copy a PKCS #7 package including the CA certificate(s).
Certificates can be extracted from a PKCS #7 package by specifying the -7 flag with ssh-keygen-g3.
Define the CA certificate(s) to be used in host authentication in the ssh-broker-config.xml file under the general element:
```
<cert-validation end-point-identity-check="yes" 
                 http-proxy-url="http://proxy.example.com:800">
  <ldap-server address="ldap://ldap.example.com:389" />
  <ocsp-responder url="http://ocsp.example.com:8090" validity-period="0" /> 
  <dod-pki enable="no" />
  <ca-certificate name="ssh_ca1"
                  file="ssh_ca1.crt"
                  disable-crls="no"
                  use-expired-crls="100" />
</cert-validation>         
```
The client will only accept certificates issued by the defined CA(s) or its subordinate CA(s). Typically, Authority Info Access URI from the server certificate is used to construct a validation path to the trusted CA. It is also possible to configure LDAP Server or add the intermediate CA certificate(s) to the user config directory as extra certificates if AIA does not exist in the certificates themselves.
You can disable the use of CRLs by setting the disable-crls attribute of the ca-certificate element to "yes".
Note
CRL usage should only be disabled if the CA issues short-lived certificates or for testing purposes. Otherwise it is highly recommended to always use CRLs.
Also define the LDAP server(s) or OCSP responder(s) used for CRL checks. Defining the LDAP server is not necessary if the CA certificate contains a CRL distribution point extension.
If the CA services (OCSP, CRL) are located behind a firewall, define also the SOCKS server in the ssh-broker-config.xml file. The SOCKS server is defined inside cert-validation with the socks-server-url element.

	Note
CRL usage should only be disabled if the CA issues short-lived certificates or for testing purposes. Otherwise it is highly recommended to always use CRLs.

Managing CA Certificates with the GUI

Using the Tectia Connections Configuration GUI to manage CA certificates is described in Managing CA Certificates.