It's not exactly what I had expected because I am having to add the dns challenge back to my zones during the verification. What is odd is that if you remove the challenge from your dns as you SHOULD after getting your certs and rerun the the acme.sh script against it, you can get new certs... but at some point it seems to self expire and that verification stops working. I thought that my syntax was wrong so I added the --renew option when running my renewal process in my script. It still required that I add the new challenge which surprised me this morning. Next time, I am just going to uncomment the current challenge in my dns zones and push it out before running the renewal to see if that would work??? The other thing I need to look into is how zmcertmgr is cleaning up. It does its own backup so my extra step of doing a backup is redundant, etc.
Anyone else have any experiences with this DNS method on renewal? I still like it for it simplicity versus the certbot but need to change to a more automatic method now that I trust these letsencrypt certs and the verification process. Initially, I wanted this to be manual until I built some operational experience so I might be looking at the web version of the letscrypt acme protocol if I can't get around this DNS verification step. In my speed to deploy, I took a fairly quick read of the acme.sh code but need to take a deeper look before my next renewal in case I am missing something obvious here.
UPDATED Jan 30, 2017: I asked the author of acme.sh and he said that currently, if you renew within 59 days, there would not be a re-authorization but expect that to go lower from LetsEncrypt. That explains why it seemed to work and then not later on and force me through another challenge. It is in reference to this: https://community.letsencrypt.org/t/upc ... nges/17947. Since my original post, the code has begun to change to reflect this also. ... Given this, you have 2 options:
- 1. renew more frequently
2. use something like the webroot method with nginx and acme.sh