Very Computer

Hi all,

I'm trying to build Apache-SSL from source.  I've compiled and
installed OpenSSL 0.9.5a successfully.  I've also managed to
compile and install Apache 1.3.9 with Ben's SSL 1.37.  Now I'm
trying to make a certificate like this:

        /space2/build/apache_1.3.9/src

Trouble is, I get these errors:

        /opt/local/bin/openssl req -config ../SSLconf/conf/ssleay.cnf \
        -new -x509 -nodes -out ../SSLconf/conf/httpsd.pem \
        -keyout ../SSLconf/conf/httpsd.pem; \
        ln -sf httpsd.pem ../SSLconf/conf/`/opt/local/bin/openssl \
        x509 -noout -hash < ../SSLconf/conf/httpsd.pem`.0
        Using configuration from ../SSLconf/conf/ssleay.cnf
        unable to load 'random state'
        This means that the random number generator has not been seeded
        with much random data.
        Generating a 1024 bit RSA private key
        12629:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:md_rand.c:538:
        12629:error:04069003:rsa routines:RSA_generate_key:BN lib:rsa_gen.c:182:
        *** Error code 1
        make: Fatal error: Command failed for target `certificate'

Truss shows that the openssl command can't find one of two
files which look like they're to do with random key generation:

        12635:  stat("/home/richteer/.rnd", 0xFFBEE388)         Err#2 ENOENT

and

        12635:  open("/dev/urandom", O_RDONLY)                  Err#2 ENOENT

Needless to say, I don't have either of these files!

Does anyone know where I can get (or how I can build) these
files?  I'm using Solaris 7 MU 4 plus recent patches & Apache 1.3.9
on a Sun Ultra 5.  As I'll soon be doing the same thing with Apache
1.3.12 (using the corresponding version of Apache-SSL), something
that works with both releases would be appreciated!

I've tried looking at the OpenSSL.org site, the Solaris FAQ, and
the Apache-SSL web site too, all to no avail.  Any help or pointers
greatfully received!

Many TIA,

--
Rich Teer

NT tries to do almost everything UNIX does, but fails - miserably.

The use of Windoze cripples the mind; its use should, therefore, be
regarded as a criminal offence.  (With apologies to Edsger W. Dijkstra)

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

seeded:md_rand.c:538:

Quote:> 12629:error:04069003:rsa routines:RSA_generate_key:BN lib:rsa_gen.c:182:
> *** Error code 1
> make: Fatal error: Command failed for target `certificate'

>Truss shows that the openssl command can't find one of two
>files which look like they're to do with random key generation:

> 12635:  stat("/home/richteer/.rnd", 0xFFBEE388)         Err#2 ENOENT

>and

> 12635:  open("/dev/urandom", O_RDONLY)                  Err#2 ENOENT

>Needless to say, I don't have either of these files!

>Does anyone know where I can get (or how I can build) these
>files?  I'm using Solaris 7 MU 4 plus recent patches & Apache 1.3.9
>on a Sun Ultra 5.  As I'll soon be doing the same thing with Apache
>1.3.12 (using the corresponding version of Apache-SSL), something
>that works with both releases would be appreciated!

>I've tried looking at the OpenSSL.org site, the Solaris FAQ, and
>the Apache-SSL web site too, all to no avail.  Any help or pointers
>greatfully received!

My experience is that Apache/mod_ssl works better.
See http://www.modssl.org/

Quote:>Hi all,

>I'm trying to build Apache-SSL from source.  I've compiled and
>installed OpenSSL 0.9.5a successfully.  I've also managed to

No you haven't.  OpenSSL is strict about your box having a decent
source of entropy, but it enforces it at run-time ;^).

Quote:

>I've tried looking at the OpenSSL.org site, the Solaris FAQ, and
>the Apache-SSL web site too, all to no avail.  Any help or pointers
>greatfully received!

See http://www.openssl.org/support/faq.html#6

Chris

Phew!  I've finally got it working!

Quote:> >I've tried looking at the OpenSSL.org site, the Solaris FAQ, and
> >the Apache-SSL web site too, all to no avail.  Any help or pointers
> >greatfully received!

> See http://www.openssl.org/support/faq.html#6

