Server certificate and clients (eap-tls) certificate
Do I understand the following correctly? I should get valid ssl certificate from (Verisign or other CA) and use it in `certificate_file` and `private_key_file`. This is tells radius server clients, what server is valid. Also this will be enough to enable eap-ttls. The `ca_file` options should point to my self-generated/self-signed CA certificate. And eap-tls clients certificate should be signed by this CA. --- Also I have question not related to freeradius server, but maybe someone have an answer. I can generate client certificate for eap-tls auth method with very long lifetime, like 10 years, and provision clients devices with it only once. But if certificates have short lifetime, I will have to update it periodically. How to do it with minimal user interaction? -- Vladimir
On Dec 9, 2017, at 12:36 PM, work vlpl <thework.vlpl@gmail.com> wrote:
I should get valid ssl certificate from (Verisign or other CA)
Please don't. It's generally a bad idea. Use a self-signed CA. That way you can control it much better.
and use it in `certificate_file` and `private_key_file`. This is tells radius server clients, what server is valid. Also this will be enough to enable eap-ttls.
That's what the documentation says to do...
The `ca_file` options should point to my self-generated/self-signed CA certificate. And eap-tls clients certificate should be signed by this CA.
Yes.
--- Also I have question not related to freeradius server, but maybe someone have an answer. I can generate client certificate for eap-tls auth method with very long lifetime, like 10 years, and provision clients devices with it only once. But if certificates have short lifetime, I will have to update it periodically. How to do it with minimal user interaction?
Magic. :( Most OS vendors make it hard to push EAP configs to end-user machines. This may help: http:802.1x-config.org Or, there are commercial providers who charge for the same services. Alan DeKok.
On 12 December 2017 at 03:12, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 9, 2017, at 12:36 PM, work vlpl <thework.vlpl@gmail.com> wrote:
I should get valid ssl certificate from (Verisign or other CA)
Please don't. It's generally a bad idea. Use a self-signed CA. That way you can control it much better.
Why using valid certificate from some global CA is bad idea? Because Windows requires certain OIDs in the certificates? -- Vladimir
On 12/12/2017, at 3:23 PM, work vlpl <thework.vlpl@gmail.com> wrote:
On 12 December 2017 at 03:12, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 9, 2017, at 12:36 PM, work vlpl <thework.vlpl@gmail.com> wrote:
I should get valid ssl certificate from (Verisign or other CA)
Please don't. It's generally a bad idea. Use a self-signed CA. That way you can control it much better.
Why using valid certificate from some global CA is bad idea? Because Windows requires certain OIDs in the certificates?
https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/certs/READ... <https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/certs/README> Line 26 onwards: In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organisations in the "ca_file", you permit them to masquerade as you, to authenticate your users, and to issue client certificates for EAP-TLS. -- Nathan Ward
On 12 December 2017 at 08:36, Nathan Ward <lists+freeradius@daork.net> wrote:
https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/certs/READ... <https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/certs/README>
Line 26 onwards: In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organisations in the "ca_file", you permit them to masquerade as you, to authenticate your users, and to issue client certificates for EAP-TLS.
Yes, I am aware of it, and I set `ca_file` variable to point my self-generated/self-signed CA certificate. I am asking about `certificate_file` and `private_key_file` variables which represent radius server, and documentation says not to use global know CA only for `ca_file` variable.
On 12/12/2017, at 4:26 PM, work vlpl <thework.vlpl@gmail.com> wrote:
On 12 December 2017 at 08:36, Nathan Ward <lists+freeradius@daork.net> wrote:
https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/certs/READ... <https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/certs/README>
Line 26 onwards: In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organisations in the "ca_file", you permit them to masquerade as you, to authenticate your users, and to issue client certificates for EAP-TLS.
Yes, I am aware of it, and I set `ca_file` variable to point my self-generated/self-signed CA certificate. I am asking about `certificate_file` and `private_key_file` variables which represent radius server, and documentation says not to use global know CA only for `ca_file` variable.
I have not tried using a certificate_file that is not trusted by the CA in ca_file, perhaps it doesn’t relate. The documentation seems to indicate that the ca_file is presented along with certificate_file, but, I am not certain, as that is in the radsec stuff not EAP. However: - If you use a 3rd party CA for ca_file, they can create fake users (and could be expensive unless you buy a certificate which can sign certificates..) - If you use a 3rd party CA signed cert for certificate_file, they can create a certificate that impersonates your RADIUS server, and set up fake APs/whatever. This is the main concern. -- Nathan Ward
On Dec 11, 2017, at 10:43 PM, Nathan Ward <lists+freeradius@daork.net> wrote:
I have not tried using a certificate_file that is not trusted by the CA in ca_file, perhaps it doesn’t relate. The documentation seems to indicate that the ca_file is presented along with certificate_file, but, I am not certain, as that is in the radsec stuff not EAP.
The server certificate has to be signed by a CA in the ca_file. For EAP-TLS, the entire certificate chain is presented to the other end.
However: - If you use a 3rd party CA for ca_file, they can create fake users (and could be expensive unless you buy a certificate which can sign certificates..) - If you use a 3rd party CA signed cert for certificate_file, they can create a certificate that impersonates your RADIUS server, and set up fake APs/whatever. This is the main concern.
Most modern OSes use "certificate pinning". Which means that they cache the server certificate on first authentication, and then allow only that certificate. Which mitigates the concern, but doesn't remove it entirely. The recommendations for self-signed CAs still stand. Alan DeKok.
________________________________ From: work vlpl <thework.vlpl@gmail.com>
But if certificates have short lifetime, I will have to update it periodically. How to do it with minimal user interaction?
I haven't tried it myself, but if the clients are Windows you might find this useful: https://sourceforge.net/projects/su1x/ In a domain you can use group policy.
participants (4)
-
Alan DeKok -
Nathan Ward -
Vieri -
work vlpl