Within establishment of connection to a server application (Kerio Control or Kerio Connect — called simply server thereinafter), Administration Console (called simply client thereinafter) checks identity of the particular server. This security feature protects from so called “man-in-the-middle” attack type (the attacker pretends to be the destination server, captures client's login data and uses it to connect to the real server).
The server prooves its identity by an SSL certificate. The client compares so called certificate fingerprint with the fingerprint saved in its configuration file. If the fingerprints match each other, the connection is permitted automatically. Otherwise, intervention of the user is required.
Notes:
The check of the certificate is not applied to connections from the very host where the particular server application is installed (connection to
localhost). In such cases the “man-in-the-middle” attack would be meaningless (the attacker might harvest fragile data much more simply).Connection by Administration Console does not use the SSL certificate which is set for “client” services (web interfaces, etc.) in the server application; in such cases, a special self-generated certificate is used.
Let us suppose that Kerio Control has already been
installed on server.company.com.[1] And at the very moment, you need to connect to this server from
another host by using the Administration Console for the
first time.
Fill in the login dialog (or create a bookmark — for details, see chapter 3.2 Connection to the server and how to create bookmarks). Upon clicking on the button, a notice is displayed informing that the server identity could not be verified — see figure 3.6 Verification of the server's identity — connection to a new server.
At this point, it is time to verify whether Administration Console connects to the correct server:
In the Server textfield, check type of server application and IP address of the destination server.
If the server is defined by name and its IP address does not agree, it is necessary to verify DNS record for the particular host name or to specify the server directly by the IP address. However, bear in mind that an incorrect IP address might point at an attack attempt (fake DNS record).
Note: If the server is defined by an IP address, the DNS verification is meaningless and it is skipped.
If the server application type is not correct, it is recommended to check running server application on the particular server and attempt to connect to them locally.
Compare the certificate's fingerprint in the Certificate details entry with the fingerprint of the particular server's certificate.
If fingerprints do not match with each other, the certificate is fake.
HINT: Certificate fingerprint can be saved to the clipboard and pasted to a file, email message, etc.
If the IP address, application type and certificate's fingerprint are correct, it is possible to connect securely to the server. Otherwise, use the button to deny the connection and try to find what caused the problems.
If the address and the server certificate do not change upon the next connection, Administration Console will consider the server as trustworthy and the identity verification dialog is not opened since then.
A special, automatically generated SSL certificate is used to
secure traffic between the server application and the Administration
Console. This certificate is created upon the first startup of the
server application after the installation or/and whenever the certificate
cannot be found (it might have been removed, damaged, etc.). The certificate is
saved in file server.crt under the
dbSSL subdirectory of the installation directory of the
server application (the exact path depends on application type and on the
operating system).
The method used to detect the certificate's fingerprint depends on the operating system of the server:
- Windows
By default, the server's certificate is stored under
C:\Program Files\Kerio\WinRoute Firewall\dbSSLor
C:\Program Files\Kerio\MailServer\dbSSLA dialog with certificate information is displayed upon opening of the certificate file (by double-clicking or by pressing the Enter key).
On the Details tab, look at the Thumbprint field.[2]. This field includes the certificate's fingerprint which can be saved to the clipboard and pasted to a file, email message, etc.
- Linux and Mac OS X (Kerio Connect only)
By default, the server's certificate is stored under
/opt/kerio/mailserver/dbSSL(Linux),or
/usr/local/kerio/mailserver/dbSSL(Mac OS X).To detect the certificate's fingerprint, use the
opensslapplication (the OpenSSL package is required to be installed on the system).In the console (terminal), open the directory which includes the
server.crtfile and enter the following command:openssl x509 -in server.crt -noout -text -fingerprint -sha1This command displays certificate information, providing the certificate's fingerprint on the last line:
SHA1 Fingerprint=F4:D1:F4:49:57:99:81:10:D6:41:8F:0E:2E:A5: 77:42:80:E9:70:D0
Unless the certificate's fingerprint or IP address of the server is changed, Administration Console verifies only through username and password during future connections. The verification of the certificate and the IP address of the server is hidden and the user cannot see it.
If the certificate's fingerprint has been changed, a warning is displayed — see figure 3.8 Verification of the server's identity — detection of the certificate change.
Such a situation may occur when the server is reinstalled or when its certificate has been, by any reason, damaged or removed. In such a case, the server application has created a new certificate the fingerprint of which does not match with the fingerprint saved in the Administration Console. When we learn of such a change, verify the certificate's fingerprint applying the same mthod as for the forst connection (see above). If the new (accepted) fingerprint of the certificate matches with the server's certificate, connection can be allowed. In this case, the saved certificate's fingerprint is overwritten by the new fingerprint and no warning will be displayed upon future connections.
If the certificate on the server has not been changed, the situation might point at an attack (fake certificate). In such a case, use the button to deny the connection and try to find what caused the problems.
Note: When the server application is being upgraded, the original certificate is kept. In this case, the reinstallation means a brand new installation — for example when a new harddisk is introduced in the computer, etc.
Under certain conditions, IP address of the server can be changed (e.g. when the server is re-employed in another subnet). When IP address is changed, corresponding DNS records are usually also updated. This implies that the same DNS name is used during the following attempt for remote connection to the particular server application by Administration Console, while the IP address will be different. There are two types of Administration Console's responses to change of the server IP address:
If there is no record for the new IP address (and for the port of the particular server application) yet, Administration Console displays warning as in case of the first connection to a new server (see figure 3.6 Verification of the server's identity — connection to a new server).
If there is already a record for the new IP address and the port (i.e. Administration Console has already connected to the particular server application through the same IP address), the situation is considered and treated as a change of the server's identity (see figure 3.8 Verification of the server's identity — detection of the certificate change).
In both cases, if the change of the IP address is desirable and cognizant, check the IP address and the (new) certificate's fingerprint and accept the connection upon acknowledging that no problem is found. If the IP address has not been changed, deny the connection and try to find the cause of the problem.