Question Is there a way for automatic export a Let's Encrypt certificate to a folder?

Currently reading
Question Is there a way for automatic export a Let's Encrypt certificate to a folder?

2
1
fasterpage.cz
NAS
DS918+
Operating system
  1. macOS
  2. Windows
Mobile operating system
  1. iOS
Hello to everyone,
I had a DS214 for many years and I was very happy with its features. But I needed more space and more disks, so I upgraded to DS918 + a few days ago. And because I try to make the most of my equipment, I also started using also the Docker and in it jacobalberty UniFi Controller.

There is one annoying thing, Docker container (or this one) cannot use the certificate from the NAS. So I have to manually make a backup of the LE certificate to a .zip file and manually unzip it to the folder I mapped for him.

So, my question is. There is a way to automate this process. Or even better, its possible to direct mapping to the default certificate folder, inside the NAS file system?

I tried searching google, searching here on the forum, even elsewhere. But I did not find a solution. So thank you for your help and advice.
 
So, my question is. There is a way to automate this process. Or even better, its possible to direct mapping to the default certificate folder, inside the NAS file system?
You can use Task Scheduler to copy the files from the source location where the certs live to the mapped folder considering that everything is on the NAS. Creating a Linux copy script will allow you to do this.
 
This is an enhanced version of script I created long time ago for the german synology forum: jboxberger/synology-gitlab-jboxberger

The script searches the archive folder for the certificate matching a given domain, checks wether the certificate is newer than the one in the target and restarts a container if the certificate changed. The container restart is done using the syno specific commands.

Feel free to tailor it for your needs.
 
welcome here!
no way for UniFi controller, there is a folder (defined by Ubiquiti), where you need to place the certificate and UniFi system is watching this folder.

There is a better way than described by you (zip-transport-unzip):
transport within Docker folders mapped at your computer side = then Copy/Paste only.

But sometimes you can find a problem between certificate keystore format (defined by SW producer).
Here is guide how to change the keystore format.
 
This is an enhanced version of script I created long time ago for the german synology forum: jboxberger/synology-gitlab-jboxberger

The script searches the archive folder for the certificate matching a given domain, checks wether the certificate is newer than the one in the target and restarts a container if the certificate changed. The container restart is done using the syno specific commands.

Feel free to tailor it for your needs.
This looks great! :love: If I'm looking at your script well, just change the paths for the UniFi Controller share here. And also certificate files. Am I right?
 
Last edited:
You will want to change:
GITLAB_CERT_DIR: target folder where the container expects the certs
GITLAB_CERT: expected name of the .crt file within the containerized application
GITLAB_KEY: expected name of the .key file withing the containerized application

and add:
GITLAB_NAME: name of the container to restart

Maybee, you will need to remove the first two lines starting with a "." character that source other bash files. You don't need them.

After that you can add a scheduled task every x minutes or hours. The script will skip execution if the files in target are older than in the source folder.

Update:
You will need to add these as well:
HOSTNAME: full qualified domain name the certificate is issued for
SYNO_WEBAPI=/usr/syno/bin/synowebapi
 
Last edited:
Great script! Unfortunately didn't work for me without some changes.
Ok so, I found out if you use the jacobalberty unifi docker, it will automatically import cert files from unifi/cert
It has that feature built in, and as well it will recognize the let's encrypt variation and adjust for that. That makes it way handier because all that has to be done is export the let's encrypt cert files from synology over to the docker and let it process it. Which you probably know, but I wanted to summarize.

So normally one would have a share somewhere that was set as a volume to the docker of /unifi
No need to adjust the volumes on the docker, just check that the /unifi folder has a /cert subfolder though the script should make one if it doesn't have it.
Some additional info is under the "Certificate Support" section of his docker info page

Then I found I had to tweak the script given above by one-eyed-king. I first started with the tweaks he mentioned then ended up taking it further. Here's my working script below.

1) Note that this script assumes you've run the acme.sh stuff to get a let's encrypt cert already and it's showing properly in the synology certificates list. I've not tested it with the synology lets encrypt GUI process because I wanted a wildcard, so I manually used the acme.sh process.

2) Make sure to edit the GITLAB_CERT_DIR value to match yours (CASE matters here! If you get it wrong it won't work properly)

3) Edit the HOSTNAME value to match yours. I put in comments to call attention to those variables.

4) Also verify your GITLAB_NAME is correct to match the name of that docker instance for jacobalbery unifi though if everything was setup as default it probably does.

