Defining Server Authentication

Managing Host Keys

On the Host Keys page, you can add new public host keys, define the host key acceptance policy, and view and manage known host keys used in server authentication. Known host keys mean keys already stored to the user-specific %APPDATA%\SSH\Hostkeys directory.

Figure A.37. Defining server host keys settings

	Note
	The host key policy settings have changed in version 6.1.4. Tectia Connections Configuration GUI updates the user-specific configuration automatically to use the new policy based on the old Strict host key checking, Accept unknown host keys, and Always show host key prompt settings. The interpretation of the old policy to the new policy is shown in Table A.2.

The Host Keys view includes the following options:

Check for Host Key

You can check if a public host key of a remote server exists on your client, and view its fingerprint. To check the host key, enter the name of the server in the Host field and the listener port number in the Port field, and click Check.

Note that wildcard characters are not allowed, specify the exact host name and port.

When a public host key for the specified server is found on the client, a dialog-box shows where the host key is stored and what is the fingerprint of the public key. The fingerprint is shown in the SSH Babble format, consisting of a series of pronounceable five-letter words in lower case and separated by dashes. See an example below.

Figure A.38. Server public host key information

For more information on server public host keys, see Server Authentication with Public Keys.

Delete Host Key

In case you want to delete a known public host key from the client side, enter the name of the relevant server in the Host field and the listener port number in the Port field, and click Delete.

A dialog box appears asking you to confirm or to cancel the deleting of the host key.

Add Host Key

Click the Add Key button to add a new host key to your known host keys directory. The Connection Broker opens a file manager view where you can browse to the key location and select the host key you want to copy.

Host Key Policy

Select the policy you want to apply to the checking of server host keys and to the handling of unknown server host keys.

	Note
	This setting strongly affects the security of the client side host.

The options are:

Ask - the default - the user will be asked to verify and accept the server public host keys, if the keys are not found in the host key store or if the keys have changed. The user can decide whether the key is to be stored to %APPDATA%\SSH\Hostkeys, or used once without storing it, or cancelled. Connection is allowed only to a server whose host key is either found in the known host keys directory or accepted by the user currently.
This policy requires an interactive connection to get a response from the user. If the Ask option is applied on a non-interactive connection, the connection will be closed.
Strict - the connection to the server will be allowed only if the host key is found in the user's known host keys storage. Otherwise, the connection will be closed. This option expects that all acceptable server host keys have already been stored on the client. No new host key's will be stored, and connections to any servers that have changed host keys will be closed.
This option can be used on non-interactive connections, once the host keys have been received by other means. This policy provides maximum protection against man-in-the-middle attacks.
Trust on first use - new host keys are stored without prompting the user to accept them. Connections to servers offering a changed host key will be closed. This policy should be used only when server host keys cannot be added to the key storage by any other means.

Advisory - not recommended - new host keys are stored without prompting the user to accept them, and connections are allowed also to servers offering a changed host key. Changed keys are not stored on the client, and data about opening connections with them are logged, provided that logging is enabled on the Connection Broker.

If you choose this policy, make sure the Connection Broker has logging activated in the General - Logging view, see Defining Logging Settings. Then you have the possibility to detect any connections with changed host keys in the logs.

	Caution
	Consider carefully before you activate the Advisory policy, as it practically disables server authentication and makes the connection vulnerable to active attackers.

Rotation

Select the rotation options you want to apply to the server host keys.

The options are:

No - Disables key rotation.
Yes - Enables key rotation.
Append only - Enables key rotation. When this option is selected, the new key file is appended to the keyfile, without the old keys being removed.
Tectia only - the default - Enables key rotation, but only for Tectia servers. This option requires enabling on the server also.

Managing CA Certificates

On the Certificates page, you can manage trusted CA certificates.

For more information on server certificate authentication, see Server Authentication with Certificates.

Figure A.39. Defining CA certificates

To add a CA certificate, click the Add button and select the certificate you want to add.

You can add X.509 certificate(s) as such. To add certificates from a PKCS #7 package (.p7b), you must first extract the CA certificates from the package by specifying the -7 option with ssh-keygen-g3 on the command line:

> ssh-keygen-g3 -7 certfile.p7b

You can then add the extracted CA certificates.

The following fields are displayed on the CA certificate list:

