802.1x wireless authentication - RADIUS (NPS) certificate confusion

N

NSimpraga

n00b
Joined
Mar 19, 2021
Messages
4
Greetings,

I am working on a enterprise authentication system for my company. Got a NPS (RADIUS) server configured to authenticate wireless clients using PEAP-MSCHAPv2. This method uses server certificates to verify the identity of the server the client is talking to. The NPS, whose name is myNPS is joined to my cloud domain (Microsoft's cloud version of Domain Services - Azure AD Domain Services), let's say the domain name is aadds.mycompany.com, so the FQDN for my NPS is myNPS.aadds.mycompany.com.

What my end goal is - to have a proper server certificate on my NPS which is signed by a public CA, where the CA cert comes preinstalled on client devices. That way I don't have to distribute CA certs to my end-users since they use BYOD devices (privately owned).

1. Is this feasible and secure? I've read that RADIUS servers should use private CA, but in that case I need to distribute all these CAs to my end users private devices, which seems way too much of a hassle, especially with BYOD.

When connecting to the Wi-Fi from Android, for the CA field, I can select the option to 'Don't validate' which doesn't check the server certificate at all. I can authenticate just fine but no server validation means someone can steal credentials using the evil twin method.
The option I want to use is the 'Use system certificates' option together with a public CA which comes preinstalled on Android. The cert I want to try out is from Let's Encrypt whose CA is DST Root CA x3, which is preinstalled on Android.

When the 'Use system certificate' option is selected, a 'Domain' field needs to be populated. This is where it gets fuzzy for me.
So if the server certificate which was issued by a public CA has the FQDN (myNPS.aadds.mycompany.com) of my server in it, the end user needs to populate the field with that FQDN or just the domain mycompany.com?

2. Does this ensure the server verification part? A malicious actor can have a rogue RADIUS for sniffing the creds, but he shouldn't be able to have a proper certificate with my FQDN in it? Or can he?
When the user enters the FQDN, it won't match what his certificate has in it.

Do I understand this correctly?

3. Is the domain field also the indicator for the client device which CA cert from it's store to use for server verification? How exactly does it do that?

Hope I made clear what is confusing me so someone can explain the exact steps this server verification process using certificates involves. Thanks in advance!
 
I'm not at all an expert on certificates, but if your certificate is publicly available, then wouldn't someone using the same evil twin method still be able to break in because they have a valid cert?
 
No no, you mixed something up, my server cert is not public. My Certificate Authority is public, they are the ones signing my certificate. The point of that is that their CA certificates come preinstalled on smartphones so I don't have to distribute anything to my end users.
 
You are on the correct path.

The whole point of using Public CAs is because they are preloaded on all devices to allow secure connections to be built between two parties who have no connection. By using a 3rd party broker you can facilitate the connection. This is what you are doing for just about every website in existence that uses SSL, so if it's secure enough for all of your web applications it should be secure enough for connecting your clients to wireless.

Definitely do not check the "don't validate" button. At that point all the client does is take whatever certificate is available and attempt to use it to establish a connection. The point of validating the certificate is that the client won't even attempt to connect to the server until the server presents it with a valid certificate.

I'm not even 100% confident in saying I can describe the magic that happens with certificates, but to my best knowledge two things occur. First is that There is a certificate chain that the client can follow back to a certificate it already considers trustworthy. Any certificate that is presented to the client, it can do some action to determine if that certificate was issued by another certificate authority. It will do this until it reaches the root CA, which can't be validated because that server issued itself a certificate. So that's why those certificates are preinstalled and considered trusted on the device, to allow the chain to function. The other part is that in the SSL certificate itself, it contains a public key. Making an educated guess I would infer that what happens is the client will use that public key to encrypt the original bit of data it sends to the server before the session is made. Because the data is encrypted only the holder of the private key is able to decrypt that data. When you generate the certificate on the radius server you create the keypair and only that system has the private key that is capable of decrypting that traffic. So if someone were to put that public certificate onto their radius server and attempt to act as if they were legit, they would get back encrypted data but have no way to decrypt it because they don't possess the private key that matches. So in that case no they cannot gain anything from your server because they should never be getting unencrypted traffic.

Going back to that little check box about validating the server certificate. If the client didn't validate the certificate chain was legit, then I could just issue a self signed certificate on my server with the exact same hostname. Because that's what your client is looking for, your client would use the public key from the cert to encrypt the data, and because I created it I'm the one holding onto the private key. So then I would be able to successfully see all traffic the client is sending to me, including user names and passwords. I'm assuming the "evil twin" part would be after I capture that data, I simply forward it on to your server and utilize your cert and that would satisfy the server requirements on your end to let the client connect to the network.

I can't find a good example for that domain field, the best guess is that it's actually just mycompany.com
 
NSimpraga said:
No no, you mixed something up, my server cert is not public. My Certificate Authority is public, they are the ones signing my certificate. The point of that is that their CA certificates come preinstalled on smartphones so I don't have to distribute anything to my end users.
Click to expand...
Ah gotcha. That would make sense then, but I don't know enough to be of help. I'm going to stick around and learn though. (y)
 
bman212121 said:
You are on the correct path.

The whole point of using Public CAs is because they are preloaded on all devices to allow secure connections to be built between two parties who have no connection. By using a 3rd party broker you can facilitate the connection. This is what you are doing for just about every website in existence that uses SSL, so if it's secure enough for all of your web applications it should be secure enough for connecting your clients to wireless.

Definitely do not check the "don't validate" button. At that point all the client does is take whatever certificate is available and attempt to use it to establish a connection. The point of validating the certificate is that the client won't even attempt to connect to the server until the server presents it with a valid certificate.

I'm not even 100% confident in saying I can describe the magic that happens with certificates, but to my best knowledge two things occur. First is that There is a certificate chain that the client can follow back to a certificate it already considers trustworthy. Any certificate that is presented to the client, it can do some action to determine if that certificate was issued by another certificate authority. It will do this until it reaches the root CA, which can't be validated because that server issued itself a certificate. So that's why those certificates are preinstalled and considered trusted on the device, to allow the chain to function. The other part is that in the SSL certificate itself, it contains a public key. Making an educated guess I would infer that what happens is the client will use that public key to encrypt the original bit of data it sends to the server before the session is made. Because the data is encrypted only the holder of the private key is able to decrypt that data. When you generate the certificate on the radius server you create the keypair and only that system has the private key that is capable of decrypting that traffic. So if someone were to put that public certificate onto their radius server and attempt to act as if they were legit, they would get back encrypted data but have no way to decrypt it because they don't possess the private key that matches. So in that case no they cannot gain anything from your server because they should never be getting unencrypted traffic.

Going back to that little check box about validating the server certificate. If the client didn't validate the certificate chain was legit, then I could just issue a self signed certificate on my server with the exact same hostname. Because that's what your client is looking for, your client would use the public key from the cert to encrypt the data, and because I created it I'm the one holding onto the private key. So then I would be able to successfully see all traffic the client is sending to me, including user names and passwords. I'm assuming the "evil twin" part would be after I capture that data, I simply forward it on to your server and utilize your cert and that would satisfy the server requirements on your end to let the client connect to the network.

I can't find a good example for that domain field, the best guess is that it's actually just mycompany.com
Click to expand...
First of all this is a very good explanation of the whole process, makes a lot of sense so thank you for that!

Regarding the certificate chain - the client can always determine which authority signed the server certificate the server presents? If it can determine who the CA is, then the client checks its own CA certificate store to mathematically check if the CA certificate it has there has actually signed the certificate the server presented. Is this correct?

In this case, I don't understand why the domain field is actually there. Is it just some kind of double, extra check that has to match what the presented server certificate has in it? The field is actually mandatory on Android when the 'Use system certificates' option is selected, so you really have to enter a domain. I am just wondering what the role of that field is and how important it is.
 
I presumed that part, just not sure what exact role it plays in the server verification process, besides the obvious part where the entered FQDN has to match what the server cert has in it. Is it only that or does it play a role in the certificate chain hopping?
 
You must log in or register to reply here.
Back
Top