• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Problem by creating DHPARAM (not saved)

Dukemaster

Regular Pleskian
Hi at all,
I correctly implemented the creation of new DHPARAM every week.
They are created, which I can see from the changing date/time of the four files (dhparam512.pem....dhparam4096.pem).
But they are empty.
Cron task: command as root in Plesk 17.8 (Ubuntu 18)
Code:
FILE=`mktemp` ; openssl dhparam 512 -out $FILE && mv -f $FILE /etc/dhparam/dhparam512.pem && FILE=`mktemp` ; openssl dhparam 1024 -out $FILE && mv -f $FILE /etc/dhparam/dhparam1024.pem && FILE=`mktemp` ; openssl dhparam 2048 -out $FILE && mv -f $FILE /etc/dhparam/dhparam2048.pem && FILE=`mktemp` ; openssl dhparam 4096 -out $FILE && mv -f $FILE /etc/dhparam/dhparam4096.pem

This question was asked several times here in forum by several users, but never answered why the files are empty or in other way, why the content is not saved in the files and what to do. Perhaps the reason is wrong permissions?
I don't know.

Helpful people like Igor wrote a good instruction, a tutorial how to set this. It's working, with the only problem that the content is not saved in the files.
When I run
Code:
~# /usr/local/sbin/gen_dhparam
they are created and I can copy them from CLI into the files and save it by hand, but this is not the way, not computing.
 
Last edited:
Thanks @IgorG to mention your great help, I just wanted to insert the link in my thread.
The incredible thing is: It was on my old server. March 2018 I changed to a newer server by Ionos with Ubuntu 18.
But on the old server, You are right, it was solved. I never know why, what the issue was.
On new server I make everything like before, but it isn't successful...
 
Sorry I've forgotten something important, perhaps.
The .pem files are created with 0600, not like usual with 0644.
Some procedure every week, I change them handy to 0644.
By the script they always switch again (empty) to 0600.
This is why I thing the reason has to do with permissions, perhaps another change in Plesk or Ubuntu versions?
 
Last edited:
Just try to modify script like

Code:
# cat /etc/cron.weekly/gen_dhparam
#!/bin/bash

mkdir -p /etc/dhparam 2>/dev/null
FILE=`mktemp`

N=512
while [ $N -le 4096 ] ; do
  openssl dhparam $N -out $FILE && cat $FILE >/etc/dhparam/dhparam${N}.pem
  let N*=2
done

chmod 644 /etc/dhparam/dhparam*
rm -f ${FILE}
 
Thanks for help, Igor.
This little thing I just solved by another action five minutes ago.
I reconfigured shell back to dash with "dpkg-reconfigure dash" (Yes)
What a surprise! The before with 0640 handily configured files now only change their time after creation, but not the rights any longer.
I will keep your tipp in mind.

I'm disappointed about myself, so many hours and days tested since last March, thinking about how to solve this problem.
The script alone works in shell and creates the content/encryption. Only the saving won't happen. :(

Could it be, that it has to do with Ubuntu(18) rights and configuration. It's unbelievable.
 
By hours of investigation now I come a little closer to the real root issue.
It must have to do with the whole permission system, perhaps umask.
I wondered why the permissions of /etc/cron.weekly/gen_dhparam are set to 0777 and it's impossible to change to the normal 0755 rights by ~# chmod 755 /etc/cron.weekly/gen_dhparam?
Code:
root@server:~# ll /etc/cron.weekly/gen_dhparam
lrwxrwxrwx 1 root root 27 Jan 21 13:17 /etc/cron.weekly/gen_dhparam -> /usr/local/sbin/gen_dhparam*
Then I deleted this file, and after re-creation it has wrong 0777 again.
But the whole server system with PLESK is working like a charm with no issues.

Please, what can I do to change the set of permissions, perhaps reset them to default?
 
Last edited:
Hi @IgorG and Plesk friends
I found a part of a solution. Not the ultimate one, but very close to it.
By investigation I looked closer to one of the oldest threads dealing with DHPARAM. Mister @Lloyd_mcse tutorial is the key here.
In his posting Lloyd gave the raw command to create the pems. By the execution of his command openssl dhparam -out /etc/dhparam/dhparam.pem 4096 I was able to create a 4096 cert/pem with the correct permissions 644 over CLI today, afterwards I created also the other ones (3).
I only modified his command and used it with generator 2, like usual, not generator 5. Therefor I left the part -5 out. This was the first little test to see if the generator is responsible for the fails during last year.
No empty file like the last months by executing the dhparam-script-command /usr/local/sbin/gen_dhparam.
But why?
Why does the dhparam-script create empty files but in CLI you see always the correct ciphers?
Maybe writing permissions are the reason, when creating the temporary files (`mktemp`)?
Much more interesting and useful would be to put Lloyd's command in the script and modify it.
No matter to execute it manually by hand.

Greets
 
Last edited:
Hi @IgorG and Plesk friends
I found a part of a solution. Not the ultimate one, but very close to it.
By investigation I looked closer to one of the oldest threads dealing with DHPARAM. Mister @Lloyd_mcse tutorial is the key here.
In his posting Lloyd gave the raw command to create the pems. By the execution of his command openssl dhparam -out /etc/dhparam/dhparam.pem 4096

But why?

When the number of bits, in this case 4096, comes after the option where to put the file (-out), openssl seems to output meaningful data. That is the correct way. The script is wrong, because the script puts the option after the numbits, be it 512, 2048 or 4096.

This is wrong:
Code:
openssl dhparam $N -out $FILE && cat $FILE >/etc/dhparam/dhparam${N}.pem

This is correct:
Code:
openssl dhparam -out $FILE $N && cat $FILE >/etc/dhparam/dhparam${N}.pem

If you modify all the examples like shown above, and switch the number with the option, it will work.
 
Hi at all,
I correctly implemented the creation of new DHPARAM every week.
They are created, which I can see from the changing date/time of the four files (dhparam512.pem....dhparam4096.pem).
But they are empty.
Cron task: command as root in Plesk 17.8 (Ubuntu 18)
Code:
FILE=`mktemp` ; openssl dhparam 512 -out $FILE && mv -f $FILE /etc/dhparam/dhparam512.pem && FILE=`mktemp` ; openssl dhparam 1024 -out $FILE && mv -f $FILE /etc/dhparam/dhparam1024.pem && FILE=`mktemp` ; openssl dhparam 2048 -out $FILE && mv -f $FILE /etc/dhparam/dhparam2048.pem && FILE=`mktemp` ; openssl dhparam 4096 -out $FILE && mv -f $FILE /etc/dhparam/dhparam4096.pem

This question was asked several times here in forum by several users, but never answered why the files are empty or in other way, why the content is not saved in the files and what to do. Perhaps the reason is wrong permissions?
I don't know.

Helpful people like Igor wrote a good instruction, a tutorial how to set this. It's working, with the only problem that the content is not saved in the files.
When I run
Code:
~# /usr/local/sbin/gen_dhparam
they are created and I can copy them from CLI into the files and save it by hand, but this is not the way, not computing.

This is incorrect, please fix. The numbits for dhparam must come after the options for the openssl command. You can check the manpage. See this blog entry, for example:

Mailserver – Andre-Toellner.de
 
Thank you very very much @Penguin-IT. This was the correct solution. Don't know why nobody found it out, including myself?
I also correct my support article in 4 languages where the tutorial is published.
:) Thumbs up
 
Back
Top