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.

After the certificate has been created for a server, it can be enrolled to the client hosts.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 with 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 of the server. This check can be disabled by setting the end-point-identity-check attribute of the cert-validation element in the client configuration file to no.
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. You can configure how often the CRL is refreshed from the repository. See SSH Tectia Client User Manual for more information.

Certificate Enrollment Using `ssh-cmpclient-g3`

Certificates can be enrolled using the ssh-cmpclient-g3 command-line tool (ssh-cmpclient-g3.exe on Windows).

To configure SSH Tectia Server to authenticate itself using X.509 certificates, perform the following tasks:

Enroll a certificate for the server.
This can be done with the ssh-cmpclient-g3 command-line tool, for example:
```
$ ssh-cmpclient-g3 INITIALIZE \ 
  -P generate://ssh2@rsa:1024/hostcert_rsa \
  -o /etc/ssh2/hostcert_rsa \
  -p 62154:ssh \
  -s "C=FI,O=SSH,CN=testserv;dns=testserv.ssh.com" \
  http://pki.ssh.com:8080/pkix/ \
  'C=FI, O=SSH Communications Security Corp, CN=Secure Shell Test CA'
```
Note that the DNS address parameter (dns) needs to correspond to the fully qualified domain name of the server.
Remember to define also the SOCKS server (-S) before the CA URL, if required.
For more information on the ssh-cmpclient-g3 syntax, see ssh-cmpclient-g3(1).
Define the private key and the server certificate in the ssh-server-config.xml file:
```
<params>
  <hostkey>      
    <private file="/etc/ssh2/hostcert_rsa" />
    <x509-certificate file="/etc/ssh2/hostcert_rsa.crt" />
  </hostkey>
...
</params>
```
Alternatively, on Windows when using the SSH Tectia Server Configuration tool, enter the private key and certificate filenames on the Identity page. See Identity.
Run ssh-server-config-tool to take the new configuration in use. See ssh-server-config-tool(8).
On Windows, just click Apply to take the new settings in use.

Server Authentication with Certificates

Certificate Enrollment Using ssh-cmpclient-g3

Certificate Enrollment Using `ssh-cmpclient-g3`