5) Throw the script somewhere accessible on the NAS and then make a synology task in task scheduler (in synology control panel) to run it. The task info under the run command user defined script will look something like:
bash /volume1/synostuff/scripts/import-syno-cert-script.sh
Of course match that to your synology folder location and script name.
I've set mine to run daily (it won't do anything until it picks up a new cert when the lets encrypt renews), and I added some bits to make sure it generates more outputs if I need to go look at the script outputs. I don't think you can run this task without root (which synology sets by default as the user for tasks), because I think only root can get access into that cert archive folder, though I'm not an expert.
Oh and if using windows DON'T USE NOTEPAD to edit the script. It will screw up the line feeds and the synology will have issues running it. I used notepad++ and that app worked fine once I verified it was set to EOL conversion of unix LF.

One of the driving factors behind me doing this was because unifi docker with it's insistence upon HTTPS only traffic (it can't even be configured to use HTTP) and it having a self signed default cert, was breaking the chrome "lock" on my properly secured synology HTTPS access. Apparently when chrome see two certs on the same site name with one not valid, it freaks out and turns all the locks to "not secure" for that site. And now maybe that I've worked out how to programmatically export the letsencrypt cert files in a scheduled task, maybe I can get my other stuff like plex going on an HTTPS access with proper certs.


Bash:
#!/bin/sh
# . "$(dirname $0)"/common
# . "$ETC_PATH"/config

########################################################################################################################
# VARIABLES
########################################################################################################################
FORCE_RENEW=0
SYNO_CERT_DIR="/usr/syno/etc/certificate/_archive"
GITLAB_CERT_DIR="/volume1/dockerstuff/Unifi/cert"
# edit above line to match your volume share to the unifi docker CASE MATTERS and have /cert at the end.
GITLAB_CERT="cert.pem"
GITLAB_CHAIN="chain.pem"
GITLAB_KEY="privkey.pem"
GITLAB_NAME="jacobalberty-unifi1"
HOSTNAME="example.com"
# edit the above line to match your domain name that lets encrypt is using such as example.com don't use wildcards
SYNO_WEBAPI="/usr/syno/bin/synowebapi"

########################################################################################################################
# PARAMETER HANDLING
########################################################################################################################

for i in "$@"
do
    case $i in
            --force-renew)
            FORCE_RENEW=1
        ;;
        *)
            # unknown option
        ;;
    esac
    shift
done

if ! [ -d "$GITLAB_CERT_DIR" ]; then
  mkdir -p "$GITLAB_CERT_DIR"
fi


