Skip to content

Instantly share code, notes, and snippets.

@catchdave
Last active November 9, 2024 01:27
Show Gist options
  • Save catchdave/69854624a21ac75194706ec20ca61327 to your computer and use it in GitHub Desktop.
Save catchdave/69854624a21ac75194706ec20ca61327 to your computer and use it in GitHub Desktop.
CLI script to programmatically replace SSL certs on Synology NAS
# MOVED to public repo: https://github.com/catchdave/ssl-certs/blob/main/replace_synology_ssl_certs.sh
@telnetdoogie
Copy link

telnetdoogie commented Jun 12, 2024

@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"

@telnetdoogie
Copy link

...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".
#

@alejakun
Copy link

alejakun commented Jul 8, 2024

Hi everyone, somewhat related, but has anyone figured out how to do the same for Synology Routers (SRM 1.3)?

@footswitch
Copy link

@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.

@telnetdoogie
Copy link

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 :)

@tfilo
Copy link

tfilo commented Oct 5, 2024

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:

  1. In my DSM ActiveBackup and SynologyDrive certs had different owner than root.
  2. Added missing LogCenter, ReplicationService and kmip
  3. Added for loop to add all WebStation folders as well
  4. /usr/syno/bin/synosystemctl restart changed to /usr/syno/bin/synosystemctl try-restart to restarts only active units

@telnetdoogie
Copy link

@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.

@tfilo
Copy link

tfilo commented Oct 6, 2024

@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.

@telnetdoogie
Copy link

@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?

@telnetdoogie
Copy link

telnetdoogie commented Oct 6, 2024

@tfilo Yes, I just tested this... my script will check the /usr/local/etc/certificate/ path for certs now as well and as you can see below, my WebStation certs were not matching... restarting WebStation without copying the certs into those locations will re-sync those certificates with the ones in the system default folder. Maybe there's a less intrusive way than a restart but for now that might still be easier than copying the certs to every possible location:

➜  sudo ./check_certs.sh /volume1/docker/certbot/etc_letsencrypt/live/{mydomain}/cert.pem
The following certificates do not match the current version:
    - /usr/local/etc/certificate/ScsiTarget/pkg-scsi-plugin-server/cert.pem
    - /usr/local/etc/certificate/WebStation/7e8b547e-bd85-4d0e-8cb5-74d09c38e9c3/cert.pem
➜  sudo /usr/syno/bin/synopkg restart WebStation
restart package [WebStation] successfully
➜  sudo ./check_certs.sh /volume1/docker/certbot/etc_letsencrypt/live/hobbs-family.com/cert.pem
The following certificates do not match the current version:
    - /usr/local/etc/certificate/ScsiTarget/pkg-scsi-plugin-server/cert.pem
➜                                                            

In the case of the above... to sync those certs as well, rather than adding directories, I can just add

SERVICES_TO_RESTART=("pkg-scsi-plugin-server")
PACKAGES_TO_RESTART=("VPNCenter" "WebStation")

AND / OR

Add those folders to TARGET_FOLDERS in the script.

To resolve the above two, for example, WebStation re-syncs certs,
pkg-scsi-plugin-server does not.

So to resolve the case above, minimally I just:

  • Add WebStation to PACKAGES_TO_RESTART
  • Add pkg-scsi-plugin-server TO SERVICES_TO_RESTART
  • Add /usr/local/etc/certificate/ScsiTarget/pkg-scsi-plugin-server/ to the TARGET_FOLDERS

That gets all certs synced.

@tfilo
Copy link

tfilo commented Oct 6, 2024

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.

@telnetdoogie
Copy link

I just made another update too to the script so that when checking for 'non matching' certs (including the new certificate path that you identified - thank you!!) it will output some of the metadata from the info file if it exists as well. That can help identify Services that could be restarted as a potential "quick fix". So now the output would look like this for non-matching certs:

Warning: Some unmatched certs still exist, in the following locations:
======================================================================

  - /usr/local/etc/certificate/WebStation/7e8b547e-bd85-4d0e-8cb5-74d09c38e9c3
    - Service    : 7e8b547e-bd85-4d0e-8cb5-74d09c38e9c3
    - Subscriber : WebStation

  - /usr/local/etc/certificate/WebStation/poop
    - (info file not found in /usr/local/etc/certificate/WebStation/poop)

