Copy the CA certificate(s) to the client machine. You can either copy the X.509 certificate(s) as such, or you can copy a PKCS #7 package including the CA certificate(s).

Certificates can be extracted from a PKCS #7 package by specifying the -7 flag with ssh-keygen-g3.

Define the CA certificate(s) to be used in host authentication in the ssh-broker-config.xml file under the general element:

<cert-validation end-point-identity-check="yes" 
                 http-proxy-url="http://proxy.example.com:800">
  <ldap-server address="ldap://ldap.example.com:389" />
  <ocsp-responder url="http://ocsp.example.com:8090" validity-period="0" /> 
  <dod-pki enable="no" />
  <ca-certificate name="ssh_ca1"
                  file="ssh_ca1.crt"
                  disable-crls="no"
                  use-expired-crls="100" />
</cert-validation>         

The client will only accept certificates issued by the defined CA(s) or its subordinate CA(s). Typically, Authority Info Access URI from the server certificate is used to construct a validation path to the trusted CA. It is also possible to configure LDAP Server or add the intermediate CA certificate(s) to the user config directory as extra certificates if AIA does not exist in the certificates themselves.

You can disable the use of CRLs by setting the disable-crls attribute of the ca-certificate element to "yes".

	Note
	CRL usage should only be disabled if the CA issues short-lived certificates or for testing purposes. Otherwise it is highly recommended to always use CRLs.

Also define the LDAP server(s) or OCSP responder(s) used for CRL checks. Defining the LDAP server is not necessary if the CA certificate contains a CRL distribution point extension.

If the CA services (OCSP, CRL) are located behind a firewall, define also the SOCKS server in the ssh-broker-config.xml file. The SOCKS server is defined inside cert-validation with the socks-server-url element.