Repository navigation
|
I've been successfully using this script to renew a wildcard SSL certificate for many months now - and renewals always worked fine. However, upon this morning's scheduled renewal I got this as the output: ... so I reviewed my notes, did an export command for: then re-ran the script, which then failed again - the deploy section (with debug enabled) is as follows: ... so I checked that the account password was correct (it was) and tried again - no change. I then re-set the password to the what had been put in the SYNO_PASSWORD value (just in case) - still no change. I also tried enabling access to the DSM application in permissions (although it didn't have it in the past) - but that didn't help either. By now, I'd run out of attempts to generate a certificate so thought I'd try to deploy it manually instead - as the certificate files are already in /usr/local/share/acme.sh/sounds.me.uk_ecc - but that's also failing. The command I'm using (from /usr/local/share/acme.sh) is: ... I tried running ./acme.sh --upgrade and trying again, but still get the same error. Any ideas as to why the script failed initially all of a sudden (with the 400 error) and why I can't get the certificate to deploy? Thanks :-) EDIT: the values appear to be stored correctly, as if I enter ./acme.sh --info -d sounds.me.uk --home $PWD I get: |
Replies: 3 comments 2 replies
|
OK, my mistake ... I got the command for deploy wrong, should have removed the .sh from the deploy routine name. Retried with |
|
OK, think I've got it sussed. Had to re-update the value for SYNO_PASSWORD - enclosing it in single quotes rather than speech marks. I did SYNO_USERNAME as well, for good measure. The updated certificate is now deployed to DSM, albeit the old one was still there too. I then cleared the "SYNO_CREATE=1" value and set "SYNO_CERTIFICATE" to the description of the current one, then tried again - this time it replaced the certificate - perfect. I noted that with SYNO_CREATE=1, the penultimate output is "Restart HTTP services failed.", whereas with SYNO_CERTIFICATE set it now says "Restart HTTP services succeeded." - so it looks like for renewals, it's really worth editing the certificate description in DSM and then setting that as the value for SYNO_CERTIFICATE - it gives you a completely "hands off" solution, perfect! |
|
Hi sounds2k,
Thanks |
|
Thanks Neil, I think I’ve removed those entries. I’m away at present, so will review the remainder later. But that user account is already disabled, I now utilise the “ SYNO_USE_TEMP_ADMIN=1” option instead, which has also addressed this issue, so I’ve removed the SYNO_USERNAME and SYNO_PASSWORD values. |
|
OK, re-run the upgrade command - running it with -v confirms it's now on v3.1.7. Re-ran the renewal command with --force and it completed fine - thanks :-) |
OK, think I've got it sussed. Had to re-update the value for SYNO_PASSWORD - enclosing it in single quotes rather than speech marks. I did SYNO_USERNAME as well, for good measure. The updated certificate is now deployed to DSM, albeit the old one was still there too. I then cleared the "SYNO_CREATE=1" value and set "SYNO_CERTIFICATE" to the description of the current one, then tried again - this time it replaced the certificate - perfect. I noted that with SYNO_CREATE=1, the penultimate output is "Restart HTTP services failed.", whereas with SYNO_CERTIFICATE set it now says "Restart HTTP services succeeded." - so it looks like for renewals, it's really worth editing the certificate descri…