Managing Certificates

The Mobility Master is designed to provide secure services through the use of digital certificates. Certificates provide security when authenticating users and computers and eliminate the need for less secure password-based authentication.

Starting from ArubaOS 8.0.1, Mobility Master and managed devices generate a default certificate (controller-issued server certificate) to demonstrate the authentication of the managed device for captive portal and WebUI management access while booting. The controller-issued server certificate is used as the default certificate for WebUI authentication, 802.1X termination, and Single Sign-On (SSO).


The default-self-signed server certificate in ArubaOS 8.0 is changed to controller-issued server certificate in ArubaOS 8.0.1.

Aruba strongly recommends that you replace the default certificate with a custom certificate issued for your site or domain by a trusted Certificate Authority (CA). This section describes how to generate a Certificate Signing Request (CSR) to submit to a CA and how to import the signed certificate received from the CA into the managed device.

The managed device supports client authentication using digital certificates for specific user-centric network services, such as AAA FastConnect, VPN (see Virtual Private Networks), and WebUI and SSH management access. Each service can employ different sets of client and server certificates.

During certificate-based authentication, the managed device provides its server certificate to the client for authentication. After validating the managed device’s server certificate, the client presents its own certificate to the managed device for authentication. To validate the client certificate, the managed device checks the certificate revocation list (CRL) maintained by the CA that issued the client certificate. After validating the client’s certificate, the managed device can check the user name in the certificate with the configured authentication server (this action is optional and configurable).


When using X.509 certificates for authentication, if a banner message has been configured on the managed device, it displays before the user can login. Click on the Login button after viewing the banner message to complete the login process.

About Digital Certificates

Clients and the servers to which they connect may hold authentication certificates that validate their identities. When a client connects to a server for the first time, or the first time since its previous certificate has expired or been revoked, the server requests that the client transmit its authentication certificate. The client’s certificate is then verified against the CA which issued it. Clients can also request and verify the server’s authentication certificate. For some applications, such as 802.1X authentication, clients do not need to validate the server certificate for the authentication to function.

Digital certificates are issued by a CA which can be either a commercial, third-party company or a private CA controlled by your organization. The CA is trusted to authenticate the owner of the certificate before issuing a certificate. A CA-signed certificate guarantees the identity of the certificate holder. This is done by comparing the digital signature on a client or server certificate to the signature on the certificate for the CA. When CA-signed certificates are used to authenticate clients, the managed device checks the validity of client certificates using certificate revocation lists (CRLs) maintained by the CA that issued the certificate.

Digital certificates employ public key infrastructure (PKI), which requires a private-public key pair. A digital certificate is associated with a private key, known only to the certificate owner, and a public key. A certificate encrypted with a private key is decrypted with its public key. For example, party A encrypts its certificate with its private key and sends it to party B. Party B decrypts the certificate with party A’s public key.

Obtaining Server Certificate

Best practices is to replace the default server certificate in the managed device with a custom certificate issued for your site or domain by a trusted CA. To obtain a security certificate for the managed device from a CA:

1. Generate a Certificate Signing Request (CSR) on the managed device using either the WebUI or CLI.
2. Submit the CSR to a CA. Copy and paste the output of the CSR into an email and send it to the CA of your choice.
3. The CA returns a signed server certificate and the CA’s certificate and public key.
4. Install the server certificate, as described in Importing Certificates.


There can be only one outstanding CSR at a time in the managed device. Once you generate a CSR, you need to import the CA-signed certificate into the managed device before you can generate another CSR.

In the WebUI

1. In the Managed Network node hierarchy, navigate to the Configuration > System > Certificates page and click the CSR section.
2. Enter the following information:

Table 1: CSR Parameters




CSR Type

Type of the CSR.

You can generate a certificate signing request either with an Elliptic curve (EC) key, or with a Rivest-Shamir-Aldeman (RSA) key.


Curve name

Length of the private/public key for ECDSA. This is applicable only if CSR Type is ec.


Key Length

Length of the private/public key for RSA.

