-
-
Save catchdave/69854624a21ac75194706ec20ca61327 to your computer and use it in GitHub Desktop.
# MOVED to public repo: https://github.com/catchdave/ssl-certs/blob/main/replace_synology_ssl_certs.sh |
Hi,
Is it necessary to reboot all the services? As the script restarts all the services, docker and virtual machines that are running on the synology are affected.
I guess, some of Step 4. "Rebooting all the things..." can be disabled by default ?
I am not sure—this was the easiest method to make sure everything works. Feel free to experiment :)
You definitely need to restart any web servers serving the cert (so nginx at least).
Is it necessary to reboot all the services?
It's not, unless you have a service specifically that seems to need it.
For me, simply running:
/usr/syno/bin/synow3tool --gen-all
/usr/syno/bin/synow3tool --nginx=reload
and /usr/syno/bin/synow3tool --restart-dsm-service
...refreshes certs for DSM and Reverse Proxy setups with no need to bounce apps (like docker, which takes a long time and is disruptive if runnning network services in containers)
I use Caddy Web Server as my reverse proxy running inside Container Manager (Docker) on my Synology DSM. Caddy is also great as a certificate manager.
Inspired by you and your code (all of you here), I wrote my own script synology-cert-deploy.sh which takes only the private key and full certificate chain files as input, since those are the only two TLS files coming from Caddy, and deploys them to Synology DSM. As long as it has the new private key and full chain, it can extract all the remaining files from these two files.
On DSM 7.2-64570 Update 1, the script will update the certificates (as verified by the Certificate tab of the Security applet in the Control Panel), but fail to restart the DSM webserver which runs on port 5001 for me.
Manually issuing the /usr/syno/bin/synow3tool --nginx=reload
command seemed to do the trick, though.
Hi,
I installed this script and when running it everything seems fine.
The certificate in the control panel is updated. But when browsing to the DSM webserver on port 5001 it keeps showing the old certificate.
I already rebooted the device, but keeps showing the old certificate.
What am I missing?
Thanks.
@Daermegil check in the Certificates pane in DSM and see if you have one certificate set up, and make sure it's this one. It is possible to have multiples and assign a different one to DSM.
@telnetdoogie thank you for your quick reply.
I do have 2 certificates, one is my actual certificate. The other one is for quickconnect, but I can't delete that one. I also don't think it is the one causing problems.
But I think I see the problem. The certificate I'm using is RSA, but the old one from synology is RSA/ECC. The webserver is probally using ECC I guess, because the file ECC-cert.pem is still my old certificate. I'm just going to reset the certificates and readd them. But I have reached my request limit so I'll have to wait a bit.
@Daermegil RSA is fine; that's what I'm using too... I did see in my notes that I needed to manually import the LE certificates into DSM before the automation worked reliably.
When you're prompted for Private Key that's the privkey.pem
file. When you're prompted for the Certificate that's cert.pem
. When prompted for the Intermediate Certificate that's fullchain.pem
.
DSM does accept certs without adding the intermediate cert, but it causes some things to fail.
Try manually adding those and see if that works for you. Once the manual add works, the automation should also work.
I think from my memory, if you upload the wrong files (and it'll still appear to work sometimes) in the wrong inputs, it will actually rename things on the filesystem but when the automation works, it's now updating the wrong files. I'm not stating that right but I definitely had some weirdness early on because I wasn't providing the Intermediate cert; instead I was using fullchain.pem
as the Certificate file, which gave me issues with VPN, for example.
@telnetdoogie I added a RSA only certificate and replaced it using the script, everything seems to work brilliantly now!
Thanks for the help!
This appears to miss all "WebStation" pages for me.
I added
# Add WebStation directories
for webstation in /usr/local/etc/certificate/WebStation/*/; do
debug "Found WebStation dir: ${webstation}"
target_cert_dirs+=("${webstation}")
done
But those then weren't re"compiled" into the correct folders nginx uses, so I wrote
# somehow WebStation ends up not getting applied later, so lets manually do it (if it works later it will simply get overwritten)
for ws in /usr/syno/etc/www/certificate/WebStation_*/; do
info "Copying WebStation certificates to '$ws'"
ws_crt=$( grep -o "$ws"cert.conf -Pe '(?<=ssl_certificate\s)\s*.*(?=;$)' | xargs )
ws_key=$( grep -o "$ws"cert.conf -Pe '(?<=ssl_certificate_key\s)\s*.*(?=;$)' | xargs )
ln -f "${certs_src_dir}/"fullchain.pem "$ws_crt"
ln -f "${certs_src_dir}/"privkey.pem "$ws_key"
done
which appears to be sufficient. I still had to add nginx -s reload
to get changes to show up.
Is this really the only way to do this?
In the process I grepped through my /usr
and also saw my cert ended up in /usr/local/etc/certificate/LogCenter/pkg-LogCenter/
somehow, so it might be good to add that path as
target_cert_dirs=(
[...]
"/usr/local/etc/certificate/LogCenter/pkg-LogCenter/")
# Faster ngnix restart (if certs don't appear to be refreshing, change to synosystemctl
if ! /usr/syno/bin/synow3tool --gen-all && sudo systemctl reload nginx; then
warn "nginx failed to restart"
fi
The above lines should change to
if ! /usr/syno/bin/synow3tool --gen-all; then
warn "nginx failed to generate config"
fi
info "Restart nginx"
# Faster ngnix restart (if certs don't appear to be refreshing, change to systemctl restart)
systemctl reload nginx
Otherwise, systemctl reload nginx
will not be executed.
Otherwise,
systemctl reload nginx
will not be executed.
@xiaozhuai: I'm not sure I understand how the above is true (or why you want to separate out the two commands). The intent is that we do not restart if the certs did not generate correctly and instead issue a warning.
systemctl reload nginx
will be executed if and only if the synow3tool --gen-all
command is executed correctly, which is the intent of the original code.
Could you provide an example where this does not work as intended?
Could you provide an example where this does not work as intended?
@catchdave
That's odd.
I try this script on my machine last time and foud the second command never exec.
And I'm sure the /usr/syno/bin/synow3tool --gen-all
is ok.
Confirmed, the script is wrong. You can try below.
#!/usr/bin/env bash
if ! true && echo "Good"; then
echo "Not good"
fi
It prints nothing.
It should be
#!/usr/bin/env bash
if ! (true && echo "Good"); then
echo "Not good"
fi
And it prints Good
.
So the script should change to
# Faster ngnix restart (if certs don't appear to be refreshing, change to systemctl restart)
if ! (/usr/syno/bin/synow3tool --gen-all && systemctl reload nginx); then
warn "nginx failed to restart"
fi
Thanks --you are right, it should have parenthesis! I updated the script. Appreciate the suggestion, @xiaozhuai
Hello @catchdave. Nice script! I want to test it. But I have DS218+ where in all certs directories are not just 3 files which is copied by your script.
There are these structure:
cert.pem chain.pem fullchain.pem info privkey.pem root.pem short-chain.pem
I can create cert.pem chain.pem fullchain.pem privkey.pem
But I haven't idea about root.pem short-chain.pem.
Do you have same structure? Or is it something new? How to solve it? Thx for info.
@raven2cz my advice is to initially manually add your LE cert and make it default. Through the DSM interface, the mapping of LE generated files is:
Private Key ---------------> privkey.pem
Certificate ---------------> cert.pem
Intermediate Certificate --> fullchain.pem
Once that's done and the LE cert is now your default certificate, the script should work fine.
Great script. You may also be interested in my old scripts for managing certificates also for other apps like MailStation and co. Recently I added also synow3tool call to be able to reload nginx properly in DSM7. This script presents jsut a slightly different approach and was mainly developed for DSM6. If you have a reliable way of reloading services in the absence of /usr/local/libexec/certificate.d/$subscriber in DSM7 I would really appreciate
Hey everyone, it's been about a year since I started using this script.
I've never been able to get VPN working with the updated certs automatically (with the script).
The VPNCenter package does restart, and I also tried restarting OpenVPN manually, which also doesn't help. (/var/packages/VPNCenter/target/scripts/openvpn.sh restart)
It seems I always have to manually go over Control Panel --> Security --> Certificate, then with the Settings button I need to change the certificate for "VPN Server", save, and then change it back.
Only then the VPN Server's certificate is "updated".
Anyone here using this script to update VPN Center's certificates?
@footswitch VPN requires the intermediate certificate to be updated, you may have the wrong file names selected, see my comment a few back regarding starting out with manual setup before automation https://gist.github.com/catchdave/69854624a21ac75194706ec20ca61327?permalink_comment_id=4787628#gistcomment-4787628
Synology WILL accept using the fullchain.pem
file as the "Certificate" file, however this causes VPN to fail. You need to use fullchain.pem
only for the Intermediate Certificate, and cert.pem
for "Certificate"
...I only remember this because I ran into the same issue.
#!/bin/bash
# modified version of https://gist.github.com/catchdave/69854624a21ac75194706ec20ca61327
# from https://github.com/catchdave
#
# - Important:
# Before this script can run reliably, you must first manually import your LE certificates into DSM.
# Private Key ---------------> privkey.pem
# Certificate ---------------> cert.pem
# Intermediate Certificate --> fullchain.pem
#
# It's possible to initially import certs WITHOUT adding an Intermediate Cert, and while this works in most cases,
# it will cause OpenVPN on Synology to fail, as it requires the intermediate certs present in fullchain.pem
# You can also add fullchain.pem as the "Certificate" file, which works, but it's important to upload the correct files
# as above, so that the synology certificate sync tool will write the correct contents into the "info" files and associate
# the correct files with the "cert", "chain", and "key".
#
Hi everyone, somewhat related, but has anyone figured out how to do the same for Synology Routers (SRM 1.3)?
@telnetdoogie I'm coming from a win-acme automation, and a while back (a year ago) I was trying to automate with the wrong intermediate file (chain-only from win-acme) and getting all sorts of errors: https://gist.github.com/catchdave/69854624a21ac75194706ec20ca61327?permalink_comment_id=4530953#gistcomment-4530953
-- Then I realised what the right file was: https://gist.github.com/catchdave/69854624a21ac75194706ec20ca61327?permalink_comment_id=4541242#gistcomment-4541242
However, NOW if I try to upload the (full)chain file into the Synology UI, it gives me an error; I can only replace the certificate without error if I choose the chain-only file. So this has suddenly changed and I don't know why or how.
I'm not even talking about the automation itself, I just lost OpenVPN connectivity a couple of months ago and I had to sort this out manually via the UI, and this is what I found.
I'm at a loss here.
I just realized my OpenVPN was broken after cert updates too. OpenVPN copies certs on install to a totally different location, and makes some modifications. Rather than try to fix it I just uninstall and reinstall and the OpenVPN does its thing from the ssl certs and works again.
Switch to wireguard and wg-easy and save yourself the hassle :)
Hello, thank you for your script. I did some modifications to fork of your script, maybe you would like to update yours as well: https://gist.github.com/tfilo/940856c9ef91e6a28f0d310aa899bb2c/revisions
Most important changes:
- In my DSM ActiveBackup and SynologyDrive certs had different owner than root.
- Added missing LogCenter, ReplicationService and kmip
- Added for loop to add all WebStation folders as well
- /usr/syno/bin/synosystemctl restart changed to /usr/syno/bin/synosystemctl try-restart to restarts only active units
@tfilo if you take a look at the version I have you'll see that you don't actually need to manage those destination folders... through testing I found that you just have to replace the certs in the default folder, and /usr/syno/bin/synow3tool --gen-all
will do all of the necessary copying for you to the appropriate locations where DSM otherwise manages certs. No need to add webstation folders etc.
@telnetdoogie thanks for information, I will look at it more but for first try it replaced only 2 out of 19 certificates. All WebStation certs stayed same after /usr/syno/bin/synow3tool --gen-all. Seems like only /usr/syno/etc/certificate/ReverseProxy/, /usr/syno/etc/certificate/system/default/ got replaced with this command. I would like to figure out how synology GUI does it. You select certificates, click next and it changes all certificates at one step. There must be some synology script or utility to update all at once somewhere in system.
@tfilo I see now... that makes sense! I added a 'check' for these other folders in my script too but yeah it'd be super nice to know how it pulls these certs... I know with VPNCenter the certs are copied by DSM on startup of that service, so maybe WebStation does the same thing as well?
@DJGauthier It appears you're running into a port forwarding issue. Have you been able to renew certs successfully using the Synology UI? The address you're using -
[mysyno].synology.me
will point to your public WAN IP, so you're unlikely to be able to test that locally unless you're doing some hairpin NAT rules on your router. I'd start with validating that LetsEncrypt certificates can be generated via the UI on the Synology NAS before you try to use scripts to do the same.Alternatively you could switch to certbot using DNS-01 challenge instead of HTTP-01 to avoid the need to have ports open and forwarded. More info here:
https://letsencrypt.org/docs/challenge-types/