1

We are a school using WPA2-Enterprise with PEAP for WiFi authentication. We use Microsoft NPS as the Radius server. The certificate in place is expiring and I need to renew it (first time for me). Currently we are using a certificate issued to nps..ca (which does not exist but the dns alias points to nps..local as CAs don’t issue certificates for internal domain names) which is working although all IOS and Android devices get a prompt to trust the certificate the first time they connect. Not a big deal, I can live with this. However the cert was issued by DigiCert before my time here and to renew it is $800 USD. This seems crazy expensive just to do what we’re doing with it. I’m looking at options such as using a Godaddy certificate ($80) or setting up an internal CA (free).

Since we are using this certificate internally only, do I even need a third party certificate? It seems like users will be prompted regardless unless I distribute the certificate chain to all devices (not an option as the campus is filled with hundreds of BYOD devices we have no control over).

Any reason not to just set up an internal CA and save money?

8 Spice ups
2

all these devices connect internally?

3

I’m not sure what you mean by internally but all these devices just connect to our campus WiFi SSID that uses WPA2-Enterprise authentication. I guess you could refer to that as internal use only?

4

Didn’t understand. Are you a volunteer of are you paid staff? Are all components needed for setting up internal CA already present or do you need to make equipment purchases to become able to setup that infrastructure? Are all people involved in setting up and operating internal CA already trained or will they need additional training usually costing time and money at least?

So don’t yet believe that such an endeavor is free.

Didn’t understand why this wouldn’t be an option. Isn’t that part of setting up an internal CA?

And are you sure that the existing public certificate isn’t used for other purposes too? Seeing what is certified in that public certificate, you might even be right in your assessment.

Don’t know how you do currently and how you plan to do certificate management. So if certificates at your school don’t serve any other purposes, you might go on and opt for setting up internal CA. There might be other parties at your school which might be interested too in such an internal CA which might change the usage and your perceiption. If done properly, you might then reapply for a different public certificate certifying your internal CA root and ending up with more uses of certificates then you’re currently aware of.

Although I’m not sure, there is high probability that your school also uses other public certificates for other purposes already. Setting up an internal CA will probably and should coordinate those probably several and currently uncoordinated public certificates. I expect such other certificates for parts of the communication of your school with some public authorities and with the public at large. The latter one could be free and the former one paid by some other party.

5

Thanks for the reply.

Yes we already have the infrastructure to set up an internal CA using our Windows servers. What I mean by free is there is no cost to that (the servers and OSs etc are already set up) as opposed to a public certificate that we need to pay for.

Setting up an internal CA is just to be able to issue our own server side certificate as opposed to buying one from a public certificate authority. It’s my understanding (and I could be wrong here) that if we didn’t want client devices to complain/prompt to trust our internal certificate when connecting to our wifi we would have to somehow distribute the internal certificate chain to all client devices. While technically this could be an option, it would be a logistical nightmare so realistically it’s not an option. It was my understanding (and I could be wrong here too) that using a public certificate, clients already come preloaded with the certificate chain to trust this certificate and as such would not get prompted. Although they are getting prompted still with our current public certificate (not sure why the clients aren’t trusting it since it’s issued by Digicert).

As to your question about other certificates, yes we have other certificates as well for our organization that are separate from this. They don’t come into the picture here. It’s only the nps..ca certificate that is expiring. This certificate is only used for WiFI authentication and nothing else.

So, I guess my question can be summarized like this: Since it appears clients are getting prompted to trust the certificate with a public cert anyway, what’s the point of paying for one if we get the same behaviour with an internal certificate that we don’t have to pay for? Or am I missing something and an internal certificate won’t work at all?

6

