Under Server Authentication, you can define how Tectia ConnectSecure authenticates remote server hosts.
To use public keys in server authentication, define the settings as described in Managing Host Keys.
To apply certificates, define the settings as described in Managing CA Certificates.
Settings required for LDAP usage are described in Managing LDAP Server Settings.
To define regular intervals for fetching certificate revocation lists (CRLs), see Managing CRL Prefetch Settings.
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.
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:
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.
For more information on server public host keys, see Server Authentication with Public Keys.
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.
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.
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. |
On the Certificates page, you can manage trusted CA certficates.
For more information on server certificate authentication, see Server Authentication with 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.
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. |
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.
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.
If this check box is not 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. |
This element defines whether the certificates are required to be compliant with the DoD PKI (US Department of Defense Public-Key Infrastructure).
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
fails, for example, when a user tries to connect to a host
"tower
" giving only the short hostname and the certificate
contains the full DNS address "tower.example.com
".
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).
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).
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.
To add an LDAP server, click the Add button. Define the hostname and port for the 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.
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.
To add a CRL prefetch address, click Add. The CRL Prefetch dialog box opens.
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.