Solving the SSL problem in CVS head
I had an idea on the way home last night. It's now implemented, and it's pretty cool. In eap.conf, the tls, ttls, and peap sections are now enabled in the default install. The EAP module ignores them if OpenSSL wasn't found during the build. The tls module now has a configuration entry "make_cert_command". raddb/certs/bootstrap is a shell script that runs "make". On initial boot in debugging mode after "make install", the server loads the tls module (if OpenSSL was found). The TLS module sees that there's a "make_cert_command", and it's in debugging mode, and no server certificate exists. It then runs the "make_cert_command" to create the certificates, and continues with its normal startup. This means that all of the annoying fighting with stupid certificates to get EAP-TLS to work is *gone*. Just install OpenSSL, install the server, and start the server. EAP-TLS, TTLS, and PEAP will Just Work. This makes me happy. It should make the server MUCH easier to deploy. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi,
This means that all of the annoying fighting with stupid certificates to get EAP-TLS to work is *gone*. Just install OpenSSL, install the server, and start the server. EAP-TLS, TTLS, and PEAP will Just Work.
This makes me happy. It should make the server MUCH easier to deploy.
it does sound funky but how does this interact with systems that already have signed certs etc etc installed/configured - eg doing a new install over older software? alan
A.L.M.Buxey@lboro.ac.uk wrote:
it does sound funky but how does this interact with systems that already have signed certs etc etc installed/configured - eg doing a new install over older software?
Two answers: 1) Very well, thank you. :) 2) raddb/certs/README Like everything else in "make install", it does *not* touch your existing configuration. Programmers that write code to blow away your existing configuration when installing a new version are *bad* people. They are *very* bad people, and I don't like them at all. If /etc/raddb/certs exists, the "make install" process doesn't touch it. Any existing eap.conf is likewise *not* touched on "make install". The default for "make_cert_command" is NULL, which means "don't run it.". Even if you did set "make_cert_command", when the server starts, it would notice that /etc/raddb/certs/<server-cert> exists, so it won't do anything on existing installations. And even if the server certificate didn't exist, it would see that /etc/raddb/certs/bootstrap doesn't exist, so it wouldn't try to run it. In the end, this code has *zero* effect on existing installations. It has *beautiful* effects on brand-new installations. And outside of a few entries in a "Makefile", the change is about 30 lines of code... most of which is sanity checking to ensure it doesn't over-write existing installations, or run at the wrong time. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Wed 25 Apr 2007, Alan DeKok wrote:
I had an idea on the way home last night. It's now implemented, and it's pretty cool.
In eap.conf, the tls, ttls, and peap sections are now enabled in the default install.
The EAP module ignores them if OpenSSL wasn't found during the build.
The tls module now has a configuration entry "make_cert_command".
raddb/certs/bootstrap is a shell script that runs "make".
On initial boot in debugging mode after "make install", the server loads the tls module (if OpenSSL was found). The TLS module sees that there's a "make_cert_command", and it's in debugging mode, and no server certificate exists.
It then runs the "make_cert_command" to create the certificates, and continues with its normal startup.
This means that all of the annoying fighting with stupid certificates to get EAP-TLS to work is *gone*. Just install OpenSSL, install the server, and start the server. EAP-TLS, TTLS, and PEAP will Just Work.
This makes me happy. It should make the server MUCH easier to deploy.
This is all cool, except my rpms no longer work by default :-D A new install on a clean server of last night's snapshot rpm gives the following on first start: Tue May 8 14:31:08 2007 : Info: FreeRADIUS Version 2.0.0-pre0, for host i686-pc-linux-gnu, built on May 8 2007 at 11:17:58 Tue May 8 14:31:08 2007 : Info: Starting - reading configuration files ... Tue May 8 14:31:08 2007 : Info: rlm_exec: wait=yes but no output defined. Did you mean output=none? Tue May 8 14:31:08 2007 : Info: rlm_eap_tls: Loading the certificate file as a chain Tue May 8 14:31:08 2007 : Error: rlm_eap: SSL error error:0200100D:system library:fopen:Permission denied Tue May 8 14:31:08 2007 : Error: rlm_eap_tls: Error reading certificate file /etc/raddb/certs/server.pem Tue May 8 14:31:08 2007 : Error: rlm_eap: Failed to initialize type tls Tue May 8 14:31:08 2007 : Error: radiusd.conf[10]: eap: Module instantiation failed. Tue May 8 14:31:08 2007 : Error: radiusd.conf[2129] Failed to find module "eap". Tue May 8 14:31:08 2007 : Error: radiusd.conf[2076] Failed to parse authenticate section. Tue May 8 14:31:08 2007 : Error: Errors setting up modules Note that radiusd does not have permission to write to /etc/raddb with the default install of my rpms, and in my opinion should not need to have permission: # ls -la /etc/raddb/certs total 33 drw-r----- 2 root radiusd 248 2007-05-08 14:28 . drwxr-xr-x 4 root root 816 2007-05-08 14:28 .. -rw-r----- 1 root radiusd 297 2007-05-08 11:18 bootstrap -rw-r----- 1 root radiusd 1155 2007-05-08 11:18 ca.cnf -rw-r----- 1 root radiusd 1109 2007-05-08 11:18 client.cnf -rw-r----- 1 root radiusd 4181 2007-05-08 11:18 Makefile -rw-r----- 1 root radiusd 4063 2007-05-08 11:18 README -rw-r----- 1 root radiusd 1123 2007-05-08 11:18 server.cnf -rw-r----- 1 root radiusd 514 2007-05-08 11:18 xpextensions Should I run "raddb/certs/bootstrap" during rpm build? On initial install? -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
This is all cool, except my rpms no longer work by default :-D
A new install on a clean server of last night's snapshot rpm gives the following on first start:
OK. The server isn't running in debugging mode, so it expects to read the certificate file. If it isn't there, it complains. Of course, SSL's version of "file not found" is "permission denied" <sigh>.
Note that radiusd does not have permission to write to /etc/raddb with the default install of my rpms, and in my opinion should not need to have permission:
Exactly. The bootstrap is run ONLY in debugging mode, and should probably be done only if run as root.
Should I run "raddb/certs/bootstrap" during rpm build? On initial install?
When the RPM is installed. It will create per-host certificates. This should be safe, because no client will have the certificates installed. They won't trust the server if it presents them a newly created (and unknown) certificate. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Should I run "raddb/certs/bootstrap" during rpm build? On initial install?
When the RPM is installed. It will create per-host certificates.
In fact, if there's an "openssl" command, the "bootstrap" script should be run on "make install". I'll see if I can fix the Makefiles tomorrow. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Garber, Neal -
Peter Nixon