Remember when you put your Root CA file (and perhaps the CRL for that CA) into your certificate directory, and ran 'c_rehash <cert directory>'?

If you mean when I installed ssl certs for Apache, I never did this. I simply put the server cert and the chain file on the server, then configured mod_ssl with 2 required parameters - CertificateFile and CertificateChainFile. No (re)hashing was required.

Well - it's just like that. You might have had RootCA.pem with the Verisign CA certificate. Personally - I like to have a separate file for each intermediate CA certificate in the chain.

What i've got currently can be up to 3 files. Firstly, the server certificate itself, which has been signed by Verisign's Intermediate CA, then the cert for said Intermediate CA, and finally the root cert used to sign the Intermediate CA. My current setup is with the server cert in a file on it's own (jrs-radius02.pem is the cert, jrs-radius02.key is the keyfile), and the intermediate and root certs in the same file (verisign.pem. Intermediate cert at the top, root cert at the bottom). I then have the following config lines in the tls section of eap.conf for FreeRADIUS to reference these files: private_key_file = ${certdir}/jrs-radius02/jrs-radius02.key certificate_file = ${certdir}/jrs-radius02/jrs-radius02.pem CA_file = ${certdir}/jrs-radius02/verisign.pem

When you think you are done - you can test the validity of your new certificate like this:

openssl verify -crl_check -CApath <certificate path> /path/to/certificate-file/server.pem.cert

I've actually dropped the -crl_check from this test, as i'm not doing crl checking within FreeRADIUS until i've got it working without it. Also, this command didn't seem to work when my verisign.pem contained > 1 cert, even after a c_rehash, it only worked if all the certs were in individual files: jrs-radius02:/etc/freeradius/certs/jrs_radius02# openssl verify -CApath . jrs-radius02.pem jrs-radius02.pem: OK As such, I also tried commenting out CA_file in eap.conf and instead having: CA_path = ${certdir}/jrs-radius02/ With all my certs in individual files, but that gave the same behaviour, i.e. that on my client it shows me the certificate it got passed, for the jrs-radius02 server, but it doesn't have a certificate chain back to a known trusted root.

Hope this helps. Give it a go and let us know if you have any problems.

