For the renewal with ZeroSSL you can always use the same command as for the initial issuance, with just one additional parameter --renew X (where X is the amount of days left before certificate expiration, when a renewal attempt should be made).
Since wildcards require DNS verification, neither --path nor --unlink parameters should be there, but --handle-as dns should.
But I would prefer if the renewal did NOT require any more --handle-as dns as that makes it impossible to run as scheduled task.
If it could use --crt instead it would be much more logical and easier
–crt points to already once created (and dns validated) wildcard certificate, there should be no need validate it again (as we doing it still withing that certificate validity period)
I’m not sure I understood what you were saying correctly, but renewal of a wildcard certificate always requires a new DNS validation, including posting new TXT records in the DNS zone. This is a requirement from the certificate authority side.
Some clients and some DNS providers support an API to perform DNS updates in order to do unattended renewals this way. For example acme.sh and Certbot now support a number of these APIs. I'm not sure if any Windows-specific client yet does.
Do they let you create CNAME records? You can CNAME _acme-challenge to a resource on another nameserver that does have an API, and the CA validator will follow the CNAME when checking the challenge.
Perl version of the client (which also works fine under Windows) can be extended rather easily to support some custom actions required for verification. That requires some programming knowledge though, but you can also resort to just executing an external command (as also referenced in the integration guide).
If your current DNS provider does not offer any API, you could in theory still set up some sort of automation (using some sort of headless browser or even the macro recorder to replay repetitive tasks), but of course just moving to another (more flexible) DNS hosting would be a better solution indeed.
Actually the certificate is checked. The client is intended to be set up in a way that it can run daily but only attempt to renew when it is X (or fewer) days left until the expiration of the certificate. The certificate expiration is checked in two ways - either by looking at the local certificate file (if it is present) or by connecting (via HTTPS) to a domain the certificate is issued for and checking for the expiration that way.
But not for wildcard certificate (as stated above - a wildcard certificate always requires a new DNS validation, including posting new TXT records in the DNS zone )
In which case no certificate is checked, as there is no domain specified to connect to, unless --crt is specified on command line?
Checked by client due to --crt switch?
Because surely not online, as there is nothing in command line to point it to any domain that would have this certificate