JW566AAE Aruba AW-EXF1-2500 AirWave 2500 Volume Failover Expansion License E-LTU JW567AAE Aruba AW-CONDUCTOR AirWave Conductor Console License E-LTU JX918A Aruba AirWave DL360 Professional Edition Hardware Appliance R3W19A Aruba AirWave Pro Gen 10 Hardware Appliance R1Q04B Aruba Central Ready AirWave 8 Appliance. How Generate A Private Key That Matches A Public Key Generate Rsa Key Length 4096 Generate A New Ssh Key Centos Command And Conquer Red Alert 3 Cd Key Generator Php Generate Unique Session Key Aruba Airwave Car Doesn't Generate Private Key C Code Generate 256 Bit Encryption Key Generate Public And Private Key Java. Private Key Password. Enter the private key password, then reenter it to verify the password. Private Key Type. Select the length for the generated private key types from the following options: 1024-bit RSA. X9.62/SECG curve over a 256 bit prime field. NIST/SECG curve over a 384 bit prime field.
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, Mobility Master and managed devices generate a self-signed certificate (default-self-signed) to demonstrate the authentication of the managed device for captive portal and WebUI management access while booting. The default-self-signed certificate is used as the default certificate for WebUI authentication, 802.1X termination, and Single Sign-On (SSO).
You can navigate to Configuration > System > Certificates page in the WebUI to view the details of the default-self-signed certificate. You can also use the following command to view the details in the CLI:
Aruba Airwave Doesn't Generate Private Key From Crt
(host) [mynode] # show crypto-local pki servercert default-self-signed
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha384WithRSAEncryption
Issuer: CN=ArubaMM-DC1234567.arubanetworks.com, O=Aruba Networks, C=US
Validity
Not Before: Apr 25 18:27:34 2016 GMT
Not After : Apr 18 18:27:34 2046 GMT
Subject: CN=ArubaMM-DC1234567.arubanetworks.com, O=Aruba Networks, C=US
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:98:49:30:ae:6b:11:da:19:45:ff:85:97:1c:03:
83:3a:d3:0c:42:5d:58:c9:f4:ed:fb:25:32:4e:91:
33:0d:0f:29:12:e7:30:32:64:b4:9c:ca:59:65:f3:
...
...
You may see a server certificate error while using the WebUI or 802.1X termination because the default certificate is a self signed certificate. You can view and verify the certificate to proceed further. |
Additionally, to view the fingerprint details of the default-self-signed certificate, execute the following command:
(host) [mynode] #show crypto-local pki serverCert default-self-signed fingerprint
SHA1 Fingerprint=F7:A3:01:50:BC:AA:5E:2E:8F:62:24:6F:24:B2:B5:ED:AD:D4:25:4F
There is also another server certificate, default available in ArubaOS 8.0 for demonstration purposes. However, this certificate does not guarantee security in production networks. 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: |
Parameter | Description | Range |
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. | ec/rsa |
Curve name | Length of the private/public key for ECDSA. This is applicable only if CSR Type is ec. | secp256r1/secp384r1 |
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. | 1024/2048/4096 |
Common Name | Typically, this is the host and domain name, as in www.example.com. | — |
Country | Two-letter ISO country code for the country in which your organization is located. | |
State/Province | State, province, region, or territory in which your organization is located. | |
City | City in which your organization is located. | |
Organization | Name of your organization. | |
Unit | 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 |
| | DER |
| | 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:
Command | Description |
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:
Location | Description |
/flash/certmgr/trustedCAs | Trusted CA certificates, either for root or intermediate CAs. Best practices is toimport the certificate for an intermediate CA, you also import the certificate for the signing CA. |
/flash/certmgr/serverCerts | 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. |
/flash/certmgr/CSR | Temporary certificate signing requests (CSRs) that have been generated on the managed device and are awaiting a CA to sign them. |
/flash/certmgr/publiccert | 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:
| | wlsxCertExpiringSoon |
| | wlsxCertExpired |
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
Aruba Airwave Doesnt Generate Private Key
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.
Creating a web server certificate request is very easy when using a Windows CA server. There is one disadvantage. The requested certificate is directly stored in the user store (by default) or the local computer store, if specified during the request. The disadvantage is that you cannot export the requested certificate including the private keys. During the request the option to Mark keys as exportable is grayed out.
There is a way to mark the keys as exportable when using a Windows CA server. You need to create a new Web Server Certificate template. You can use the existing Web Server Certificate Template as default and copy the current settings. To do so, you just:
- run certtmpl.msc, which will open the Certificate Template snap-in;
- click the Web Server certificate template;
- choose Action – Duplicate Template;
- configure a unique template name;
- choose the tab Request Handling;
- enable the option Allow private key to be exported;
That is all you need to do. You can now request a new certificate with the newly create certificate template. After the certificate is issued and installed on the user or local computer store, you can export the certificate including the private key.
The following two tabs change content below.- ClearPass, Azure AD, SSO and Object ID - August 12, 2021
- ClearPass – custom MPSK - July 20, 2021
- Getting your AOS-CX switch in Central - November 4, 2020