for current_domain_cert in ${SYNO_CERT_DIR}/*; do
  if [ -d ${current_domain_cert} ] && [ -f ${current_domain_cert}/cert.pem ]; then
        openssl x509 -in ${current_domain_cert}/cert.pem -text | grep DNS:${HOSTNAME} > /dev/null 2>&1
        domain_found=$?
        if [ "${domain_found}" = "0" ]; then
            # time of last file change, seconds since Epoch
            last_change_cert_key=$(stat -c %Y ${current_domain_cert}/privkey.pem)
            echo ${last_change_cert_key} >&2
            if [ -f ${GITLAB_CERT_DIR}/${GITLAB_KEY} ];then
                last_change_gitlab_cert_key=$(stat -c %Y ${GITLAB_CERT_DIR}/${GITLAB_KEY})
                echo ${last_change_gitlab_cert_key} >&2
            else
                last_change_gitlab_cert_key=0
            fi
            if [ ${last_change_gitlab_cert_key} -le ${last_change_cert_key} ] || [ $FORCE_RENEW = 1 ]; then

                echo "gitlab ssl certificate is outdated... updating from domain certificate" >&2
                cp ${current_domain_cert}/privkey.pem ${GITLAB_CERT_DIR}/${GITLAB_KEY}
                cp ${current_domain_cert}/chain.pem ${GITLAB_CERT_DIR}/${GITLAB_CHAIN}
                cp ${current_domain_cert}/cert.pem ${GITLAB_CERT_DIR}/${GITLAB_CERT}

#                if ! [ -f "$GITLAB_CERT_DIR/dhparam.pem" ] && [ -f "/usr/syno/etc/ssl/dh2048.pem" ]; then
#                    cp "/usr/syno/etc/ssl/dh2048.pem" "$GITLAB_CERT_DIR/dhparam.pem"
#                fi

                echo "changing ownership of gitlab certificates" >&2
                chmod 400 ${GITLAB_CERT_DIR}/*

                echo "restarting gitlab container to activate new certificate" >&2
                $SYNO_WEBAPI --exec api=SYNO.Docker.Container version=1 method=stop name="$GITLAB_NAME" >&2
                $SYNO_WEBAPI --exec api=SYNO.Docker.Container version=1 method=start name="$GITLAB_NAME" >&2
            else
                echo "nothing to do, gitlab ssl certifiacte is same or newer than the domain ssl certificate" >&2
            fi
        fi
    fi
done
 
Last edited:
Oh now this is interesting to try an automate the renewal process of my LE certificates as I'm now also using the method @Rusty described somewhere on his blackvoid website. Once I've got @one-eyed-king 's script working I can sleep in peace.
Are you talking about this?

His setup for wildcard needs a manual step to import every time it's renewed, so that process is not yet automatable. Because he's doing it outside of DSM in the docker. His docker uses the acme.sh script process too, just it's hidden inside it. One would have to research how to IMPORT the cert into the DSM cert store using a script also, in order to make that automatable.

My method involves doing it internally to the DSM OS so that there's no need for an import step. The way I did it is first by setting up a domain name with and automating the DDNS with a DDNS docker. Although I used namecheap, Cloudflare can be automated in this way too.

Then the main piece with actually getting the cert is to SSH into DSM and use the acme.sh script method for the wildcard cert with let's encrypt. The advantage of this method is after the one time setup, you have a one line renewal script that can be automated in DSM task scheduler, and that the certificate starts out inside the DSM certificate store already, so there's no import step you need to automate. The disadvantage is you have to manually copy/paste lines to run the script manually for the first time. But it's a one time process.

Then finally my previous post above is describing automating the export process so you can use the cert for other things like a docker, such as the unifi docker.

That way the whole chain is automated, the renewal of the cert (which is already inside DSM by design) and the exporting.

This method is mostly covered on this page:

The piece with how to use a specific domain company with the DDNS bits with acme.sh is covered here:
It has a section on cloudflare too.
 
His setup for wildcard needs a manual step to import every time it's renewed, so it's not yet automatable
Correct. This was intentional, considering I wanted to describe getting wild cert for 3rd party domain outside of Synology LE wizard. Automation is definitely something that needs to be done on top of this.
 
Are you talking about this?
Yes that's it!
His setup for wildcard needs a manual step to import every time it's renewed, so that process is not yet automatable.
For me it's automatable. Because I reverse proxy everything that is running with a seperate nginx Docker container. I don't reverse proxy in DSM. So I pretty much need to copy the newly generated cert files from the LE docker container to my Nginx docker container (both containers have a -v mount to /volume1/docker )

But I could also consider to -v the /cert path I have inside my nginx docker container directly in the folders of my LE docker containers, but I think that may cause conflicts.
 
Yes that's it!

For me it's automatable. Because I reverse proxy everything that is running with a seperate nginx Docker container. I don't reverse proxy in DSM. So I pretty much need to copy the newly generated cert files from the LE docker container to my Nginx docker container (both containers have a -v mount to /volume1/docker )

But I could also consider to -v the /cert path I have inside my nginx docker container directly in the folders of my LE docker containers, but I think that may cause conflicts.
Ohhhh ok. So you only need to cert the exposed end piece the nginx sounds like, and don't need the import step. I wasn't aware of that. Whereas with my method if I went into the nginx route I'd be having that extra needless step. Ah the beauty of sharing methods and script code, things can be customized to fit needs of various bits that people need in their system. That's interesting, I'm still learning things revolving around synology I only got it last month. So I'm not familiar with the reverse proxy stuff, another thing to learn on my list!
-- post merged: --

oh hey it merged the replies, awesome, I was trying to figure out how to multi quote and get it into same post lol.
Correct. This was intentional, considering I wanted to describe getting wild cert for 3rd party domain outside of Synology LE wizard. Automation is definitely something that needs to be done on top of this.
Which as I now see above from Shadow has uses I hadn't even considered!
 
I was trying to figure out how to multi quote and get it into same post lol.
 
Last edited:
Yesterday I was playing with acme.sh. My dns-provider is supported by its dns01-challenge, I just had to tinker arround to understand which setting for --dnssleep (=duration in seconds to postpone the dns txt-entry verification - this will vary from provider to provider; I had to use 600 for netcup ) works with my provider. On top acme.sh provides a deployhook that allows to push created certificates into the Synology cert manager. Both actualy worked suprisingly easy :)

Hint: If you put acme.sh on a fileshare (lets say the docker share) and let it create the certificates there as well, you can use the certificates right away with bind-mount volume in containers, and still push them to the cert manager.

List of supported DNS-API providers: acmesh-official/acme.sh
DSM Deployhook: acmesh-official/acme.sh
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Old thread notice: There have been no replies in this thread for quite some time. The last reply was on .
The content in this thread may no longer be relevant. It might be better to open a new thread instead.

Similar threads

  • Question
Is it this option that is causing it? I noticed this as well and I just disabled it.
Replies
6
Views
4,429
  • Question
Right I'll look into it next time I come close to renewing...
Replies
11
Views
4,264

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending threads

Back
Top