To configure the client to trust the server's SAF certificate by using SSH Tectia validation, perform the following tasks. Replace the names and IDs with those appropriate to your system:
Get the CA certificate and store it to a dataset, for example
To add the CA certificate into SAF, give the following TSO commands:
RACDCERT CERTAUTH ADD('HOSTCA.CRT') TRUST WITHLABEL('HOSTCA') RACDCERT ID(SSHD2) ADDRING(SSH-HOSTCA) RACDCERT ID(SSHD2) CONNECT(ID(SSHD2) CERTAUTH LABEL('HOSTCA') RING(SSH-HOSTCA) USAGE(CERTAUTH)) RACDCERT ID(SSHD2) LISTRING(SSH-HOSTCA)
For the settings to take effect, give the following TSO command:
SETROPTS RACLIST(DIGTCERT) REFRESH
Define the z/OS SAF external key provider that contains the CA certificates in the
<cert-validation end-point-identity-check="yes" socks-server-url="socks://fw.example.com:1080"> <ldap-server address="ldap://ldap.example.com:389" /> <ocsp-responder url="http://ocsp.example.com:8090" validity-period="0" /> <key-store type="zos-saf" init="KEYS(ID(SSHD2) RING(SSH-HOSTCA)) TRUST-ANCHORS" disable-crls="no" use-expired-crls="0" /> </cert-validation>
Define also the LDAP server(s) or OCSP responder(s) used for CRL checks. If the CA services (OCSP, CRLs) are located behind a firewall, define also the SOCKS server.
Defining the LDAP server is not necessary if the CA certificate contains a
CRL Distribution Pointor an
Authority Info Accessextension.
Setting the certificate authentication method either under default settings (
default-settings/server-authentication-methods) or per connection profile (
profiles/profile/server-authentication-methods) defines that the server must authenticate with a certificate or else the authentication will fail.
<server-authentication-methods> <authentication-method name="certificate" /> </server-authentication-methods>
For more information on the configuration file options, see ssh-broker-config(5). For information on the format of the external key initialization string, see the section called “Key Store Configuration Examples”.