...check the script and add these folders to TARGET_FOLDERS for syncing"
or alternatively add appropriate packages to PACKAGES_TO_RESTART or SERVICES_TO_RESTART for those 
services that auto-sync certs
- WebStation is an example of a package that will re-sync certs from the system default on restart

 this script can then be run again with the '--force' parameter to retry"

@telnetdoogie
Copy link

I'm not sure how to 'merge' any of my stuff back into @catchdave 's original gist...

@catchdave
Copy link
Author

catchdave commented Oct 7, 2024

I actually found that sudo systemctl reload nginx line that several commenters said they preferred due to being less intrusive to actually not work for me. I just realized this when all my certs got out of date and was only fixed when I did a "actual ngnix restart".

So my script actually has if ! /usr/syno/bin/synow3tool --gen-all && sudo /usr/syno/bin/synosystemctl restart nginx; then which I have found to currently work for me.

Perhaps try changing it to restart instead of reload to see if that resolves the mis-matching cert issue. Easy enough to modify to add extra services if you think it needs to be.

@bungabear
Copy link

It seems that this code overwrites the certificates of all ReverseProxies, is that correct?

# Add reverse proxy app directories
for proxy in /usr/syno/etc/certificate/ReverseProxy/*/; do
    debug "Found proxy dir: ${proxy}"
    target_cert_dirs+=("${proxy}")
done

It would be better to modify it to overwrite only those using the default certificate.

# Add reverse proxy app directories that using default certificate
for proxy in /usr/syno/etc/certificate/ReverseProxy/*/; do
    if cmp -s "${certs_src_dir}/privkey.pem" "${proxy}/privkey.pem" ; then
        debug "Found proxy dir: ${proxy}"
        target_cert_dirs+=("${proxy}")
    fi
done

@bungabear
Copy link

bungabear commented Oct 22, 2024

And I have a question.
When I look at /etc/nginx/sites-enabled/server.ReverseProxy.conf,
I see that it uses another certificate in a path with "www" added, like the following:

...
server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name some.example.com ;

    if ( $host !~ "(^some.example.com$)" ) { return 404; }

    include /usr/syno/etc/www/certificate/ReverseProxy_f34f22f1-6cee-4707-8768-826a2e85d507/cert.conf*;

    include /usr/syno/etc/security-profile/tls-profile/config/ReverseProxy_f34f22f1-6cee-4707-8768-826a2e85d507.conf*;

    ...
}
...
#> cat /usr/syno/etc/www/certificate/ReverseProxy_f34f22f1-6cee-4707-8768-826a2e85d507/cert.conf
ssl_certificate          /usr/syno/etc/www/certificate/ReverseProxy_f34f22f1-6cee-4707-8768-826a2e85d507/f0c77d20-2385-470f-a90b-458aac52504f.pem;
ssl_certificate_key      /usr/syno/etc/www/certificate/ReverseProxy_f34f22f1-6cee-4707-8768-826a2e85d507/0e5d3729-671e-4a2a-9b9d-a08d0cdba465.pem;
ssl_certificate          /usr/syno/etc/www/certificate/ReverseProxy_f34f22f1-6cee-4707-8768-826a2e85d507/4ffbf2b5-0708-4462-b3f5-f61f72b8ed5b.pem;
ssl_certificate_key      /usr/syno/etc/www/certificate/ReverseProxy_f34f22f1-6cee-4707-8768-826a2e85d507/3e1a6a19-a158-4a18-a052-3dc2e6fdce76.pem;

I’m not sure if only I have different paths like this or if they are automatically re-generated.

@catchdave
Copy link
Author

@bungabear the answer to both is maybe. Is something not working for you?

This script works for me and my reverse proxies—is there a bug or negative symptom you’re experiencing, or is the questions theoretical?

for the www—when you run the script, does your certs work when visiting your custom domains? If not, what is the specific issue?

@bungabear
Copy link

bungabear commented Oct 22, 2024

@catchdave
Sorry, this script works well.
It just failed to restart NGINX once.

@Redjard
Copy link

Redjard commented Oct 23, 2024

@bungabear @catchdave
I did have problems with the script overwriting a second certificate I created with letsencrypt through dsm for something else.
In the process of fixing that I rewrote the core part of the script, and then a lot more of it around that

