Appendix B: Certificates; Overview - AMX NX-1200 Webconsole And Programming Manual

Appendix B: Certif icates

Overview

In any security scenario, it is important that the private key is protected. If the private key is compromised, the entire security chain
breaks down and is subject to decryption by outside parties. The following table lists certificates supported by NX Masters:
Supported Certif icates
Certif icate Type
Trusted CA
CRL (Certificate Revocation
List)
Device Certificate and
Private Key
NetLinx/SSH Private Key
802.1x Certificate
Audit Log Certificate and
Private Key
HTTPS KeyStore
Duet TrustStore
NOTE: Existing secure sites coming from 1.4 using LDAPS should continue to work for user authentication. However, in NetLinx
Studio, the Certif icate Manager may show an LDAP CA as an 802.1x certif icate. This is due to previous versions of Studio sending
.pem f iles to the 8021x directory. It is recommended that the LDAP CA be removed from the 802.1x type, and re-sent to the NX as a
Trusted CA type.
NOTE: Existing installations that used basic FTP and installed the LDAP CA in user/certs will NOT show up in the Certif icate Manager.
However, auth will still be available for most access.
NOTE: For LDAPS connections, specif ically FTP/SSH, the CA must be in the Trusted CA store otherwise the NX will authorize, but FTP/
SSH will fail. This is not required for instances where the Controller authorizes the activity (HTTP, ICSP).
NX-Series Controllers - WebConsole & Programming Guide
Format Function
PEM A list of trusted Certificate Authorities (CAs) for verifying secure connections include
Secure-ICSP (ICSPS), TLS_CLIENT_OPEN, Audit Log, and LDAPS. For Secure ICSP
connections, this only works when the NX Master is used as a client (contains an entry
in the URL list). An audit log trusted CA must be specified when configuring remote
logging. The primary usage for Trusted CAs is to enable validation of remote sites
based on the site certificate.
PEM A list of compromised certificates that should no longer be trusted. The primary usage
of CRLs is to prevent a secure connection to a remote site. Since CAs must be loaded
manually, this type should be rarely needed for a well-defined system that does not
connect to random sites.
PEM A certificate and private key (must be generated together) used in Secure ICSPS
connections. The primary use of custom device certificates and private keys is to
conform to unique site-specific certificate/security policies.
NOTE: These must be added in pairs to work. The key has no use without the
public certif icate, and vice versa.
SSH-Private Key A private key (generated by SSH-keygen) to connect to a remote system using
passwordless/PKI authorization. This is NOT an X.509 certificate, but the X.509-like/
SSH custom form used by most SSH client/servers. The primary reason for SSH
private key usage is to connect to a remote server without a plain-text password in the
NetLinx program.
PEM Used by the upstream switch/RADIUS server for network authorization.
PEM A certificate and private key used for authorization on the Remote Syslog server. This
certificate is used only when the audit log is sending data to a remote server. The
primary reason for audit log certificates is to encrypt the logging connection to the
Remote Syslog server.
NOTE: These must be added in pairs to work. The key has no use without the
public certif icate, and vice versa.
JKS (Java KeyStore/ The default HTTPS store is auto-generated at the first boot. A user KeyStore should
Keytool) include the private key, the device certificate as well as the signer's certificate. The
primary reason for updating the HTTPS KeyStore is to prevent the security exception
warning when connecting to the NX over HTTPS.
JKS (Java KeyStore/ The Duet TrustStore is the default shipped with Java. If additional CAs are required,
Keytool) they should be added to the original. A user-provided Duet TrustStore is NOT in
addition to a system TrustStore. The primary reason for doing this is to add a
self-signed/internally signed CA for a server to enable HTTPS connections to RMS.

Appendix B: Certificates

133