This still appears to be failing to pass the certificate chain. The root cert *definitely* exists on my test client (I extracted it from there and diffed it with the one on the server). If I install the intermediate cert on the client, then everything works fine (but I don't want to have to try and get my users to understand the process of installing a cert before getting online). However when Windows XP prompts me to accept the certificate FreeRADIUS is handing out it doesn't have any chain listed at all, so I assume is still not being handed that Intermediate cert. Thanks very much for the help so far. Any more would be greatly appreciated. I can attach full config files if you think that would be helpful. Dan

On Fri, Feb 13, 2009 at 12:11 PM, Meyers, Dan <d.meyers@lancaster.ac.uk> wrote:

...

I'm sure I must just be being thick with our FreeRADIUS config, but i've completed failed to find anything online or in the docs explaining *what* i'm doing wrong, so i'm posting here.

We've had a FreeRADIUS server set up for some time now, with an SSL certificate directly signed by one of Verisign's root CA's, for the purposes of doing EAP-TLS domain auth. This worked fine on both FreeRADIUS 1.1.7 and 2.0.5. However our cert is due to expire in a month, and it would appear no one issues root signed certs any more, they're all cert chains. Obviously with things like apache this is fine, as you install the chain bundle file at the same time as your actual cert, and the chain gets passed to the client, who follows it to a root CA they do already trust. I'm having trouble working out how to do this with FreeRADIUS however. All the info I can find suggests that if I edit my certificate file so that it contains multiple certs, from least trusted at the top (my server cert) down the chain and file to the one which has been signed by a root CA the user's machine will already trust, then machines will follow the chain as expected and accept the certificate. However if I do this, and have a chain file of the same format as I use successfully on the web server (i.e. multiple BEGIN and END blocks with a single cert between each pair), then my client machines still fail to pick up the chain, and thus can't validate the certificate.

Am I missing something blindingly obvious with regards to how to do certificate chains in FreeRADIUS? If so, please tell me what.

Thanks

...

I've actually dropped the -crl_check from this test, as i'm not doing crl checking within FreeRADIUS until i've got it working without it. Also, this command didn't seem to work when my verisign.pem contained

1 cert, even after a c_rehash, it only worked if all the certs were in individual files:

jrs-radius02:/etc/freeradius/certs/jrs_radius02# openssl verify - CApath .. jrs-radius02.pem jrs-radius02.pem: OK

What?

openssl verify -CAfile verisign.pem jrs-radius02.pem

isn't working? Then something is wrong with your chain file. Check that you are using the correct root certificate and cat certificates again in a new bundle.

OK, got this bit sorted, which was me being a tool. I was using vim, and hadn't noticed one file was being opened in dos mode and the other in unix. As soon as I catted them together instead of copy-pasting between terminals I saw that the root block was ending lines with ^M. Converted that to unix format, re-catted the two into my ca pem file, and openssl is now happy with a file containing multiple certs and validates the chain. My client is still giving the same behaviour of not getting the certificate chain, however. I did wonder if Windows was being daft, and resaved the ca file so all certs within it were in dos format instead of unix. After another rehash openssl still verified the chain fine, but my client is still not playing ball. Dan

...

My client is still giving the same behaviour of not getting the certificate chain, however.

OK. So which certificate signed the client certificate?

Sorry, i'm still getting to grips with this system after the previous admin of it left. I've adminned FreeRADIUS before, but never done any of the EAP/PEAP/MSCHAP etc user auth with it. On my other system we are using it for client MAC auth via perl modules. I was incorrect about us doing EAP-TLS. We're doing EAP-PEAP, which does not require a client certificate. My understanding however is that for passing of the server certificate to validate our server to the clients the options with the tls subsection of the eap.conf file are still used. Apologies for any wasted time and/or confusion I caused :( Dan

...

I was incorrect about us doing EAP-TLS. We're doing EAP-PEAP, which does not require a client certificate. My understanding however is that for passing of the server certificate to validate our server to the clients the options with the tls subsection of the eap.conf file are still used.

For that you need to export just the intermediate certificate used to sign the server certificate onto the clients. They should have the root one already.

Import intermediate certificate (.der or .crt version) onto a client. Copy server.crt onto the client desktop and see if Windows recongnized the chain.

Yes, if I import just the intermediate certificate to the client, install it, and then try and auth, the chain is picked up correctly (or if I just copy across the server cert and check it). But of course the reason for this is because the intermediate cert is then directly trusted by the client, and the server cert is signed by it. This was my reasoning for thinking that FreeRADIUS was not passing the intermediate cert when the auth attempt was being made. I did originally think it should work without the root cert, because the client already had that, and only installed it as well as the intermediate cert when I failed to get the output I expected just using the intermediate one. Googling suggested that simply catting the 2 certs (server and intermediate) into a single file (server at top, intermediate at bottom) and listing that in the config as the certificate_file should work, but it'd didn't seem to for me (and i've checked the file formats this time). The client got the server cert, but still didn't pick up the chain. Dan

...

Googling suggested that simply catting the 2 certs (server and intermediate) into a single file (server at top, intermediate at bottom) and listing that in the config as the certificate_file should work

No, that's not going to work. Client machine will still look for the intermediate CA in it's store and not in that bundle.

So there is no way at all to get the client to pick up the cert chain without directly installing the intermediate cert on it? Is this actually a client issue of it refusing to use chains for this then, rather than a FreeRADIUS issue of it not passing the chain? Thanks very much for all your help. This only came up because Verisign have stopped issuing directly root-signed certs, as have the other major cert authorities, it would seem. Our previous cert was directly root signed, and thus worked fine. I (possibly foolishly) assumed that if all the major CAs were shifting to chained certs for everything that the majority of clients using ssl supported them as well. Dan

Meyers, Dan wrote:

...

...

I was incorrect about us doing EAP-TLS. We're doing EAP-PEAP, which does not require a client certificate. My understanding however is that for passing of the server certificate to validate our server to the clients the options with the tls subsection of the eap.conf file are still used. For that you need to export just the intermediate certificate used to sign the server certificate onto the clients. They should have the root one already.

Import intermediate certificate (.der or .crt version) onto a client. Copy server.crt onto the client desktop and see if Windows recongnized the chain.

Yes, if I import just the intermediate certificate to the client, install it, and then try and auth, the chain is picked up correctly (or if I just copy across the server cert and check it). But of course the reason for this is because the intermediate cert is then directly trusted by the client, and the server cert is signed by it.

Dan, It's unclear to me exactly: a. what you're expecting to happen b. what is happening We have exactly the same setup - verisign root->intermediate->our cert. What happens with an XP client on our WPA EAP-PEAP network is exactly the same as documented here: http://www.albany.edu/its/windows_detailed_document.pdf ...that is, after clicking all the tedious boxes in XP, once connecting a dialog box pops up as per page 6 of the PDF above. Once clicked, the user is never prompted again. As per my email on the DOT1X list the other day, this is (we believe) a behaviour change from a vanilla windows XP SP2 install i.e. one of the hotfixes changed something. Certainly when we tested a vanilla XP SP2 install against our current cert chain, it worked straight through, but a fully-hotfixed install did not. Is this what you're seeing?

Dan,

It's unclear to me exactly:

a. what you're expecting to happen b. what is happening

We have exactly the same setup - verisign root->intermediate->our cert. What happens with an XP client on our WPA EAP-PEAP network is exactly the same as documented here:

http://www.albany.edu/its/windows_detailed_document.pdf

...that is, after clicking all the tedious boxes in XP, once connecting a dialog box pops up as per page 6 of the PDF above. Once clicked, the user is never prompted again.

Yes, this is the behaviour we are seeing too. The issue is that, with said popup and a directly root-signed cert, you can click on the 'View Server Certificate' button and see that it is trusted to a known root, and Windows says something along the lines of 'This is a trusted certificate'. The reason we shifted to using a Verisign cert instead of a self-signed one with the right bits set was that we were getting a surprisingly large number of users refusing to accept a cert that windows flashed up as 'Untrusted. Warning, this certificate cannot be traced to a known trusted root etc etc' (or whatever the actual text is, I can't recall offhand), and then complaining that they couldn't get on the wireless network. It was easier to get a 'proper' cert from Verisign than it was to try and get all our users to install our local CA on their personal machines. Now that Verisign are using an Intermediate CA the cert we have paid for is no better than a self signed one in this case. The chain does get picked up correctly in Vista, which backs up your point of it being an XP specific issue and nothing to do with FreeRADIUS. I was unfortunately testing on XP only as that is the only Windows I had readily available. If it used to work then God knows why MS decided to break it in a security update, but bring the functionality back in Vista. Unfortunately the majority of our users are still on XP. Thanks all for your help. Dan