Wireless Access

Hello Community!

 

Just wanted to ask for your thoughts.

I just recently encountered an issue with our Windows 10 laptops that suddenly can not connect to our Internal SSID that is using the WPA-2 Enterprise and Authentication server 1 is InternalServer. MAC Laptops can still connect. Also our Guest SSID that uses only PSK are still working fine for both Win10 and MAC.

It appears that the issue is related to an expired Default Server Certificate that just got expired last September 8, 2020. 

Since we are just a small company and we only have few Windows 10 users, what we did is just to manually add the Internal SSID and unticked the "Verify the server's identity by validating the certificate". The laptops able to connect to the Internal SSID after that.

My concern is, is it just fine if I just leave that Default Server Certificate for a a few months without affecting/disrupting the users (MAC or Win10) connection to the Internal SSID?

Additionally, there is another certificate that got expired at the same day as the Default Server Certificate, that is the Default CP Server Certificate. I confirmed that this is just for Captive Portal's use. We are not using Captive Portal here. Only PSK for Guest.

Another thing is there is another certificate that will expire soon next year, that is Default Web UI Server Certificate. What is the effect if this one expires?

Thank you and this is my 2nd post to Aruba Community! Sorry for the long post! Hoping for your patience!

As a long term solution, you should consider using an external RADIUS server with an internal/private or third party SSL certificate for your 802.1X authentication.

To resolve your issue now, you can replace the default IAP certificate with a third party SSL certificate

You can use OpenSSL on either Windows or a MacBook to generate the CSR and the private key:

https://knowledge.digicert.com/solution/SO27347.html

When you run the commands it will go through a wizard :
Here’s an example for the IAP CSR
openssl req -nodes -newkey rsa:2048 -keyout Controller-key.key -out Controller-csr.csr

Once you go through the wizard , two files will be generated (Controller-key.key and Controller-csr.csr)
Then create a .pem file:
Creating a .pem with the Private Key and Entire Trust Chain

1. Open a text editor (such as wordpad) and paste the entire body of each certificate into one text file in the following order:
1. Purchase and generate the certificate
2. The Private Key – Controller-key.key
3. The Primary Certificate – securelogin..crt
4. The Intermediate Certificate - IntermediateCA.crt
5. The Root Certificate - TrustedRoot.crt

Make sure to include the beginning and end tags on each certificate. The result should look like this:

-----BEGIN RSA PRIVATE KEY-----
(Your Private Key: Controller-key.key)
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate: securelogin..crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate: IntermediateCertCA.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate: TrustedRoot.crt)
-----END CERTIFICATE-----

Save the combined file as securelogin.yourdomain.pem. The .pem file is now ready to use and it can be uploaded to the IAP


Thank you

Victor Fabian

Pardon typos sent from Mobile

Thank you, Fabian! I will try this out. I have a question on the second step 1. Purchase meaning this is not for free?

1. Open a text editor (such as wordpad) and paste the entire body of each certificate into one text file in the following order:
1. Purchase and generate the certificate

Also, if I decide to let an expire certificate to run for let's say another 3 months. Will it cause any disruption later on our IAP Cluster?

 

Thank you,

John

A certificate from a public CA has some cost associated, and that can be few US$ up to hundreds p[er year.

 

You could also set up your own CA with OpenSSL or Microsoft Enterprise CA, or others. For a single certificate, it probably is not worth making that investment, and either just buy a certificate, or get away from 802.1X and use a PSK network with a long and strong PSK (think 40+ characters).

 

Disabling certificate validation on the client will put your client passwords at risk as there are known practical attacks against PEAP username and passwords when certificates are not correctly configured.

 

My recommendation would be to either deploy 802.1X completely, secured with the right certificates, device management and client certificates (EAP-TLS), which if you can do it is the absolute preferred method as you have user/device unique credentials and encryption plus the visibility and auditing from that.

 

In general, if you can't manage your certificates, either because of cost/scale/knowledge, you probably are better off with a PSK network. Long password, enter it for your users, don't give it, make sure your users don't have access to it and cannot view/export the PSK.

 

Please consult your Aruba reseller/partner if you need guidance specific to your situation.

 

Disclaimer: The recommendation is in general, so applies to most cases and there are valid exceptions. Consult an expert to reduce your security risks.

WOW SIR! Thank you so much! You have answered all my questions and worries in my mind!!!

I will make sure to follow your recommendations!

 

God Bless!