This is applicable only if CSR Type is rsa.

NOTE: RSA-1024 is not permitted if the managed device is operating in the FIPS mode.


Common Name

Typically, this is the host and domain name, as in


Two-letter ISO country code for the country in which your organization is located.



State, province, region, or territory in which your organization is located.



City in which your organization is located.



Name of your organization.



Optional field to distinguish a department or other unit within your organization.


Email Address

Email address referenced in the CSR.


3. Click Generate New.
4. Click View Current to display the generated CSR. Select and copy the CSR output between the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST lines, paste it into an email and send it to the CA of your choice.

In the CLI

1. Run the following command:

crypto pki csr {rsa key_len <key_val> |{ec curve-name <key_val>} common_name <common_val> country <country_val> state_or_province <state> city <city_val> organization <organization_val> unit <unit_val> email <email_val>


RSA-1024 is not permitted if the managed device is operating in the FIPS mode.

2. Display the CSR output with the following command:

show crypto pki csr

3. Copy the CSR output between the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST lines, paste it into an email and send it to the CA of your choice.

Obtaining Client Certificate

You can use the CSR generated on the managed device to obtain a certificate for a client. However, since there may be a large number of clients in a network, you typically obtain client certificates from a corporate CA server. For example, in a browser window, enter http://<ipaddr>/crtserv, where <ipaddr> is the IP address of the CA server.

Importing Certificates

Use the WebUI or the CLI to import certificates into the managed device.


You cannot export certificates from the managed device.

You can import the following types of certificates into the managed device:

Server certificate signed by a trusted CA. This includes a public and private key pair.
CA certificate used to validate other server or client certificates. This includes only the public key for the certificate.
Client certificate and client’s public key. (The public key is used for applications such as SSH which does not support X509 certificates and requires the public key to verify an allowed certificate.)

Certificates can be in the following formats:

X509 PEM unencrypted
X509 PEM encrypted with a key
PKCS7 encrypted
PKCS12 encrypted

In the WebUI

1. In the Managed Network node hierarchy, navigate to the Configuration > System > Certificates page.
2. In the Import Certificates table click +.
3. For Certificate Name, enter a user-defined name.
4. For Certificate Filename, click Browse to navigate to the appropriate file on your computer.
5. If the certificate is encrypted, enter and repeat the passphrase.
6. Select the Certificate Format from the drop-down list.
7. Select the Certificate Type from the drop-down list.
8. Click Submit.
9. Click Pending Changes.
10. In the Pending Changes window, select the required check box and click Deploy changes.

In the CLI

Use the following command to import CSR certificates:

crypto pki-import {der|pem|pfx|pkcs12|pkcs7} {PublicCert|ServerCert|TrustedCA} <name>

The following example imports a server certificate named cert_20 in DER format:
crypto pki-import der ServerCert cert_20

Viewing Certificate Information

In the WebUI, the Certificate Lists section of the page lists the certificates that are currently installed in the managed device. Click View to display the contents of a certificate.

To view the contents of a certificate with the CLI, use the following commands:

Table 2: Certificate Show Commands



show crypto-local pki trustedCAs [<name>][<attribute>]

Displays the contents of a trusted CA certificate. If a name is not specified, all CA certificates imported into the managed device are displayed. If name and attribute are specified, then only the attribute in the certificate are displayed. Attributes can be CN, validity, serial-number, issuer, subject, public-key.

show crypto-local pki serverCerts [<name>][<attribute>]

Displays the contents of a server certificate. If a name is not specified, all server certificates imported into the managed device are displayed.

show crypto-local pki publiccert [<name>][<attribute>]

Displays the contents of a public certificate. If a name is not specified, all public certificates imported into the managed device are displayed.

Imported Certificate Locations

Imported certificates and keys are stored in the following locations in flash on the managed device:

Table 3: Imported Certificate Locations




Trusted CA certificates, either for root or intermediate CAs. Best practices is to import the certificate for an intermediate CA, you also import the certificate for the signing CA.


Server certificates. These certificates must contain both a public and private key (the public and private key must match). You can import certificates in PKCS12 and X509 PEM formats, but they are stored in X509 PEM DES encrypted format.


Temporary certificate signing requests (CSRs) that have been generated on the managed device and are awaiting a CA to sign them.


Public key of certificates. This allows a service on the managed device to identify a certificate as an allowed certificate.

Checking CRLs

A CA maintains a CRL that contains a list of certificates that have been revoked before their expiration date. Expired client certificates are not accepted for any user-centric network service. Certificates may be revoked because certificate key has been compromised or the user specified in the certificate is no longer authorized to use the key.

When a client certificate is being authenticated for a user-centric network service, the managed device checks with the appropriate CA to make sure that the certificate has not been revoked.


The managed device does not support download of CRLs.

Certificate Expiration Alert

The certificate expiration alert sends alerts when installed certificates, which correspond to trust chains, OCSP responder certificates, and any other certificates installed on the device. By default, the system sends this alert 60 days before the expiration of the installed credentials. This alert is then repeated periodically on a weekly or biweekly basis. This alerts consist of two SNMP traps:


Chained Certificates on the RAP

Chained certificates on the RAP (that is, certificates from a multi-level PKI) need to be in a particular order inside the file. The RAP’s certificate must be first, followed by the certificate chain in order, and then followed by the private key for the certificate. For example, with a root CA, a single intermediate CA, and a root CA, the PEM or PKCS12 file must contain the following parts, in this order:

1. RAP Certificate
2. Intermediate CA
3. Root CA
4. Private key


If this order is not followed, certificate validation errors occur. This order also applies to server certificates.

Support for Certificates on USB Flash Drives

This release now supports storing RAP certificates in a USB device. This ensures that the RAP certificate is activated only when the USB with the corresponding certificate is connected to the RAP. If the USB is removed from the RAP, the RAP certificate is deactivated and when the USB is connected to the RAP it acts a storage device and not as a 3G/4G RAP.

The RAP supports only PKCS12-encoded certificates that are present in the USB. This certificate contains all the information that is required for creating the tunnel including the private key, RAP certificate with the chain of certificates, and the trusted CA certificate. There is a limit of three supported intermediate CAs.

Ensure you adhere to the following file naming guidelines when you are saving the certificate:

The first twelve characters of the certificate file name should be the RAP's MAC address. For example, if RAP’s eth0 MAC address is 00:0b:86:c2:00:6c, then the file name will be 000B86C2006C.P12 or 000B86C2006C_rap155.p12
All alphabets of the MAC address in the file name should be in upper case.
The file name can have additional characters after the MAC address separated by "_" for the purpose of identification.

If this naming convention is not followed a error will occur during certificate validation.

Follow the steps below to configure the USB certificate store:

1. Copy the PKCS12 certificate bundle to a USB device.
2. Enter a name for the certificate using the correct naming convention as mentioned above.


In the USB connected to the RAP, delete any duplicate <mac-address>.p12 certificate file. Only one such file must be present in the USB.

If you unplug the USB device the RAP will become unresponsive. Reboot the RAP to bring it up with a custom certificate, if the USB device was unplugged.

Marking the USB Device Connected as a Storage Device

If the AP provisioning parameter “usb-type” contains the value “storage,” this indicates that the RAP will retrieve certificates from the connected USB flash drive.

RAP Configuration Requirements

The RAP needs to have one additional provisioning parameter, the pkcs12_passphrase, which can be left untouched or can store an ACSII string. The string assigned to this parameter is used as the passphrase for decoding the private key stored.


If you have an activated RAP that is using USB storage for the certificate, and you remove the USB storage, the RAP drops the tunnel. This is by design. However, for the RAP to re-establish the tunnel it has to be power cycled. It does not matter if you reinsert the USB storage before or after the power cycle as long as you power cycle it.

When the RAP successfully extracts all the information including the CA certificate, the RAP certificate and the RAP private key using the passphrase from the provisioning parameter, it successfully establishes the tunnel.