acme .sh deploy Scipt for TrueNAS Server that uses the REST API from TrueNAS.
- Authentification with API Key
- If HTTP redirect is configured, automatik switch to HTTPS
- If WebDAV Certificate is the same as Web UI Certificate, Webdav Certificate get also an updated
- If FTP Certificate is the same as Web UI Certificate, FTP Certificate get also an updated
Small changes for DSM 6:
All fields (except enable_syno_token as explained below) must either be in the GET params or the POST params, you can't mix GET and POST params
enable_syno_token=yes must be in both the GET and POST params.
If enable_syno_token=yes is only in the POST fields, then DSM6 returns a synotoken of --------. If enable_syno_token=yes is only in the GET params, then it returns no synotoken at all. It must be in both to work.
Need to use /webapi/auth.cgi instead of /webapi/entry.cgi
Verified with DSM 6.2.3-25426 Update 2 and DSM 7.0-40850
This allows us to get the cookie and the token (as it appears to be only in the body in DSM 7.) HTTP_HEADERS is only guarenteed to be output with POST for both wget and curl.
I have modified the following things:
Originally, "/data/assets/ssl/" is always appended to the varialbe ${_mailcow_path}. Since I use acme.sh as docker container, I only want to include the mailcow-ssl directory in the acem.sh container and not the complete mailcow directory. So now it is checked if the file generate_config.sh is in the directory (then it is the mailcow root directory, see https://github.com/mailcow/mailcow-dockerized) and only then "/data/assets/ssl/" is appended, in all other cases the passed variable is taken over unchanged.
Because of the RP mailcow/mailcow-dockerized#2443 I have extended the script with ECC certificates.
I adapted the reboot commands as described in the mailcow manual (https://mailcow.github.io/mailcow-dockerized-docs/firststeps-ssl/#how-to-use-your-own-certificate).
This provider relies on the the python-openstackclient and
python-designateclient tools be installed and working, with
either password or application credentials loaded in your env.
I'm actually not entirely sure why/how this worked with curl but not wget, but it did. The short answer is that using a GET does not result in the HTTP_HEADER file being written, instead you must pass in the http_headers param ($2) which will return the HTTP headers as a string. Luckily, the Token is in both the body and the header. We need it and the id (and smid if 2fa) cookie to proceed. So now we parrse the response for that instead of the HTTP_HEADER file.
Interesting side note: wget is fine if the URL contains a \r or \n, but curl will barf on it. So we need to make sure those are stripped from the token as it will be passed in the URL later.
It was discovered in testing that PAN-OS < 9.0 has slightly different
requirements for the multipart/form-data format and requires the `type`
parameter to be passed in the URL. These corrections should work for all
PAN-OS versions.
Before this update all remote commands were bunched together and
sent to the remote host in a single SSH command. This could result
in a very long sequence of commands that might be rejected by a
remote host (example is VMware ESXi that uses busybox sh).
With this update you can set DEPLOY_SSH_BATCH_MODE="no" and
each remote command is sent as a separate SSH call so now we
do not have big long sequence of commands. Defaults to same
behaviour as before this update.
haproxy deploy script now compatible with OpenSSL v1.1+
The OpenSSL OCSP request for haproxy deployment breaks from OpenSSL v1.1.0 on.
The format of the `-header` option has been changed and does now contain a `=` instead of a whitespace.
Other projects have hit the same issue:
https://github.com/nghttp2/nghttp2/issues/742
This commit determines the OpenSSL/LibreSSL version and then adjusts the request accordingly.
Also removed the duplicate command line and added some more debug output.
This allows you to update a key on a Synology DSM using the existing API.
Handles restarting the necessary services the certificate is attached to and all other internal stuff (copying the certificate around, etc.)
This is way less error prone than most articles I've found on how to update a Synology DSM certificate.
