SSH.COM is one of the most trusted brands in cyber security. We help enterprises and agencies solve the security challenges of digital transformation with innovative access management solutions.
![]() | ![]() | |
![]() | ||
![]() |
When configuring the client, it must be set up to trust the CA certificate and to access the certificate revocation list (CRL).
To configure the client to trust the server's certificate, perform the following tasks:
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).
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. |
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.