Cisco APIC-EM Security
- Information about Cisco APIC-EM Security
- Information about PKI
- PKI Planes in Cisco APIC-EM
- Cisco APIC-EM Certificate and Private Key Support
- Cisco APIC-EM Trustpool Support
- Password Requirements
- Cisco APIC-EM Ports Reference
Information about Cisco APIC-EM Security
The Cisco APIC-EM requires a multi-layered architecture to support its basic functionality. This multi-layered architecture consists of the following components:
-
External network or networks—The external network exists between administrators and applications on one side of the network, and the Grapevine root and clients within an internal network or cloud on the other side. Both administrators and applications access the Grapevine root and clients using this external network.
-
Internal network—The internal network consists of both the Grapevine root and clients.
-
Device management network—This network consists of the devices that are managed and monitored by the controller.
Any inter-communications between the layers and intra-communications within the layers are protected through encryption and authentication.
![]() Note | For information about the different services running on the clients within the internal network, see Chapter 3, Cisco APIC-EM Services. |
External Network Security
Northbound REST API requests from the external network to the Grapevine clients located within the internal network are made secure using TLS (either version 1.0, 1.1, or 1.2). The entry point to the internal network is the Grapevine client running the reverse-proxy service. The controller provides an external facing X.509 certificate on this Grapevine client. This certificate is presented by the Grapevine client running the reverse-proxy service to any incoming API request.
The external X.509 certificate that is presented by the controller is one that has been either dynamically generated and self-signed by the controller itself, or one that has been imported (user's X.509 certificate) with a private key into the controller. You have the option to either use the a self-signed X.509 certificate from the controller or to import and use your own X.509 certificate and private key. By default, the self-signed X.509 certificate presented to an API request is signed by Grapevine's internal Certificate Authority (CA). This self-signed X.509 certificate may not be recognized and accepted by your host. To proceed with your API request, you must ignore any warning and trust the certificate to proceed.
![]() Note | We recommend against using and importing a self-signed certificate into the controller. Importing a valid X.509 certificate from a well-known, certificate authority (CA) is recommended. Additionally, you must replace the self-signed certificate (installed in the Cisco APIC-EM by default) with a certificate that is signed by a well-known certificate authority for the Network PnP functionality to work properly. |
Internal Network Security
Several key intra-Grapevine communications using HTTP are sent over SSL using the internal public key infrastructure (PKI). All the internal Grapevine services, database servers, and the Cisco APIC-EM services themselves listen only on the internal network in order to keep these services segmented and secured.
Device Management Network Security
The Cisco APIC-EM REST API /network-device/management-info allows the retrieval of the list of managed network devices in the Cisco APIC-EM inventory, including the administrative credentials (SNMP community strings, CLI username and password, CLI enable password) in cleartext. The purpose of this API is to allow an external application to synchronize it's own managed device inventory with the devices that have been discovered by the Cisco APIC-EM. For example, for Cisco IWAN scenarios Prime Infrastructure makes use of this API in order to populate its inventory with the IWAN devices contained in the Cisco APIC-EM inventory in order to provide monitoring of the IWAN solution. Any user account with a ROLE_ADMIN has access to this API.
Information about PKI
The Cisco APIC-EM relies on Public Key Infrastructure (PKI) to provide secure communications. PKI consists of certificate authorities, digital certificates, and public and private keys.
Certificate authorities (CAs) manage certificate requests and issue digital certificates to participating entities such as hosts, network devices, or users. The CAs provide centralized key management for the participating entities.
Digital signatures, based on public key cryptography, digitally authenticate the hosts, devices and/or individual users. In public key cryptography, such as the RSA encryption system, each entity has a key pair that contains both a private key and a public key. The private key is kept secret and is known only to the owning host, device or user. However, the public key is known to everyone. Anything encrypted with one of the keys can be decrypted with the other. A signature is formed when data is encrypted with a sender's private key. The receiver verifies the signature by decrypting the message with the sender's public key. This process relies on the receiver having a copy of the sender's public key and knowing with a high degree of certainty that it really does belong to the sender and not to someone pretending to be the sender.
Digital certificates link the digital signature to the sender. A digital certificate contains information to identify a user or device, such as the name, serial number, company, department, or IP address. It also contains a copy of the entity's public key. The CA that signs the certificate is a third party that the receiver explicitly trusts to validate identities and to create digital certificates.
To validate the signature of the CA, the receiver must first know the CA's public key. Typically this process is handled out of band or through an operation done at installation. For instance, most web browsers are configured with the public keys of several CAs by default.
PKI Planes in Cisco APIC-EM
The Cisco APIC-EM maintains two completely separate PKI planes that do not share certificates, keys, or CAs. Each PKI plane secures a particular set of connections:
-
Controller connections
The controller's server certificate secures client-initiated connections to the controller.
The controller will present its server certificate in response to HTTPS connection requests from NB REST API callers, such as third-party applications that interact with the controller by means of its use of the NB REST API. Additionally, when a router, switch, or other control-plane device initiates an HTTPS connection to the controller to invoke a NB REST API or to download a file (such as a device image, a configuration, and so on) the server presents its certificate to the device that requested the connection.
Device interactions initiated by the controller, including actions that the controller takes on behalf of a REST caller (for example, discovering devices, managing tags or pushing policy to devices) do not currently use HTTPS.
Note
The security content and discussion in this deployment guide concerns itself solely with this PKI plane.
-
Device-to-device DMVPN connections
IWAN-managed devices form Dynamic Multipoint VPN (DMVPN) connections between themselves to fulfill IWAN QoS policy. An embedded private CA in the Cisco APIC-EM provisions the certificates and keys that secure these DMVPN connections. The PKI broker embedded in the Cisco APIC-EM manages these certificates and keys as directed by an admin in the IWAN GUI or a REST caller that uses the pki-broker NB REST API. An external CA cannot manage these certificates and keys.
Currently, IWAN application DMVPN use cases are the only ones leveraging the internal CA issued certificates. In future, there may be other services that obtain certificates from the Cisco APIC-EM internal CA.
Note
This deployment guide does not discuss the IWAN Dynamic Multipoint VPN (DMVPN) connections. For information about this topic, see the appropriate Cisco IWAN documentation.
The internal CA embedded in the Cisco APIC-EM cannot be a sub/Intermediate CA to any external CA. Until the Cisco APIC-EM adds such support, these two PKI planes remain completely independent of one another. In the current release, the IWAN devices’ mutual interaction certificates are managed only by the CA that is embedded in the Cisco APIC-EM. External CAs cannot manage the IWAN-specific certificates that devices present to each other for DMVPN tunnel-creation and related operations.
Cisco APIC-EM Certificate and Private Key Support
The Cisco APIC-EM supports a PKI certificate management feature that is used to authenticate sessions (HTTPS). These sessions use commonly recognized trusted agents called certificate authorities (CAs). The Cisco APIC-EM uses the PKI certificate management feature to import, store, and manage an X.509 certificate from well-known CAs. The imported certificate becomes an identity certificate for the controller itself, and the controller presents this certificate to its clients for authentication. The clients are the NB API applications and network devices.
The Cisco APIC-EM can import the following files (in either PEM or PKCS file format) using the controller's GUI:
![]() Note | For the private key, Cisco APIC-EM supports the importation of RSA keys. DSA, DH, ECDH, and ECDSA key types should not be imported and are not supported. You should also keep the private key secure in your own key management system. |
Prior to import, you must obtain a valid X.509 certificate and private key from a well-known, certificate authority (CA) or create your own self-signed certificate. After import, the security functionality based upon the X.509 certificate and private key is automatically activated. The Cisco APIC-EM presents the certificate to any device or application that requests them. Both the Northbound API applications and network devices can use these credentials to establish a trust relationship with the controller.
In an IWAN configuration and for the Network PnP functionality, an additional procedure involving a PKI trustpool is used to ensure trust between devices within the network. See the following Cisco APIC-EM Trustpool Support section for information about this procedure.
![]() Note | We recommend against using and importing a self-signed certificate into the controller. Importing a valid X.509 certificate from a well-known, certificate authority (CA) is recommended. Additionally, you must replace the self-signed certificate (installed in the Cisco APIC-EM by default) with a certificate that is signed by a well-known certificate authority for the Network PnP functionality to work properly. |
The Cisco APIC-EM supports only one imported X.509 certificate and private key at a time. When you import a second certificate and private key, it overwrites the first (existing) imported certificate and private key values.
![]() Note | If the external IP address changes for your controller for any reason, then you need to re-import a new certificate with the changed or new IP address. |
Cisco APIC-EM Certificate Chain Support
The Cisco APIC-EM is able to import certificates and private keys into the controller through its GUI. The Cisco APIC-EM also supports the importation of subordinate certificates (intermediate certificates) from a subordinate Certificate Authority (CA) through its GUI.
If there are subordinate certificates involved in the certificate chain leading to the certificate that is imported into the controller (controller certificate), then both the subordinate certificates as well as the root certificate of these subordinate CAs must be appended together into a single file to be imported. When appending these certificates, you must append them in the same order as the actual chain of certification.
For example, assume that a well-known and trusted CA with a root certificate (CA root) signed an intermediate CA certificate (CA1). Next, assume that this certificate, CA1 signs another intermediate CA certificate (CA2). Finally, assume that the CA certificate (CA2) was the CA that signed the controller certificate (Controller_Certificate). In this example, the PEM file that needs to be created and imported into the controller should have the following order from the top (beginning) of the file to the bottom of the file (end):
The requirement to append the root and subordinate certificates to the controller certificate to create a single file only applies to a PEM file. The requirement for appending a root and intermediate certificates to a root certificate for import is not required for a PKCS file.
Cisco APIC-EM Trustpool Support
The Cisco APIC-EM and Cisco IOS devices support a special PKI certificate store known as the trustpool. The trustpool holds X.509 certificates that identify trusted certificate authorities (CAs). The Cisco APIC-EM and the devices in the network use the trustpool bundle to manage trust relationships with each other and with these CAs. The controller manages this PKI certificate store and has the ability to update it through its GUI when certificates in the pool are due to expire, are reissued, or must be changed for other reasons.
![]() Note | The Cisco APIC-EM also uses the trustpool functionality to determine whether any certificate file that is uploaded via its GUI is a valid CA signed certificate or not. |
The Cisco APIC-EM contains a pre-installed, default, Cisco-signed trustpool bundle named ios.p7b. This trustpool bundle is trusted by supported Cisco network devices natively, since it is signed with a Cisco digital signing certificate. This trustpool bundle is critical for the Cisco network devices to establish trust with services and applications that are genuine. This Cisco PKI trustpool bundle file is available on the Cisco website (Cisco InfoSec). The link is located at: http://www.cisco.com/security/pki/.
For the controller's Network PnP functionality, the supported Cisco devices that are being managed and monitored by the controller need to import this file. When the supported Cisco devices first boot-up, they contact the controller to import this file.
![]() Note | At times, you may need to update this trustpool bundle to a newer version due to certificates in the trustpool expiring, being reissued, or for other reasons. Whenever the trustpool bundle that exists on the controller needs to be updated, you can update it by using the controller's GUI. The controller can access the Cisco cloud (where the Cisco approved trustpool bundles are located) and download the latest trustpool bundle. After download, the controller then overwrites the current, older trustpool bundle file. As a practice, you may want to update the trustpool bundle before a new certificate from a CA is to be imported using the Certificate window or the Proxy Gateway Certificate window, or whenever the Update button is active and not grayed out. |
The Cisco APIC-EM trustpool management feature operates in the following way:
-
You boot-up the Cisco devices within your network that supports the Network PnP functionality.
Note
Not all Cisco devices support the Network PnP functionality. See the Release Notes for Cisco Network Plug and Play for a list of the supported Cisco devices.
-
As part of initial PnP flow, these supported Cisco devices download a trustpool bundle directly from the Cisco APIC-EM using HTTP.
-
The Cisco devices are now ready to interact with the Cisco APIC-EM to obtain further device configuration and provisioning per the Network PnP traffic flows.
Password Requirements
The Cisco APIC-EM password policy governs password values in logins to the controller GUI, SSH logins to the Grapevine root, northbound API requests, and logins to the Grapevine console for troubleshooting. The Cisco APIC-EM rejects a password that does not conform to the password policy. If a password is rejected, the controller provides an error message that describes the reason for the rejection.
For example, Splunge! is a valid password because it meets the eight-character minimum length, contains at least one uppercase alphabetic character, contains at least one lowercase alphabetic character, and contains at least one special character (!).
Cisco APIC-EM Ports Reference
The following tables list the Cisco APIC-EM ports that permit incoming traffic, as well as the Cisco APIC-EM ports that are used for outgoing traffic. You should ensure that these ports on the controller are open for both incoming and outgoing traffic flows.
The following table lists Cisco APIC-EM ports that permit incoming traffic into the controller
Port Number |
Permitted Traffic |
Protocol (TCP or UDP) |
---|---|---|
22 |
SSH |
TCP |
67 |
bootps |
UDP |
80 |
HTTP |
TCP |
123 |
NTP |
UDP |
162 |
SNMP |
UDP |
443 |
HTTPS |
TCP |
14141 |
Grapevine console |
TCP |
16026 |
SCEP |
TCP |
The following table lists Cisco APIC-EM ports that are used for outgoing traffic from the controller.
Port Number |
Permitted Traffic |
Protocol (TCP or UDP) |
||
---|---|---|---|---|
22 |
SSH (to the network devices) |
TCP |
||
23 |
Telnet (to the network devices) |
TCP |
||
53 |
DNS |
UDP |
||
80 |
Port 80 may be used for an outgoing proxy configuration. Additionally, other common ports such as 8080 may also be used when a proxy is being configured by the Cisco APIC-EM configuration wizard (if a proxy is already in use for your network).
|
TCP |
||
123 |
NTP |
UDP |
||
161 |
SNMP agent |
UDP |
||
443 |
HTTPS |
TCP |