13.11.2 Certificates needed for using the communication encryption function
Each manager host whose communication must be encrypted requires a private key and a server certificate. The same server certificate cannot be shared among different hosts. However, if a wildcard certificate is used, the same server certificate can be shared among different hosts. For details about wildcard certificates, see (1) Wildcard certificates.
There is no problem if the root certificate corresponding to each server certificate is different for each manager host. If the root certificates are the same, you can place only one root certificate on the manager host and the viewer host, thereby making operation easier.
If there is no need to encrypt communication for a manager host, you need not create a client certificate or a server certificate for that manager host. For details about the configuration in which a manager host that encrypts communication is intermixed with a manager host that encrypts communication, see 13.11.6(2) System configuration in which connection is established with multiple manager hosts.
If you have changed the host name of a manager host after you started using the communication encryption function and the new host name differs from CN and SAN in the server certificate, re-create the server certificate.
For details about how to re-create server certificates, see 9.4.2 Changing configured certificates in the JP1/Integrated Management 2 - Manager Configuration Guide.
- Organization of this subsection
(1) Wildcard certificates
The communication encryption function supports wildcard certificates.
A wildcard certificate is one that uses the asterisk (*) as a wildcard in a CN or SAN in a server certificate so that multiple subdomains (hosts) can be supported by a single server certificate.
For a server certificate in which the CN or SAN host name begins with an asterisk, the same server certificate can be shared among multiple hosts with different host names as long as they are all in the same domain. The asterisk can be used only at the beginning of a CN or SAN (host name part) and must be followed immediately by a period (.). An asterisk cannot be used at any location other than the beginning or in a regular expression (such as a* to indicate host names beginning with a). The wildcard cannot be used for host names in a top-level domain or a generic domain. The following table shows the validity of CN and SAN values used in wildcard certificates.
|
No. |
CN or SAN value |
Supported by JP1/IM |
|---|---|---|
|
1 |
*.example.com |
Y |
|
2 |
**.example.com |
N |
|
3 |
t*.example.com |
N |
|
4 |
*t.example.com |
N |
|
5 |
test.*.com |
N |
|
6 |
*.com |
N |
|
7 |
*.co.jp |
N |
|
8 |
*.168.0.2 |
N |
- Legend:
-
Y: Supported
N: Not supported
(2) Self-signed certificate
The communication encryption function supports not only certificates signed by a certificate authority but also self-signed certificates. If you will be using self-signed certificates, ensure that you understand the differences in characteristics from when certificates from a public certificate authority are used.
(3) Maintaining certificates
The communication encryption function checks that certificates have not expired. Ensure that your certificates have been properly maintained by renewing them before they expire. For details about the procedure, see 1.6.1 Managing the effective duration of the server certificate in the JP1/Integrated Management 2 - Manager Administration Guide.
For details about the expiration period for certificates, see 13.11.4 Verifying server certificates and 13.11.5 Verifying root certificates.