freeradius2-2.1.12-2.el5 is now built into Brew, the errata files have been updated. Will reassign the errata back to QE as soon as the rpmdiff results are waived.

O.K. there are multiple things going on here, some interrelated. Let's
take it one at a time:

1) /etc/raddb/certs/Makefile creates the random file
   /etc/raddb/certs/random, it has 0640 permissions.  If bootstrap is
   run directly by root it's ownership is root:root, if bootstrap is
   run by radiusd -X it's ownership is root:radiusd (because that's
   the effective uid:gid of radiusd during it's configuration)

2) openssl's command line tools use a random file defined by the
   environment variable $RANDFILE. if $RANDFILE is not defined it
   defaults to $HOME/.rnd. $RANDFILE is often re-written by the
   openssl command line tools, when it is re-written it's permissions
   are forced to 0600.

3) /etc/raddb/certs/Makefile does not set $RANDFILE, thus openssl does
   not use /etc/raddb/certs/random, rather it uses $HOME/.rnd which
   because the uid is root is /root/.rnd. Also this means the file
   /etc/raddb/certs/random is never used nor modified during cert
   generation. 

4) When radiusd starts up it needs to read /etc/raddb/certs/random
   because it configures openssl to use that file as it's random
   file. Because that file is not modified in item #3 and retains it's
   0640 permissions there are no initialization problems.

5) If the Makefile is modfied to the problem defined in item #2 by
   exporting the environment variable
   $RANDFILE=/etc/raddb/certs/random then the openssl command line
   tools will rewrite the file with permissions 0600. This causes
   radiusd to fail it's initialization because it's running as
   root:radiusd and cannot read the random file.

6) We DO NOT want to write any file in $HOME, therefore we must set
   $RANDFILE. Also since the openssl command line tools will generate
   $RANDFILE there is no point in having the Makefile generate it,
   that should be removed. After the Makefile is run it must reset the
   permissions of $RANDFILE to 0640 so radiusd can read it.

7) The cert boostrap program is run by the function
   radius_exec_program() (in the file
   src/main/exec.c:74). radius_exec_program() has a hardcoded time
   limit of 10 seconds for child processes. If the 10 second of
   elapsed time is exceeded it attempts to kill the child process.

   Testing the bootstap progam on an i386 virtual machine shows it's
   execution duration varies widely, between 5 seconds and 30 seconds.

   In fact the openssl dh parameter generation explictily warns:
   "This is going to take a long time". Thus it should be expected the
   bootstrap cert generation could easily exceed 10 seconds of elapsed
   time.

   Thus even when all the issues mentioned above are corrected the
   bootstrap cert generation will sometimes fail and sometimes succeed
   depending on whether it exceeded the 10 second timeout. This
   clearly is not acceptable!

In Fedora and RHEL6 we moved the bootstrap cert generation to the RPM
install, thus the bootstrap certs were generated the first time the
RPM was generated, running radius -X did not run the cert
bootstrap. This is preferable for a variety of reasons:

a) You shouldn't need to run the server in debug mode (e.g. radiusd -X)
   to get it configured to run the first time, this is clumsy and
   confusing to users. The only reason it might not be confusing to
   users is the "bootstrap during first debug" behaviour is discussed
   widely on the FreeRADIUS mailing lists.

b) It doesn't suffer the permission problems with the random file. But
   that's just a fortunate artifact. We should fix those irrespective.

c) The duration of the bootstrap command is irrelevant when run by the
   RPM install, it will not be terminated if it exceeds the hardcoded
   10 second timeout.

The RHEL5 version of freeradius2 was packaged prior to moving the cert
bootstrap to RPM install as is currently done in Fedora and
RHEL6. Therefore during this rebase we maintained the RHEL5 behavior
of running cert bootstrap under radiusd -X (debug) so that it would be
consistent with previous RHEL5 freeradius2 package. If all it took to
fix the problems we're seeing in RHEL5 was to fix the $RANDFILE issues
we could just do that, but we're also faced with the timeout
problem. I don't want to increase the child process timeout from 10
seconds to a minute to accommodate just the one time cert bootstrap
because the timeout applies to all child processes run by the
server. Therefore I suggest in RHEL5 we fix the $RANDFILE issues and
move the cert bootstrap generation to RPM install as it is currently
done in Fedora and RHEL6. This will be a RHEL5 change but one most
users will never notice. If there certs are already generated this
will never kick in during an upgrade (and they should replace these
temporary certs anyway) and if they're installing installing for the
first time they'll only see the new behavior.

I forgot to explain that the reason why you got the
"unable to write 'random state'" error was because
openssl was trying to write the random file in /root/.rnd.
When you run the Makefile or bootstrap by hand as root:root it's
not a problem because you have permission to write into
root's home directory, but when those commands are run from
radiusd it fails because radiusd during it's start-up configuration
runs as root:radiusd.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0196.html