I have renamed Default_CA.pem to Default_CA.cer, installed it onto a Win 7 machine, and successfully connecting to the AP & authenticating to the domain via my AD credentials.
However on the Chromebook side of things ... working with the installer, Google engineer & AH engineer we haven't been able to (1) push the Default_CA.pem via OTA (2) neither have we been able to import the Default_CA.pem locally - error message is invalid or corrupt.
In Google Management console if I tell it to ignore the cert, the Chromebook will happily connect to the AP & I can authenticate using my AD credentials. However the ignoring of the cert seems to introduce insecurity.
If I have them check the cert then it's a catch-22 situation because the Chromebook does not have a cert and errors with "Authentication certificate rejected locally."
What are we doing wrong?
Aside from any issues that you are having exporting, converting or importing the self-signed certificate, the needed certificate properties for TLS-based EAP with common 802.1X supplicants are missing from it so you are unlikely to get a good outcome.
While this is probably a bug that should be resolved in a future software release, it is also always better to use proper PKI infrastructure regardless.
With this in mind:
- If you already use your own certificate server internally for other purposes and can issue a certificate from it and decide to do this, bear in mind the following:
Specifically there, "Consideration 2: Recommended certificate properties". These are the requirements that the Aerohive self-signed certificate should meet.
- If you decide to go with a commercial certificate, all of these meet the CA/B forum baseline requirements that are a superset of the requirements that common 802.1X supplicants have. These always work, therefore.
(I recommend the commercial route if you do not already have a certificate server/PKI infrastructure for ease of deployment as it avoids you having to set this up.)
You can convert the public/private key between certificate formats, if you need to, at the OpenSSL command line. This is well documented and Google search is your friend here.
It is recommended that you use the domain name of your organisation and not the RADIUS server's internal name, a private implementation detail, in the certificate that you get issued and use. For example: myschool.com not server01.myschool.com or aerohiveap.myschool.com
You will want a 2048-bit key, SHA-2 (SHA-256) based certificate for EAP purposes on the RADIUS server. (Do not use a certificate with a key that is less than or greater than 2048-bit or that is SHA-1 or MD5 based. It does not matter if the root certificate that the server certificate derives from is SHA-1 or SHA-256 based, but it should be 2048 bit.)
First of all thanx for your input.
Today I kept working with a Google Engineer providing him with debug information from Chromebook.
One reason I wanted to give a little more TLC on the Default_CA.pem from AeroHive was because it works on Windows 7 - plain and simple. I thought there may be something I'm not doing right in the Google Management console that is not sending the cert down to the Chromebook OTA and/or I'm missing something that Chromebook does not want to import even locally off an USB thumb drive.
There is a section in the Google management console where I can assign an 'user based network policy' or a 'device based network policy' for Chromebook devices. I was also told earlier that the user based policy has no bearing current as it is not working.
Just out of pure hunch I decided to ignore that information for the time being. I created policies to use the cert in both. Then I moved the test user into the OU where the policies were applied. This time I could connect to AP & authenticate with my AD credentials from the Chromebook so it must have applied(?) the user policy and made sure I had a GAFE account and then let me authenticate against AD. I guess that was the case because the cert was still not pushed to my test Chromebook but I also was not getting blocked with "Authentication certificate rejected locally" error. I still want to get the cert on the device so it's more device-based like the Win7 laptops with the same cert imported.
So I don't have the answer yet but the Google Engineers are supposedly pouring over the debug logs to see what really is happening.
Finally the other reason of why we're not trying the third party commercial cert route is purely money. As a school we are limited in budget.
I hope I'll have an update soon ... I hope the Google Engineers will call back with good news ;-) Stay tuned!
So this is all new to me. Our installers set it up, the HiveManager tools shows that LDAP is working & returning values, & sure enough I can authenticate with the Win7 laptops through the Ah RADIUS.
Is it just the matter of creating this new cert from the link you provided and somehow changing one parameter to start using this newcert instead of Default_CA.pem from AeroHive?
If it is not too much to ask what may be the steps?
Finally one of the challenges I get whe ntrying to import the cert locally into the Chromebook is "what is the password that was used to encrypt this cert?" to which I have no answer and results in not being able to import. Will a third party cert resolve that ? Actually if at all possible I want the cert to be pushed OTA per Google user or device policy ...
Hi Nick, We are trying this process but a local domain CA issues as the AP's FQDN does not accept as trusted.
We have tried using a Local domain CA to issue a wildcard as well the same issue.
lastly we also paid for a specific public CA cert but our internal domain is a *.*.local so public CA's wont issue a cert and we have tried to use our company *.domain.com
still not working.
If we email the certs to our mobiles or devices we can open them up and see they are trusted certificates.
For some reason the Aerohive still says as untrusted.