I saw that egd.pl stuff.  In the end, I didn't need it (so far,
anyway...).  I just created a /root/.rnd file, which contains 4K
of random nonsense. I told openssl to use that file, and all was
well!

Pointing SSLRandomFile in httpsd.conf at the same file also works.
Well, for 1.3.9-SSL 1.3.7 any way.  I'm going to try the latest
versions a bit later to see if they're similarly happy.

Having said that, on a very quick test, I see that the latest
Apache-SSL seems to require egd...

--
Rich Teer

NT tries to do almost everything UNIX does, but fails - miserably.

The use of Windoze cripples the mind; its use should, therefore, be
regarded as a criminal offence.  (With apologies to Edsger W. Dijkstra)

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

Beside egd.pl, have a look at ANDIrand, a /dev/random for Solaris
http://www.cosy.sbg.ac.at/~andi/
Works well with openssl and openssh.
John

Quote:>> See http://www.openssl.org/support/faq.html#6

>I saw that egd.pl stuff.  In the end, I didn't need it (so far,
>anyway...).  I just created a /root/.rnd file, which contains 4K
>of random nonsense. I told openssl to use that file, and all was
>well!

But, the contents of that file need to change.  If they do not,
then the effective entropy is 0.  Getting egd.pl to work
is rather simple.  I would urge you to at least do that much,
because using a static file for "entropy" is useless.

Quote:>Having said that, on a very quick test, I see that the latest
>Apache-SSL seems to require egd...

I would expect it to require a file from which it can read pseudo-
random data.  Whether those data come from egd.pl or anything else
is not the application's concern.

What I did under Sol 2.6 was:

Install product SUNWski from patch 105701-01.  This is more than
needed (all we want is the cryptorand binary and /dev/random) so I
manually rm:

/etc/init.d/skiserv
/usr/bin/certreq
/usr/bin/keypkg
/usr/bin/skicert
/usr/bin/skidecrypt
/usr/bin/skiencrypt
/usr/bin/skilogin
/usr/bin/skilogout
/usr/bin/skisign
/usr/bin/skistore
/usr/bin/skiverify
/usr/include/security/ossship.h
/usr/include/security/ski.h
/usr/include/security/ski_asn.h
/usr/lib/security/skiserv

Whether cryptorand is a better source of entropy than egd.pl I cannot
say.  However, I believe my usage of cryptorand is supported by Sun,
and also doesn't make me have PERL on the box in question -- which I
deliberately made as feature-deprived as possible.  Your requirements
may be different.  

Chris

Quote:> But, the contents of that file need to change.  If they do not,
> then the effective entropy is 0.  Getting egd.pl to work
> is rather simple.  I would urge you to at least do that much,
> because using a static file for "entropy" is useless.

I understand what you're saying, but I don't understand WHY.
Would you mind explaining a bit?

Quote:> Install product SUNWski from patch 105701-01.  This is more than
> needed (all we want is the cryptorand binary and /dev/random) so I
> manually rm:

Yes, that was someting I considered - but I'm using Solaris 7.  I don't
know if it'll work there.  On to Sunsolve, I guess!

Quote:> Whether cryptorand is a better source of entropy than egd.pl I cannot
> say.  However, I believe my usage of cryptorand is supported by Sun,
> and also doesn't make me have PERL on the box in question -- which I
> deliberately made as feature-deprived as possible.  Your requirements
> may be different.  

I agree with the principle of least-features - but the machine in question
will become a web server with PERL CGI stuff.  Having said that, a solution
that avoids PERL is better in my eyes for the reasons you state.

--
Rich Teer

NT tries to do almost everything UNIX does, but fails - miserably.

The use of Windoze cripples the mind; its use should, therefore, be
regarded as a criminal offence.  (With apologies to Edsger W. Dijkstra)

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

Well, I am no cryptographer (to make the understatement of
the century), but your machine's PRNG uses it's entropy pool
as a source of unpredictable bits, which it then uses to create
cryptographic keys.  The vulnerability of those keys to brute-force
attack depends on their effective key length, which is (colloquially
speaking) a function of the amount of entropy "in them".  Since
you are using a source of entropy which is minimal, your effective
key length is correspondingly diminished, and thus more susceptible
to brute force attack.

This general issue is described pretty well in an oldie but goodie
by Wietse Venema -- see http://www.fish.com/security/murphy.html

Chris