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
enabled in the Connection Broker configuration, the client compares the server's
hostname or IP address to the Subject Name or Subject Alternative Name (DNS
Address) specified in the server certificate.
end-point-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
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.
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 Tectia Server for IBM z/OS includes two implementations of certificate authentication. One is based on keys and X.509 certificates in files and software cryptography. This is the same implementation that is available in SSH Tectia products on other platforms. The other is based on keys and certificates managed by the z/OS System Authorization Facility (SAF) and cryptographic operations handled by the z/OS Integrated Cryptographic Service Facility (ICSF).
The SSH Tectia validation can use CA certificates stored in file (CA Certificates Stored in File) or in SAF (CA Certificates Stored in SAF), or the SAF validation can be used alone (Server Certificates Stored in SAF).
SAF does a limited form of certificate checking that only determines which SAF user is the owner of the certificate. SAF does not check the contents of the certificate, such as the validity period, or check for certificate revocation. Instead of revoking a certificate the site can reduce the user's access rights in SAF.
A trusted key provider must be configured under
general/known-hosts/key-store if (only) SAF certificate
checking is to be used. If there is at least one of these elements
configured, SAF validation will be used and SSH Tectia validation will not be
To enable SAF checking of remote Secure Shell servers, their certificates can be entered into SAF as SITE keys and placed on a key ring for the trusted key provider.
The SSH Tectia Certificate Validator does a full validation of the certificate and can be configured to use external PKI services such as LDAP servers that store revocation information.
When a trusted key provider is configured under
general/cert-validation/key-store, the SSH Tectia Certificate Validator
takes its trusted CA certificates from SAF, otherwise they are read from