The default Linux ISPConfig 3.1 install apparently stores all key files as group and world readable, owner root. This is not secure. I understand it's easier to link to the files from different processes and handle LetsEncrypt quickly, but the insecure storage can be fixed with some key update procedures owned by root too, ie if the LetsEncrypt archived site keys are changed, these are then copied to the site ssl directory with proper protection attached, instead of symbolic linked.
SSL key files generated by ISPConfig are not stored group or world-readable, generate one on the SSL tab and then check the content of the SSL directory. Here a SSL cert generated by ISPConfig, as you can see, the permissions are perfectly fine: root@server1:/var/www/test.tld/ssl# ls -la total 24 drwxr-xr-x 2 root root 4096 Aug 4 04:17 . drwxr-xr-x 15 root root 4096 Jun 3 11:33 .. -rw-r--r-- 1 root root 1261 Aug 4 04:17 test.tld.crt -rw-r--r-- 1 root root 1025 Aug 4 04:17 test.tld.csr -r-------- 1 root root 1675 Aug 4 04:17 test.tld.key -r-------- 1 root root 1743 Aug 4 04:17 test.tld.key.org Certbot (not ISPConfig) stores its key files world-readable and ISPConfig is not involved in that at all. They can do that without compromising security just because they put them into a folder hierarchy which is readable by root user only, so the key files are only readable by root. ls -la /etc/letsencrypt/ total 148 drwxr-xr-x 9 root root 4096 Aug 4 03:08 . drwxr-xr-x 103 root root 4096 Aug 4 14:09 .. drwx------ 6 root root 4096 Feb 1 2019 accounts drwx------ 23 root root 4096 Aug 16 2019 archive drwxr-xr-x 2 root root 53248 Aug 4 03:08 csr drwx------ 2 root root 53248 Aug 4 03:08 keys drwx------ 23 root root 4096 Aug 16 2019 live drwxr-xr-x 2 root root 4096 Jul 2 03:13 renewal drwxr-xr-x 5 root root 4096 Feb 19 2018 renewal-hooks the key files are in subdirectories of the archive folder, the archive folder is only readable by root, so all files and folders inside are only readable by root. So that's all perfectly fine and secure. You can easily test this and prove your own assumptions wrong. Run: sudo -u www-data cat /etc/letsencrypt/archive/yourdomain.com/privkey1.pem the result is: cat: /etc/letsencrypt/archive/yourdomain.com/privkey1.pem: Permission denied Then we do the same test on the symlink: sudo -u www-data cat /var/www/yourdomain.com/ssl/yourdomain.com-le.key the result is: cat: /var/www/yourdomain.com/ssl/yourdomain.com-le.key: Permission denied To sum this up, please don't post such unproven and wrong claims without testing them first and without checking the permissions in the folder hierarchy.
Hi Till. Appreciate the response and I stand corrected: I did not specifically test the site certificate keys for user access when I saw they were world readable; I'm used to properly limit the key files to owner only. I was initially triggered because of the opendkim configuration on my server: /etc# opendkim-testkey -vvv -d mydomain.com -s default opendkim-testkey: using default configfile /etc/opendkim.conf opendkim-testkey: checking key 'default._domainkey.mydomain.com' opendkim-testkey: key not secure opendkim-testkey: key OK /etc# sudo -u opendkim ls -l /usr/share/dns/root.key -rw-r--r-- 1 root root 864 Feb 1 2018 /usr/share/dns/root.key So this is probably the only example then.
As mentioned above, site key generated by ispconfig are not world-readable. What you probably looked at are symlinks, and you can't tell the actual permissions of the resulting file from looking at the permissions of a symlink. Opendkim is not used by ispconfig and should not even be installed on an ISPConfig system. The DNS root key is not from ISPConfig, so you have to contact the Linux Distribution that you use if you want to have it#s permissions changed when the Linux package creates it.
Okay, no problem. It's a clean Ubuntu 18.04 system with only ISPConfig on top, so I guess opendkim was available in the base OS install. I accept the keys ISPconfig stores are secure. One question: what is the reason to not want to make use of opendkim? Is amavis already doing the heavy lifting there?