Kozea
SSL Certificate Symlinks
Hi
I use letsencrypt to generate SSL certs for my websites. It uses symlinks to point to the most current SSL certificates as they're updated on a regular basis.
Radicale doesn't seem to want to follow the symlinks regardless of permissions/owner (the symlinks and it's parents are 777).
I'm using Radicale 2.1.10
Can anyone else replicate this?
I've just tried putting the resolved file path in the config but still getting "[Errno 13] Permission denied: '/etc/letsencrypt/archive/mydomain/fullchain.pem'.
It appears to be permissions related on first glance but the path to the file has read permission. Not sure if my radicale user is chrooted?
I've tried changing line 203 in main.py to: filename = os.readlink(getattr(server_class, name)) but it doesn't fully resolve the chain of symlinks that LetsEncrypt uses.
I might have to just have a cron script, that runs after certbot updates the certificates, that overwrites the certificates in /etc/radicale/ssl/?
This is my solution for prosody which should work after substituting file and path variables:
vi /root/certbot.sh
#!/bin/bash
LOGFILE='/var/log/messages'
echo $(date +%d.%m.%Y-%H:%Mh) >> $LOGFILE
certbot renew -a nginx --renew-hook '/root/letsencrypt-to-prosody.sh' >> $LOGFILE
vi /root/letsencrypt-to-prosody.sh
#!/bin/bash
LETSENCRYPT_DIR="/etc/letsencrypt/live/mydomain/"
CERT_DIR="/etc/jabber/certs/"
cp $LETSENCRYPT_DIR'fullchain.pem' $LETSENCRYPT_DIR'privkey.pem' $CERT_DIR
/etc/init.d/prosody reload
echo "certs successfully updatetd" | mail -s "Let's Encrypt" [email protected]
crontab -e
0 0 * * 0 /bin/bash -l -c "/root/certbot.sh"
Yeah - that's a more elegant solution than I currently use which involves running the command to copy the ssl's directly from within cron with no logging.
Would be good if python could follow "chained" symlinks properly tho ;)
I ran into this problem as well, and I would suggest replacing open(filename, "r").close() with open(os.path.realpath(filename), "r").close() in radicale/server.py.
I ran into this problem as well, and I would suggest replacing
open(filename, "r").close()withopen(os.path.realpath(filename), "r").close()in radicale/server.py.
That wouldn't solve the issue, because of the restrictive ownership and permissions of the symlink's target. So, install a deploy hook like @tberger2's or use ACLs.
On the long run, I suggest to enhance radicale with some privilege-dropping mechanism so that it can deal with any system-level permissions at start-up.
