–
A root certificate 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 gateway CA
If the CA of the gateway’s certificate is unknown, it cannot be trusted unless it comes
with an intermediate certificate, which vouches for the trustworthiness of the unknown
CA. Intermediate certificates must be signed by a trusted CA.
For example, in
, the certificate identifying the gateway is signed
by CA3, which may be known and trusted by those who installed the gateway, but in this
scenario CA3 is not trusted by SCOPIA Management. Meanwhile SCOPIA Management’s
certificate is signed by CA1, a trusted CA. This scenario requires four certificates to be
uploaded to SCOPIA Management and two for the gateway (
).
Figure 6-3
Signature of Gateway Certificate from Unknown CA
When CA3 is untrusted (
), the certificates to upload to the SCOPIA
Management are:
–
A certificate identifying SCOPIA Management, signed by trusted CA1. This is sent to
the gateway as part of the TLS negotiation.
–
A root certificate from CA1 verifying CA1’s identity, self-signed by trusted CA1. This is
used by SCOPIA Management to authenticate its certificate.
–
An intermediate certificate vouching for the trustworthiness of CA3, signed by trusted
CA2. This is used to trust the certificate sent by the gateway, which is signed by CA3.
–
A root certificate from CA2 verifying CA2’s identity, self-signed by trusted CA2. This is
used by SCOPIA Management to authenticate the intermediate certificate, which is
signed by CA2.
On the gateway side, the certificates to be uploaded are (
):
–
A certificate identifying the gateway, signed by CA3, an unknown CA. This certificate
is sent to SCOPIA Management as part of the TLS negotiation.
RADVISION | Deployment Guide for SCOPIA TIP Gateway Version 8.0
Securing Your Video Network Using TLS | 47
