Security

Greetings,

 

I have what seems to be a peculiar issue. We run an Aruba ClearPass VM with two Aruba wireless controllers running in active/passive mode. We also have a good number of 720 AP's that connect to these controllers.

 

We have several SSID's, but the ones affected by this issue authenticate using 802.11x.

 

Last week I was made aware that the RADIUS and HTTP server certificates were expiring. These certificates were real ones issued by third-party CA Symantec. However, instead of renewing them, I was asked to replace the certificates with a wildcard certificate we've been using recently with other gear that needed it. The reason for moving to a wildcard certificate is an obvious one; cheaper to reuse instead of getting individuals.

 

Ever since switching to wildcard certificate, we have Windows wireless clients that can no longer connect. The error logged in ClearPass is the subject of this topic:

 

EAP-PEAP: fatal alert by client - access_denied TLS session reuse error

 

I tried manually installing the wildcard certificate on a test Windows laptop that is affected by this, but it doesn't work. I also went into Group Policy and enabled acceptance of third-party and trusted peer CA's to no avail.

 

Interestingly, I use an Android phone and it connects to the affected SSID without issue. So it seems Windows clients are probably by default not seeking the updated certificate or insist in using the previous, now-outdated certificate as it's the same FQDN hostname, but using a brand new, wildcard certificate instead.

 

Any ideas?

 

Thanks in advance

You cannot use a wildcard certificate as the EAP server certificate.

Alright. How can I compel Windows to fetch the updated cert from the ClearPass?

 

---

@cappalli wrote:

You cannot use a wildcard certificate as the EAP server certificate.

---

 

Windows doesn't support wildcard cert for 802.1x authentication

Sure it does. I implemented the same wildcard certificate on a Cisco ASA VPN concentrator for AnyConnect remote access clients. It works fine.

 

Or are you saying Microsoft PEAP doesn't support wildcard?

---

@Victor Fabian wrote:
Windows doesn't support wildcard cert for 802.1x authentication

---

 

Correct. Microsoft does not accept wildcard certificates as the EAP server certificate as they are generally considered less secure.

Sweet!!!!!

 

So.... My only recourse is self-signed or purchase another real one, right?

 

And if I do self-signed, that will warn everyone that they're potentially accessing an unsafe resource when they connect, no? Or is there a way to supress that?

 

I realize I'm probably asking stupid questions to circumvent intended design, but I do appreciate your insight.

Self-signed will require the client to have the certificate installed.

Public will prompt the user to verify the server certificate but they don't have to have it installed.

For these reasons, PEAPv0/EAP-MSCHAPV2 is wildly insecure in unmanaged environments and should be avoided.

How do you suppose that our Android and iPhone user base can connect without issue?

 

My Android connects as it did before I installed the wildcard cert. I was told that the iPhone prompts to accept the certificate, but it works.

Like I mentioned, you can use a standaed public certificate and continue using PEAP if you're OK with the security implications.

So... Quick google search was an eye opener. The VAR that helped set this up for us was completely incompetent to boot.

I have to test a self-signed cert and see how I can push it with a GPO instead of going around every device.

Any tips?

Are all of the devices on your network managed?

All the laptops and wifi-enabled PC's are joined to AD. But it would require a one-time wired network connection so it fetches the update since nobody can authenticate at all now.

The phones on the other hand, are not.

If you have a mixed environment (managed and unmanaged), you should not use a self-signed certificate unless you are Onboarding the devices or using QuickConnect.

Also, some versions of Android will not accept a self-signed certificate even if it is installed.