Issued to: The certification authority to whom the certificate has been issued.
Issued by: The entity who has issued the CA certificate.
Expiration date: The date that the CA certificate will expire.
Filename: The file containing the CA certificate.

CRL Checking

Select the Disable check box to prevent the use of a certificate revocation list (CRL). A CRL is used to check if any of the used server certificates have been revoked.

	Note
	Disabling CRL checking is a security risk and should be done for testing purposes only.

OCSP responder URL

The OCSP Responder Service provides client applications a point of control for retrieving real-time information on the validity status of certificates using the Online Certificate Status Protocol (OCSP).

For the OCSP validation to succeed, both the end-entity (=Secure Shell server) certificate and the OCSP responder certificate must be issued by the same CA. If the certificate has an Authority Info Access extension with an OCSP Responder URL, it is only used if there are no configured OCSP responders. It is not used if any OCSP responders have been configured.

If an OCSP responder is defined in the configuration file or in the certificate, it is tried first; only if it fails, traditional CRL checking is tried, and if that fails, the certificate validation returns a failure.

Enable endpoint identity check

Specifies whether the client will verify the server's hostname or IP address against the Subject Name or Subject Alternative Name (DNS Address) specified in the server host certificate. By default, Enable endpoint identity check is enabled (option yes). The other options are no, and ask.

If No is selected, 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.

If ask is selected, the user will be prompted to verify the certificate information and to either accept or cancel the connection.

Enforce digital signature in key usage

One of the compliance requirements of the US Department of Defense Public-Key Infrastructure (DoD PKI) is to have the Digital Signature bit set in the Key Usage of the certificate. To fulfill the compliance requirement by enforcing digital signature in key usage, select this check box.

Endpoint domain

Specify the default domain used in the end-point identity check. This is the default domain part of the remote system name and it is used if only the base part of the system name is available.

If the default domain is not specified, the end-point identity check will still work with short host names. For example, when a user tries to connect to a host "rock" giving only the short host name and the certificate contains the full DNS address "rock.example.com", the connection will be opened and Tectia Client will issue a warning about accepting a connection to "rock".

HTTP proxy URL

Specify the HTTP proxy used when making LDAP or OCSP queries for certificate validity.

The format of the address is "http://username@proxy_server:port/network/netmask,network/netmask... ". The network/netmask part is optional and defines the network(s) that are connected directly (without the proxy).

SOCKS server URL

Specify the SOCKS server used when making LDAP or OCSP queries for certificate validity.

The format of the address is "socks://username@socks_server:port/network/netmask,network/netmask... ". The network/netmask part is optional and defines the network(s) that are connected directly (without the SOCKS server).

Managing OpenSSH CA Keys

On the OpenSSH CA Keys page, you can manage OpenSSH certificates.

To add an OpenSSH certificate, click the Add button.

To delete an OpenSSH certificate, select the certificate from the list, and click Delete.

Managing LDAP Server Settings

On the LDAP Servers page, you can define LDAP servers used for fetching CRLs and/or subordinate CA certificates based on the issuer name of the certificate being validated.

CRLs are automatically retrieved from the CRL distribution point defined in the certificate to be verified if the point exists.

Figure A.40. Defining LDAP servers

To add an LDAP server, click the Add button. Define the hostname and port for the server.

Figure A.41. Adding an LDAP server

To edit an LDAP server, select the server from the list and click Edit.

To delete an LDAP server, select the server from the list and click Delete.

Managing CRL Prefetch Settings

On the CRL Prefetch page, you can define certificate revocation lists (CRLs) to be fetched from the defined location at regular intervals. The CRL distribution point can be either a standard format LDAP or HTTP URL, or it can refer to a file. The file format must be either binary DER or base64, PEM is not supported.

CRLs are automatically retrieved from the CRL distribution point defined in the certificate to be verified if the point exists.

Figure A.42. Defining CRL prefetch settings

To add a CRL prefetch address, click Add. The CRL Prefetch dialog box opens.

Figure A.43. Adding a CRL prefetch setting

Enter the URL of the CRL distribution point and the Interval how often the CRL is downloaded and click OK. The default download interval is 3600 (seconds).

In case the CRL distribution point refers to a file, enter the file URL in this format:

file:///absolute/path/name

To edit an existing CRL prefetch setting, select the setting from the list and click Edit.

To delete an existing CRL prefetch setting, select the setting from the list and click Delete.