if it is a public cert, and they are geting prompted, that means it is set up wrong. you mentioned that you have a .ca pointed to a .local? “certificate issued to nps..ca (which does not exist but the dns alias points to nps..local” not sure how that would even work. the basics of a cert are that the domain names have to match what is stored in the certificate. You can have other names, but they all have to be part of the same domain.

when you say they are getting a warning, are you talking about the wifi login screen that companies put up before they log into the wifi?

something like this?

Capture.png
Capture.png752×410 120 KB
7

It’s very possible it’s set up wrong from the start. I’m inheriting this setup and have never been very good with certificates so it’s possible it’s wrong.
The public certificate currently in use is issued for nps..ca. The actual hostname of the Windows NPS server is nps01..local. Now a public certificate can not be issued for a .local domain so I’m guessing the people who set it this up prior to me taking over issued it for nps..ca and then creating an internal DNS alias for it to point to the same IP as nps01..local, thinking that would suffice. Obviously this does not appear to be the case. Below is what a client would see on a Windows computer (left) and an iphone (right. Ignore the expiry date, it’s an old screenshot):

cert.jpg
cert.jpg800×422 101 KB
So does the certificate have to match the computer name of the NPS server (in this case nps01..local). If so, how would one use a public certificate on an internal server (with a .local hostname) if certificates cannot be issued for .local domains?
8

ok. looks like you have a couple of issues going on, and i think we will need some more info.

how are users set up to log into the network, what is doing the authentication?

the NPS server has to be authorized in the domain:

as far as the certificate, according to your picture, it looks like it expired in 2013?

9

Ok it goes like this from what I understand:

  1. Client (Windows, iOS, Android, whatever) connects to o WPA2-Enterprise SSID called ‘Student’ which is broadcast by Cisco Access Points in some buildings, Unifi Access Points in other buildings

  2. Since the authentication method is WPA2-Enterprise the clients specifies their Active Directory username and password instead of a pre-shared key or something

  3. The AP passes on the authentication request to the configured RADIUS server (in this case Microsoft NPS, running on a Windows server with hostname: nps01..local)

  4. The RADIUS/NPS server sends back the configured certificate to the client saying here’s a cert to prove I am who I say I am

  5. Client either already trusts the cert and says okay automatically and connects to the network OR doesn’t trust the cert and issues the prompt in the screenshot above and says “I don’t trust this cert, do you want to manually go ahead and trust it anyway?” and connects to the network

The NPS server is already authorized in Active Directory (or wifi currently wouldn’t work)

I mentioned above to ignore the cert expiry date as the screenshot is an old one.

10

ok. thanks for the info.

if the clients are getting the error already then it wouldn’t matter if you put a internal CA cert in. their device wont trust it any way. they will get an error either way unless they add it to their trusted certificate store on the device.

after a little google-fu, i did find this link that seems to show your error and validate that the issue is that the certificate is not trusted

11

Thank you, so it seems like if we want to just continue as we currently are, being okay with that prompt, there is no point in renewing the public cert and just set up our own internal CA and issue a cert that way.

Say we did want to fix this prompt so it doesn’t happen at all and go with a public cert, do you have any thoughts on how to accomplish that when we can’t get a certificate issued for a .local domain name?

12

For WPA2-Enterprise you should use an internal CA, which will auto-renew it’s certificates to clients via GPO and itself.

The root CA should be set to 30 years

Ideally you want 3 boxes

Root - not domain joined, powered off most of it’s life

Subordinate CA - in the domain and doing the issuing

Web/CRL server to do revocation or certificates for network devices that cannot ask for them via active directory or automatic enrolment.

If you prefer not to use Windows there are many other CAs out there, Windows one with AD just makes it simpler.

1 Spice up
13

Only about 100 out of 1000 of our devices would be domain joined to pushing out the cert via GPO doesn’t really help much. You mention using a Web/CRL server for the devices that don’t get it via GPO. If we don’t care about the certificate trust prompt, is it still necessary for them to get the cert on their device for this to work at all?

@rod-it

14

If your devices are not domain joined, why do you need a certificate to validate them on Wi-Fi?

The purpose of WPA2-Enterprise with certificates is to confirm the devices connecting to the corporate Wi-Fi, as if they was LAN based clients is to confirm they also meet the domain authentication. One has to assume if these non-domain joined devices are on your regular corporate network, you have a way to manage them, validate they are not infected, especially if they are accessing your corporate resources?

Also, they have AD credentials to access network resources or not?

Given your last post I am struggling to understand the reason for the certificate at all.

I could get a certificate from your trusted CA and get on your network with this, there’s no validation going on really.

15

It’s very possible I’m not understanding how this works so bear with me. The reason we want to use WPA2-Enterprise is because we want everyone to use their individual student AD accounts to connect to the WiFi. You have to be a student here and have an active AD account in order to get on the WiFi. This gives us the ability to restrict who can connect to the wifi, revoke access by disabling the account, and give us the ability to track abuse in some way. The devices are restricted from accessing most corporate resources by network segregation so that is not as much a concern.

We do not have any control over the devices to confirm they are not infected etc. There’s just no practical way to do that with so many BYOD devices coming and going.

16

yea. that is my opinion, it doesn’t matter where you get the cert from, if you dont add it to the local store, it is going to prompt for a warning. the only worry i would have is if the users couldn’t connect, but obviously they have been able to for all this time so i dont think it will really matter.

17

So this is a guest network, simply using AD to authenticate?

If so I dont see why the certificate is needed, plus you would have to install it on the clients device if you wanted to validate it, so I’d look at only authentication and negate the certificate here, especially for BYOD devices.

Certificate based setups are for in-house domain joined machines to access the main network and resources, not student/BYOD/Guest devices

1 Spice up
18

i am guessing they want a level of authentication for the network, just a user name and password to validate who they are rather than having an open network or a PSK

19

I get that, but that does not require a certificate, besides they’d need to install it on the client devices, which is why for BYOD devices, this is not a good idea.

For the main corporate side or the network, I agree it should be used, but not on unmanaged networks like BYOD/Guest etc.

AD authentication or portal registration should be enough.

FYI all portal based networks are open (to connect to the portal page in the first place), but to go anywhere online, a password, email, SMS or code of some type is needed.

1 Spice up
20

@rod-it ​ you say to use AD authentication, a certificate is not required? I was under the impression that you couldn’t get one without the other. What authentication method is this so I can look into it? That would probably be the ideal solution.