> From: [EMAIL PROTECTED] On Behalf Of Kyle Hamilton > Sent: Friday, 09 May, 2008 07:22 > To: openssl-users@openssl.org > Subject: Re: Unable to Generate a CSR > > > This appears to be a case of your configuration file being truncated, > or your environment otherwise slightly messed up. > > The main error is, of course, the "PRNG not seeded" error -- as it > says, you need to read the OpenSSL FAQ for information on how to solve > it. (It goes into much tried-and-true detail. :)) <snip parts about other config issue> > The RSA_setup_blinding error is triggered by the PRNG not seeded > error, and that triggers the RSA_EAY_PRIVATE_ENCRYPT internal error. > Then, because the private-key encryption fails, the ASN1_item_sign > error fails (because the ASN.1 object isn't generated properly, to be > able to be signed). The practical upshot of this is, the last 4 > errors you're seeing will all be fixed by resolving the "PRNG not > seeded" problem. > Except, unfortunately, apps/req.c at least in 0.9.8g (which I use) and I expect d also doesn't use the documented methods of seeding (RANDFILE and/or -rand) for a -new req on an existing RSA -key.
I ran into this recently myself (see -dev). I patched mine. Other possibilities that I know or believe should work: - generate the key and CSR in a single operation, using -new without -key (with config or -newkey -keyout). This does seed. As I read the OP's message he is already using openssl commandline, presumably 'rsa', to generate the key, so using a different openssl commandline operation should be OK. If you were e.g. generating a key in (custom) hardware and then exporting it to openssl to be certified this wouldn't work. (Plus you would be throwing away some of the security benefit of hardware, which might also be an issue.) - use a different keytype. DSA and EC(DSA) do seed (though only RANDFILE, not -rand) and do work. Obviously this depends on the capabilities of the program(s) in which you want to use the key, and its communication or interchange partner(s). And possibly your security policy. - install and/or permit access to /dev/*random or EGD so it can "autoseed" (unless somehow this got configured out?) - use an -engine that provides random that doesn't need seeding - go back to 0.9.7 (m at least, probably others), where blinding setup was done differently, and works without seeding (though I'm not sure it should!); this only needs to be done for the CSR signing operation, which could be in a protected environment if you're worried about the attacks blinding addresses. > On Wed, May 7, 2008 at 1:57 PM, Nelson, Robert D. > <[EMAIL PROTECTED]> wrote: > > Hi: > > > > I'm running OpenSSL 0.9.8d on an HP-UX 11 box. In the past I've been > > able to generate CSRs and keys via the command line with no trouble. > > However, today I generated a key just fine, but when I tried to generate > > the CSR it failed. I'm not aware of anything having been changed since > > the last CSR I generated (July 2007), but I'm not the administrator of > > this box so I wouldn't be privy to all changes. <snip rest> If 0.9.8d (and not 0.9.7-something) was in fact in use at the previous time, the only environmental change I would expect to affect this would concern /dev/*random or EGD, and I think that would more likely go from bad to good than good to bad. But you never know. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