The entire rewritten script
# *** For DSM v7.x ***
#
# How to use this script:
#  1. Get your 3 PEM files ready to copy over from your local machine/update server (privkey.pem, fullchain.pem, cert.pem)
#     and put into a directory (this will be $CERT_DIRECTORY).
#     Personally, I use this script (https://gist.github.com/catchdave/3f6f412bbf0f0cec32469fb0c9747295) to automate steps 1 & 4.
#  2. Ensure you have a user setup on synology that has ssh access (and ssh access is setup).
#     This user will need to be able to sudo as root (i.e. add this line to sudoers, <USER> is the user you create):
#       <USER> ALL=(ALL) NOPASSWD: /var/services/homes/<USER>/replace_certs.sh
#  3. Copy this script to Synology: sudo scp replace_synology_ssl_certs.sh $USER@$SYNOLOGY_SERVER:~/
#  4. Call this script as follows:
#     sudo bash -c scp ${CERT_DIRECTORY}/{privkey,fullchain,cert}.pem $USER@$SYNOLOGY_SERVER:/tmp/ \
#     && ssh $USER@$SYNOLOGY_SERVER 'sudo ./replace_synology_ssl_certs.sh your.domain.org'


DEBUG=  # Set to any non-empty value to turn on debug mode
error_exit() { echo "[ERROR] $1"; exit 1; }
warn() { echo "[WARN ] $1"; }
info() { echo "[INFO ] $1"; }
debug() { [[ "${DEBUG}" ]] && echo "[DEBUG ] $1"; }

shopt -s nullglob  # allows wildcards like /usr/syno/etc/certificate/_archive/*/ without them adding that literal string if they don't match anything

# 0. Checks
[[ "$EUID" -ne 0 ]] && error_exit "Please run as root"  # Script only works as root
[[ "${DEBUG}" ]] && set -x

# 1. Config
# =================
hostname="$1"  # will update all certs signing for this hostname
# cert="/etc/redjard-certs/$hostname.crt"
# fullchain="/etc/redjard-certs/$hostname.crt"  # usually the cert already has the chain in it
# privkey="/etc/redjard-certs/$hostname.key"
cert="/tmp/$hostname.crt"
fullchain="/tmp/$hostname.crt"  # usually the cert already has the chain in it
privkey="/tmp/$hostname.key"

services_to_restart=("nmbd" "avahi" "ldap-server")
packages_to_restart=("ScsiTarget" "SynologyDrive" "WebDAVServer" "ActiveBackup")
target_cert_dirs=( # directories that have cert.pem, fullchain.pem, and privkey.pem
	"/usr/local/etc/certificate/ActiveBackup/ActiveBackup"
	"/usr/local/etc/certificate/LogCenter/pkg-LogCenter"
	"/usr/local/etc/certificate/ScsiTarget/pkg-scsi-plugin-server"
	"/usr/local/etc/certificate/SynologyDrive/SynologyDrive"
	"/usr/local/etc/certificate/WebDAVServer/webdav"
	"/usr/local/etc/certificate/WebStation/"*/
	"/usr/syno/etc/certificate/system/default"
	"/usr/syno/etc/certificate/system/FQDN"
	"/usr/syno/etc/certificate/smbftpd/ftpd"
	/usr/syno/etc/certificate/_archive/*/
	"/usr/syno/etc/certificate/ReverseProxy/"*/
)
target_obfuscated_cert_dirs=( # for directories that have one cert.conf in nginx format, pointing files in style 01234567-89ab-cdef-0123-456789abcdef.pem
	/usr/syno/etc/www/certificate/system_FQDN
	/usr/syno/etc/www/certificate/system_default
	/usr/syno/etc/www/certificate/ReverseProxy_*/
	/usr/syno/etc/www/certificate/WebStation_*/
)

# 2. Copy certificates to target directories if they exist
# ========================================================
for target_dir in "${target_cert_dirs[@]}"; do
	if [[ ! -d "$target_dir" ]]; then
		debug "Target cert directory '$target_dir' not found, skipping..."
		continue
	fi
	
	# synology generated letsencrypt certs have different filenames, but we don't touch them anyway
	if ! openssl verify -show_chain -x509_strict -verify_hostname "$hostname" -untrusted "$target_dir/cert.pem" "$target_dir/cert.pem" >/dev/null 2>&1; then
		debug "Skipping $target_dir as the cert doesn't sign for $hostname"
		continue
	fi
	
	debug "Copying certificates to '$target_dir'"
	cp "$cert" "$target_dir/cert.pem"
	cp "$fullchain" "$target_dir/fullchain.pem"
	cp "$privkey" "$target_dir/privkey.pem"
	
	# is this necessary?
	if ! chown root:root "$target_dir/"{privkey,fullchain,cert}.pem; then
		warn "Error copying or chowning certs to ${target_dir}"
	fi
