Cobalt Co9992-4ENC-4K-HEVC Software-Defined Broadcast Encoder - Manual (Page 119)

119
Certificate Validity and Expiration
All certificates have two dates built in:

A starting date and time, before which the certificate is not valid.

An ending date and time, after which the certificate is not valid.
When the certificate is generated, the user/device/process that is generating it decides on the
certificate validity. There is no practical limitation on how long a certificate may be valid for.
Administrators can decide on this as a tradeoff between security and convenience.
If certificate-based authentication is being used, it is important that the devices involved have a
way to determine “what time is it now”. NTP synchronization is highly recommended.
Blacklists
It is possible that a device goes “rogue” – in other words, it used to be authorized, but for
whatever reason, it should not be accepted anymore. In Cobalt devices, this functionality is
implemented using a list of
blocked devices . One important field in the certificate is the
Common Name – i.e., the name of the device. In a web site, this is usually the address of the
site, e.g., www.cobaltdigital.com , but it can be any text string. For Cobalt devices, the blocking
is done based on the Common Name of the device. Referring back to Figure 1, Device B will
execute an additional step after it verifies that the certificate from Device A is valid – it will
check that the Common Name is not in a list of blocked devices. If it is, Device B will refuse to
communicate, even though the certificate checks out.
Due to the nature of how certificates are generated, it is not possible to take a valid certificate
and modify the Common Name (or any of the other fields encoded in it, including the validity
date). Such an alteration will cause the certificate to become invalid (it is protected by a hash).
Signing a Certificate
Figure 1 shows a certificate that has been signed by a Certificate Authority. In order to be
secure, the signing process must not expose the device’s secret key, not the CA’s secret key. The
process uses an intermediate file called a
Certificate Signing Request , or CSR . The process is
illustrated in Figure 2.