Figure 6-4
RADVISION | Deployment Guide for SCOPIA TIP Gateway Version 8.0
–
A root certificate from CA1 verifying CA1's identity, self-signed by trusted CA1. This is
used by the gateway to verify the certificate sent by SCOPIA Management, which is
signed by CA1.
•
Unknown SCOPIA Management CA
When SCOPIA Management's certificate is signed by a CA unknown to the gateway, you
must upload an intermediate certificate for the untrusted CA signed by a trusted CA to
vouch for its authenticity.
In the example of
Figure 6-4 on page
CA3, an unknown CA, while the gateway's certificate is signed by CA2, a trusted CA. This
requires four certificates to be uploaded to SCOPIA Management and three for the
gateway
(Figure 6-4 on page
Signature of SCOPIA Management Certificate from Unknown CA
When CA3 is untrusted by the gateway
to the SCOPIA Management are:
–
A certificate identifying SCOPIA Management, signed by CA3, a CA unknown to the
gateway. This is sent to the gateway as part of the TLS negotiation.
–
An intermediate certificate vouching for the trustworthiness of CA3, signed by trusted
CA1. This is used to trust SCOPIA Management's identity certificate, which is signed by
CA3.
–
A root certificate from CA1 verifying CA1's identity, self-signed by trusted CA1. This is
used by SCOPIA Management to authenticate the intermediate certificate, which was
signed by CA1.
–
A root certificate from CA2 verifying CA2's identity, self-signed by trusted CA2. This is
used by SCOPIA Management to authenticate the gateway's certificate, which is
signed by CA2.
On the gateway side, the certificates to be uploaded are
–
A certificate identifying the gateway, signed by trusted CA2. This certificate is sent to
SCOPIA Management as part of the TLS negotiation.
48, SCOPIA Management's certificate is signed by
48).
(Figure 6-4 on page
48), the certificates to upload
(Figure 6-4 on page
48):
Securing Your Video Network Using TLS | 48