account pkey:sign fails with random number generator:SSLEAY_RAND_BYTES:PRNG not seeded

[lastmikoi]

Hi !

I'm encountering the following error while trying to use lua-acme on haproxy 2.2.17 (IUS repo) on CentOS 7, with OpenSSL 1.0.2k-fips and lua-ossl rel-20200709, when trying to generate a certificate using an existing account key:

haproxy[2303]: [ALERT] 265/092455 (2305) : Lua applet http '<lua.acme>': runtime error: pkey:sign: md_rand.c:530:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded from [C]: in method 'sign', /etc/haproxy/acme.lua:316: in method 'jws', /etc/haproxy/acme.lua:138: in method 'post', /etc/haproxy/acme.lua:326: in method 'register', /etc/haproxy/acme.lua:376: in local 'handler', /etc/haproxy/acme.lua:553: in function line 547.

The issue did not appear when using haproxy 2.2.10, and I've confirmed that haproxy 2.2.16 has the same issue as 2.2.17. I couldn't narrow it down more however.

[anezirovic]

Hello,

Thanks for the report, that's a good start. I'll try to reproduce it and then bisect it, and hopefully it will reveal itself.

[lastmikoi]

Hello,

I've been setting up a new deployment of haproxy-lua-acme on RockyLinux 8, I've come across that issue once again. This time on haproxy 1.18.27 (rhel maintained), with OpenSSL 1.1.1k FIPS and lua-ossl-20200709.

Sadly, in this case, I don't think I have a version to roll back to, like I could in CentOS 7, so I'll have to find a fix.

If you have insight into that issue I'll take it, but if I managed to hack my way into a fix I'll make sure to post about it here

[lastmikoi]

Alright I figured it would take me a while, but it turns out it was a pretty simple fix, at least on that new RockyLinux 8 deployment.

I had haproxy running in a chroot, but I didn't create a random source device, so any random number generation would fail as there was no source.

After doing, mknod /var/lib/haproxy/dev/urandom c 1 9, lua-ossl would be able to find a random source and it works flawlessly.

I can't verify that this fix also applies on the original deployment that I used when I created that issue, but I honestly believe that issue is solved.