Thanks for posting - I think it's helpful to have here since others are going to have the same question.
Instant uses a self-signed certificate. All IAPs use the *same* self-signed certificate, in fact. This certificate provides no guarantees of authenticity, which is why your browser is (should be) complaining each time you connect to manage the AP. It DOES allow you to encrypt administrative communication with the AP, but because anyone can come along and replace that certificate with their own “instant.arubanetworks.com” self-signed certificate, you have no guarantee that you’re communicating with the AP that you think you’re communicating with, unless you go through the effort to install that certificate into your browser/OS trusted certificate store. Which you should never do - because it's a common certificate that everyone uses.
The certificate being 1024-bit is the least of your worries in this case. The weakness of a 1024-bit key is that it would too easy to break the key into prime factors and recover the private key. But here it doesn't matter - everyone who buys an IAP already has the private key. The 1024-bit key is actually done on purpose, because we want you to recognize that this isn't a secure situation.
What I would suggest, in order of strongest to weakest security:
- Obtain and install a certificate from a public certificate authority. This will cost some money but there are CAs like ssls.com that are very inexpensive. You’ll need a hostname/domain name for these – they won’t issue them to IP addresses. This is, by far, the most common option. Many customers use wildcard certs for this so that they can install the same certificate on multiple devices - that is fine.
- Set up your own in-house CA, either a “real” one (e.g. Microsoft AD Certificate Services) or a roll-your-own with OpenSSL. Issue certificates to all your networked devices. Install the CA cetificate into your OS/browser certificate store. Now you'll automatically trust all of these in-house certificates.
- Create unique self-signed certificates for each device that you manage. Use OpenSSL from a Mac or Linux system to do this - there are lots of tutorials online. The danger here is that on any browser where you want to manage the IAPs, you need to tell it explicitly to install these self-signed certificates into the trusted cert store. This is the only way to be sure you're connecting with the correct device the next time you go to manage it. If you have 10 administrators, they all need to do this. If an attacker comes along and wants to impersonate one of these devices (and thus capture your admin username/password), the danger is that an administrator will see the certificate warning in the browser and think, "Ah, I must not have added this particular certificate before. Let me just click the 'install' button so I don't see this warning again..." This is why, for anything other than VERY small deployments with a single administrator, we recommend certificates that are issued from a trusted CA. You trust the CA explicitly, not the individual certificates.
Everything above is also true for controllers, which come with a factory certificate of "securelogin.arubnaetworks.com". That certificate is fine to use for captive portal for guest access (where you don't so much care about security) but it should never be used for administrative authentication. I have proposed eliminating this certificate in future ArubaOS versions and moving to a self-generated, self-signed certificate - similar to what you find in other networking products.
I hope that helps.