I recently discovered a problem on one of our machines running acmebot.
Heres a little rundown and a possible solution to it:
Upon every execution of the acmebot new Diffie-Hellman parameters are being generated.
Even tough the parameters are being generated with the correct length, the acmebot is not recognizing them as such and therefor is trying to re-generate them every time it is run.
Diffie-Hellman parameters for host.example.com are not 2048 bits Generating Diffie-Hellman parameters for host.example.com
I already went ahead and started nailing down the source of the issue.
It appears as if the method "dhparam_size" is not correctly parsing the output of the subprocess.
I investigated a little more and discovered that this is only happening on one of our production machines running Debian Jessie. A similar machine running Gentoo Linux was working perfectly.
After that i went ahead and ran the openssl command by hand and compared it to the regex trying to match the generated length.
Heres the output of the two systems for the same openssl command:
Hi there,
I recently discovered a problem on one of our machines running acmebot. Heres a little rundown and a possible solution to it:
Upon every execution of the acmebot new Diffie-Hellman parameters are being generated.
Even tough the parameters are being generated with the correct length, the acmebot is not recognizing them as such and therefor is trying to re-generate them every time it is run.
Diffie-Hellman parameters for host.example.com are not 2048 bits
Generating Diffie-Hellman parameters for host.example.com
I already went ahead and started nailing down the source of the issue. It appears as if the method "dhparam_size" is not correctly parsing the output of the subprocess.
I investigated a little more and discovered that this is only happening on one of our production machines running Debian Jessie. A similar machine running Gentoo Linux was working perfectly.
After that i went ahead and ran the openssl command by hand and compared it to the regex trying to match the generated length.
Heres the output of the two systems for the same openssl command:
Debian (Jessie) - OpenSSL 1.0.1t 3 May 2016
Gentoo Linux - OpenSSL 1.0.2k 26 Jan 2017
The code trying to parse it would thus need to be modified like this for it to work: (line 1187)
Currently:
match = re.match(r'\s*DH Parameters: (([0-9]+) bit)\n', output.decode('ascii'))
Modified:
match = re.search(r'\s*DH Parameters: (([0-9]+) bit)\n', output.decode('ascii'))
The search would make sure to also capture the "DH Parameters" if they happen to be somewhere in the middle of the output.
Lets hope we can resolve this issue soon! :)