To configure the client to trust the server's certificate by using CA certificates stored in a file, perform the following tasks. Replace the names and IDs with those appropriate to your system:
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
option 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" 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" /> <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).
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 for testing purposes. Otherwise it is highly recommended to always use CRLs. |
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 Point
or an Authority Info Access
extension.
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> <auth-server-certificate /> </server-authentication-methods>
For more information on the configuration file options, see ssh-broker-config(5).