-
Star
(110)
You must be signed in to star a gist -
Fork
(21)
You must be signed in to fork a gist
-
-
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 |
i'm happy to provide more info.
It's just what i'm see after running your script.
Adhere to the infos (copy pem's to /tmp/ run the script. At that momernt only the orginal synology.com cert is there and afterwards the pem's get imported and the synolgy cert is gone.
You can test it by yourself with this solution: https://github.com/vdsm/virtual-dsm
I don't see that on my two synology machines, and this is the first I am hearing of this issue. If you can provide specific details on your actual machine(s) that can help understand what is happening, I'm happy to modify the script. Details about DSM version, other scripts that are running, state of your machine and directory listing before and after would be helpful.
which directories do you want, it's a fresh install ds1819+ with latest DSM only script is yours?
The directory before and after executing the script that contains the missing/changed certs you say get removed (ls -la).
As much info you can provide - which specific files in which directory go missing, how does this look in the directory on the CLI, how does it look in the UI, etc.
Where is your default cert that goes missing located?
@mamema . This might be helpful to find all certs on your box: https://gist.github.com/catchdave/ff9c7d7a396a3201cfb14f912d3e5cda
�[1;97m�[1;100m| Filename | Valid From | Valid To | Domain | Issuer |�[0m
| �[0;95m/usr/syno/etc/certificate/smbftpd/ftpd �[0m |
| fullchain.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| cert.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| syno-ca-cert.pem | �[1;32mOct 30 10:20:16 2024 GMT �[0m | �[1;32mOct 31 10:20:16 2025 GMT �[0m | Synology Inc. CA | Synology Inc. |
| �[0;95m/usr/syno/etc/certificate/system/default �[0m |
| fullchain.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| cert.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| syno-ca-cert.pem | �[1;32mOct 30 10:20:16 2024 GMT �[0m | �[1;32mOct 31 10:20:16 2025 GMT �[0m | Synology Inc. CA | Synology Inc. |
| �[0;95m/usr/syno/etc/certificate/_archive/cSoecp �[0m |
| fullchain.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| cert.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| syno-ca-cert.pem | �[1;32mOct 30 10:20:16 2024 GMT �[0m | �[1;32mOct 31 10:20:16 2025 GMT �[0m | Synology Inc. CA | Synology Inc. |
| �[0;95m/usr/syno/etc/certificate/_archive �[0m |
| cert.pem | �[0;31mJan 4 08:27:06 2024 GMT �[0m | �[0;31mApr 3 08:27:05 2024 GMT �[0m | *.example.com | Let's Encrypt |
�[0;31m�[1m[WARN] No Valid Certs in: �[0m�[0;31m/usr/syno/etc/certificate/_archive/�[0m
| �[0;95m/usr/syno/etc/certificate/kmip/kmip �[0m |
| fullchain.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| cert.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| syno-ca-cert.pem | �[1;32mOct 30 10:20:16 2024 GMT �[0m | �[1;32mOct 31 10:20:16 2025 GMT �[0m | Synology Inc. CA | Synology Inc. |
| �[0;95m/usr/syno/etc/www/certificate/system_default �[0m |
| 152f89f2-20d5-4d1d-867c-d2b582b2313d.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| �[0;95m/usr/local/etc/certificate/LogCenter/pkg-LogCenter �[0m |
| fullchain.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| cert.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| syno-ca-cert.pem | �[1;32mOct 30 10:20:16 2024 GMT �[0m | �[1;32mOct 31 10:20:16 2025 GMT �[0m | Synology Inc. CA | Synology Inc. |
| �[0;95m/usr/local/etc/certificate/ScsiTarget/pkg-scsi-plugin-server �[0m |
| fullchain.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| cert.pem | �[1;32mOct 30 10:20:17 2024 GMT �[0m | �[1;32mOct 31 10:20:17 2025 GMT �[0m | synology | Synology Inc. |
| syno-ca-cert.pem | �[1;32mOct 30 10:20:16 2024 GMT �[0m | �[1;32mOct 31 10:20:16 2025 GMT �[0m | Synology Inc. CA | Synology Inc. |
�[1m=== Summary ===�[0m
�[1;97m�[1;100mTotal Directories �[0m | �[1m8 �[0m
�[1;97m�[1;100mTotal Certificates �[0m | �[1m20 �[0m
�[1;97m�[1;100mTotal Dirs w/ no valid cert �[0m | �[1m1 �[0m
�[1;97m�[1;100mTotal Valid Certs �[0m | �[1m19 �[0m
�[1;97m�[1;100mTotal InValid Certs �[0m | �[1m1 �[0m
all in all only Synology certs. And the remains of my trying import my own certs. They are lying around, but i've had already to reset the certs, as i said, the cert from synology wasn't shown in the security/cert gui area and the package manager wasn't working.
Perhaps this was a missundestanding, the certs are physically there on disk, but after runing your script, the synology one, wasn't shown in the security gui area of DSM
If the certs are physically there, I'm not sure besides maybe how services were restarted would affect the GUI.
I assume you tried restarting the machine?
of course. can i enable somew kind of debugging with your script?
@mamema - yes set a manual DEBUG flag in the script (change DEBUG= line to DEBUG=1). This will both print out manual debug statements and turn on set -x which will echo each command before execution.
As the comment threads for this once upon a time simple script ( 😄 ), I have moved this to a public repo instead. That way conversations about potential bugs can take place as issues.
See here: https://github.com/catchdave/ssl-certs/blob/main/replace_synology_ssl_certs.sh
I added a second domain to my Synology today and realized that with multiple certificates for different uses/destinations this got a bit more complex. I rewrote from scratch and it handles multiple certificates and their specific locations pretty well (work for a single cert as well)
https://github.com/telnetdoogie/synology-scripts/blob/main/check_certs.md
Well thats interesting, it looks like in my case restarting of webstation didn’t update certificates, but maybe i was just too hurry and didn’t let enough time for sync to happen. I will try to investigate it more but not sure if i will find time to play around with it in next few weeks. But i will try to find some time at evenings. Definetly i will let you know with results.
So finaly i found some time for testing. I found out that webstation doesn’t use new certificates if i don’t restart NAS. I will try to find some way how to do it without restart.
@tfilo Cau Tomáš, did you ever figure this out? I'm quite new to the whole SSH thing but managed to get the certificates nicely copied to my NAS etc, but... it doesn't use them. I don't like restarting nginx as it also force closes my virtual machines. But I cannot figure out how to reload some services that will actually replace the old certificate with the new one and start using it. Neither can ChatGPT :-D
/usr/syno/bin/synow3tool --nginx=reload will reload nginx configs and certificates.
/usr/syno/bin/synopkg restart "package_name" restarts packages
/usr/syno/bin/synow3tool --gen-all will regen certs if needed in 'other' packages.
For almost every case I've found, DSM does not need to be restarted.
``Thanks for that quick reply! In that case, I'm doing something wrong I think... linux is really not my thing (and I must admit, I love ChatGPT, it's been really helpful so far!) so I'm a bit lost here...
For the moment I created the following script:
#!/bin/bash
#Define paths to certificate and key files on the Debian VM
CERT_PATH="/etc/letsencrypt/live/mydomain.com/fullchain.pem"
KEY_PATH="/etc/letsencrypt/live/mydomain.com/privkey.pem"
SSH_KEY="/home/myusername/.ssh/certbot_key"# Define the target directory on the NAS (mounted SMB share)
NAS_SHARE="/mnt/debian/certificates/mydomain.com"# Define the target directory in Synology’s system certificates
NAS_USER="certification_bot"
NAS_IP="192.168.1.1"
NAS_CERT_DIR="/usr/syno/etc/certificate/system/default"# Ensure the target directory exists (on the SMB share)
mkdir -p "$NAS_SHARE"# Copy certificates to NAS share
cp "$CERT_PATH" "$NAS_SHARE/fullchain.pem"
cp "$KEY_PATH" "$NAS_SHARE/privkey.pem"# Now, move the certificates from the SMB share to the Synology system director>
ssh -i "$SSH_KEY" $NAS_USER@$NAS_IP << 'EOF'
sudo cp "/volume1/vm-share/certificates/mydomain.com/ful>
sudo cp "/volume1/vm-share/certificates/mydomain.com/pri>
sudo synow3tool --restart-dsm-service
EOF
Domain names, directories and usernames are fictional.
I have tried with --restart-dsm-service as well as --nginx=reload, and some other ways, but I'm not getting the result I expect.
When I run the following on my NAS:
ls -l /usr/syno/etc/certificate/system/default/
I get the folder with the 2 files that I just copied over, but also two other files with a different timestamp. If I import the files through DSM, all 4 files have the same timestamp but that is not the case here.
ls -l /usr/syno/etc/certificate/system/default/
total 16
-r-------- 1 root root 2851 Feb 19 01:48 cert.pem
-r-------- 1 root root 2851 Feb 19 01:54 fullchain.pem
-rw------- 1 root root 240 Feb 19 01:48 info
-r-------- 1 root root 241 Feb 19 01:54 privkey.pem
In this case, at 1:48 I replaced my certificate through DSM, which worked.
At 1:54 I ran my script which copied the fullchain.pem and privkey.pem files correctly, but then nothing. Reloading nginx didn't do the trick. Or is it just not necessary???
I have the feeling there is an intermediate step missing, one that reads the certificates and installs them or so, before restarting/reloading the server. Or maybe I am looking at this completely wrong... thanks again for looking at it :-)
I've struggled with similar stuff. It's possible you originally uploaded the wrong files? (and I think synology changed this slightly too)
For "Private Key" in DSM, upload privkey.pem
For "Certificate" upload cert.pem
Do not upload the intermediate certificate
See if that helps.
It also works (differently) with:
For "Private Key" in DSM, upload privkey.pem
For "Certificate" upload fullchain.pem
For "Intermediate Certificate" upload chain.pem
However I've run into issues with this second setup so I avoid it; perhaps this is the route you took originally... Synology does strange things. I only move privkey and cert.pem in my setup, ignoring fullchain. But it changes based on what you originally uploaded into DSM.
I'm having a hard time renewing openvpn certificates from cli.
I copy new {cert|fullchain|privkey}.pem to usr/local/etc/certificate/VPNCenter/OpenVPN
From the CLI, using the openssl command, I confirmed that these are valid
restart VPNCenter:
/usr/syno/bin/synopkg restart VPNCenter
and restart openvpn:
/var/packages/VPNCenter/target/scripts/openvpn.sh restart
The textfile /usr/local/etc/certificate/VPNCenter/OpenVPN/info seems to confirm that the location of the certs is indeed the one I just copied over:
{"certs":[{"cert":"/usr/local/etc/certificate/VPNCenter/OpenVPN/cert.pem","chain":"/usr/local/etc/certificate/VPNCenter/OpenVPN/fullchain.pem","key":"/usr/local/etc/certificate/VPNCenter/OpenVPN/privkey.pem"}],"service":"OpenVPN","subscriber":"VPNCenter"}
Yet my openvpn client states that the server certificate is expired.
It seems that synology openvpn-server is still using the old (expired) certificate.
What am I missing?
Thank you.
sudo /var/packages/VPNCenter/target/hook/CertReload.sh copy_cert_only
@telnetdoogie
Thank you so much; it's working now!
@mamema —which line of my script removes existing certs? It is simply a move, chown and restart.
If you’re having issues, please provide more details.