The support of certificate base login to the MM/MD provide a good security capability of the Aruba MM/MDs.
Aruba still don’t support importing the public key directly and thus your SSH public key can only be imported into the Aruba controller using an X509 certificate. Therefore we first need to create a certificate include you public and private key.
I would use openssl to create a public/private key pair and also to generate a final Self-Signed Cert for uploading to the Aruba Controller.
I would use a Window laptop and use putty for ssh.
Installing OpenSSL on Windows Machine:
Thanks to Shining Light Production for providing an installer version of OpenSSL for the Windows Machine:
We need to upload the Certificate to the Aruba Controller as a Public Certificate, browse and upload the Certificate:
Adding Mgmt Account Associated to the Cert:
Create the mgmt account with required access and associate the Certificate to the mgmt-account.
Using Putty to Login to the Controller:
We need to associate the private key on the PC to login to the Controller. However Putty requires the key to be in a specific format else it would give error as follows:
We would download Puttygen to convert the Private key in the format as suited to Putty.
Open Puttygen and use the load option to load the previously created private key. Once loaded Save the private key in the .ppk format using the Save Private Key option, also better to add the keypassphrase during saving.
Now that the Private key is converted to correct format, load the private key again to putty and ssh to the Aruba Controller. Find the following on how/where to load the Private Key in Putty:
We would be prompted to username and the Passphrase that you set during the key import. Enter the username that we created on Aruba Controller and enter the passphrase set during the private key import and you should login fine.
More details on how to setup it up on the Aruba 6.x Architecture:
Many a times we see that the CA (Third Party Certificate Authority) does not provide a chained cert rather they provide a signed Server Cert and might provide us the Intermediate CA cert and the Root CA cert separately.
In couple of cases they just provide you a signed Server Cert and might expect you to download the Intermediate cert and the Root cert and chain the final cert if required and use it. Many vendor devices do not support an unchained Server cert and they expect you to get a chained Server cert before it could uploaded to the device.
Lets see how we can generate a chained cert from an unchained certificate. I’ll use the following server cert as an example.
The above cert is a Server cert issue by “Go Daddy” well known CA. However the certificate is not chained, if you open the certificate in notepad you’ll find that it is just a Server cert.
For generating a chained cert you need to append the Server cert with the Intermediate CA cert and the Root CA cert. In our case “Go Daddy Secure Certificate Authority” is the Intermediate CA and “Go Daddy Class 2 Certificate Authority” is the Root CA.
The way you need to append the file is, you need to keep the Server cert on top, followed by Intermediate CA cert and then the Root CA cert i.e it is just the opposite as it is show in the Certificate Path on the server Cert. Open all the certificates in notepad, also open a blank notepad and copy paste the Server cert, followed by Intermediate cert and then the Root cert and save this as a final cert which should be ready to be uploaded to the device.
—–BEGIN CERTIFICATE—– Server Cert —–END CERTIFICATE———-BEGIN CERTIFICATE—– Intermediate CA Cert —–END CERTIFICATE———-BEGIN CERTIFICATE—– Root CA Cert —–END CERTIFICATE—–
All the certificates on windows 7 are stored in the windows register and not in any specific folder. You can view the certificates using the cert manager (Type certmgr.msc and it will bring up the following window).
For Mac users the certificates are stored in Keychain Access (In the Finder, open Utilities and then open Keychain Access.) These are the repositories where all the certificates are stored and referenced to check if any certificate is valid or not i.e the Certificate Authority is a Trusted Root CA or not. There are chances that the Intermediate CA certificate may have expired which will cause the entire certificate to go invalid (untrusted). In a recent incident DigiCert’s Intermediate Certificate expired, which caused multiple users to get the untrusted certificate error.
The expired certificate in question was the “DigiCert High Assurance EV Root CA” [Expiration July 26, 2014] certificate. This temporary intermediate certificate was used in years past as part of a compatibility chain for older devices.The problem was related to the locally installed legacy intermediate certificate that was no longer used and no longer required for the certificate installation. This certificate was not been used for over three years and was unnecessary for installations, however the device having issues were not updated. The users affected appear to have the expired intermediate in the ‘login’ keychain or stored locally on their server or in have the expired intermediate installed on a backend server or application.
DigiCert fixed the issue for the customer’s by getting the old cert removed from their machines and new valid Intermediate cert updated on these devices.
How to create the chained cert when the Root CA cert and Intermediate CA cert is not provided the CA:
Usually your CA will provide you the Intermediate CA cert and the Root CA cert or the steps to get them from their Website. However if this is not the case for you and if these are some well known CA’s we should already have their Intermediate and Root cert on your laptop in the registry or the Keychain Access. Lets see how we can get the Intermediate and the Root CA certificate.
Click on the Server cert to open it. Goto the “Certificate path” click on the Intermediate Certificate for your test certificate it is “Go Daddy Secure Certificate Authority”
Click on View Certificate on the lower right corner, which will open up the Intermediate CA cert. Now we want to export this cert so that we can use the cert for chaining. Goto the Details tab for the certificate.
Click on Copy to File, which should open up the export Wizard.
Click Next > Choose the format : ” Base-64 encoded x.59″
Click on Next > Browse and give a name to the file. (Remember this is the Intermediate CA cert so save it some where on your laptop and give it a name like intermediatecert). Click Next and Finish. This will successfully export the Intermediate CA cert on you desktop, now repeat the same process to get the Root CA cert exported on your desktop you click on the Root CA cert in the server or the Intermediate CA cert.
Once you have successfully exported both the Intermediate and the Root CA cert you can open them in notepad and append the Server cert as we already discussed initially.
The certificates are stored in the registry at: HKLM/Software/Microsoft/SystemCertificates
Personal certificates, or other certificates specific to the logged in user are at: HKCU/Software/Microsoft/SystemCertificates
They are stored as binary blobs, so they need to be decoded, and the MMC plugin is a good way to do this.