done

# somehow WebStation ends up not getting applied later, so lets manually do it (if it works later it will simply get overwritten)
for target_dir in "${target_obfuscated_cert_dirs[@]}"; do
	if [[ ! -d "$target_dir" ]]; then
		debug "Target obfuscated cert directory '$target_dir' not found, skipping..."
		continue
	fi
	
	target_crt=$( grep -o "$target_dir"/cert.conf -Pe '(?<=ssl_certificate\s)\s*.*(?=;$)'     | head -n 1 | xargs )
	target_key=$( grep -o "$target_dir"/cert.conf -Pe '(?<=ssl_certificate_key\s)\s*.*(?=;$)' | head -n 1 | xargs )
	
	# synology generated letsencrypt certs have different filenames, but we don't touch them anyway
	if ! openssl verify -show_chain -x509_strict -verify_hostname "$hostname" -untrusted "$target_crt" "$target_crt" >/dev/null 2>&1; then
		debug "Skipping obfuscated $target_dir as the cert doesn't sign for $hostname"
		continue
	fi
	
	debug "Copying obfuscated certificates to '$target_dir'"
	cp "$fullchain" "$target_crt"
	cp "$privkey" "$target_key"
done

# 3. Restart services & packages
# ==============================
info "Rebooting all the things..."
for service in "${services_to_restart[@]}"; do
    /usr/syno/bin/synosystemctl restart "$service"
done
for package in "${packages_to_restart[@]}"; do  # Restart packages that are installed & turned on
    /usr/syno/bin/synopkg is_onoff "$package" 1>/dev/null && /usr/syno/bin/synopkg restart "$package"
done

# 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

nginx -s reload

info "Completed"

Basically, the core part is openssl verify -show_chain -x509_strict -verify_hostname "$hostname" -untrusted "$target_dir/cert.pem" "$target_dir/cert.pem".
My modified version is called as syno_insert_cert "redjard.org" (replacing in your own domain naturally).
It will check if the certificate signs for the specified domain, and only replaces it if it does. (Works with any valid domain, doesn't have to be the main one. It would even be possible to add specific domains to certificates only for the purpose of telling them apart.)
I think this command also fails if the certificate is expired, there might be the flag -no_check_time which can be added but I have not confirmed if it works.

Since the script already has a more reliable criterium to find the correct certificates, I removed other conditions and simply added a list of directories to look through and potentially replace certificates in.

I have one loop for directories that have named files, where it replaces cert.pem, fullchain.pem, and privkey.pem, and one loop for directories specifically for some nginx usecases, which have a cert.conf pointing to obfuscated filenames.
The script loops over both these lists and replaces any matching certificates.
If any new location for certificate comes up, one can simply import their certificate, and grep for some string within it throughout the dsm filesystem, then add the discovered directories to the respective list.

I think this is a lot more readable than the original script which has a lot more special cases.

This is my own fork of the script which I have used for quite a while. I have had no issues for my usecase. I tried to quickly rewrite it a bit to get it back in line with how the original script worked, but it might need a few more tweaks to be fully backwards compatible (minus needing a domain name argument).

@mamema
Copy link

mamema commented Oct 30, 2024

the script from @catchdave imports the certs but at the same time removes all existing ones, as from synology itself for example. Which leads to a non functioning package center.....

@catchdave
Copy link
Author

@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.

@mamema
Copy link

mamema commented Oct 30, 2024

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

@catchdave
Copy link
Author

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.

@mamema
Copy link

mamema commented Oct 30, 2024

which directories do you want, it's a fresh install ds1819+ with latest DSM only script is yours?

@catchdave
Copy link
Author

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?

@catchdave
Copy link
Author

@mamema . This might be helpful to find all certs on your box: https://gist.github.com/catchdave/ff9c7d7a396a3201cfb14f912d3e5cda

@mamema
Copy link

mamema commented Oct 31, 2024

�[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

@catchdave
Copy link
Author

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?

@mamema
Copy link

mamema commented Oct 31, 2024

of course. can i enable somew kind of debugging with your script?

@catchdave
Copy link
Author

catchdave commented Nov 5, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment