When generating a CSR in Windows it seems to create a CSR header that looks like "-----BEGIN NEW CERTIFICATE REQUEST-----", but the addition of "NEW" breaks the parsing of the CSR. Making "NEW " optional fixes the problem.
Apparently certbot is tolerant of both forms, see: https://community.letsencrypt.org/t/error-parsing-certificate-request-resolved/40039/6 for more information.
The support for the base image alpine:3.12 will expire in 4 months (https://endoflife.date/alpine), so it would make sense to upgrade to the current version alpine:3.15.
I was able to create the acme.sh image with the new alpine:3.15 version without errors and also create and deploy a certificate, but further testing would be useful.
+ShellCheck
+ACME v2 compatible
Example:
- Fist create 2 new TXT records on _acme-challenge.example.com
- Now note the ID in (...) from the edit page behind "_acme-challenge.example.com"
export SELFHOSTDNS_USERNAME=myname
export SELFHOSTDNS_PASSWORD=mypass
export SELFHOSTDNS_RID=id_of_txt_record
export SELFHOSTDNS_RID2=id_of_second_txt_record
acme.sh --issue -d example.com --dns dns_selfhost
The support for the base image alpine:3.12 will expire in 4 months (https://endoflife.date/alpine), so it would make sense to upgrade to the current version alpine:3.15.
I was able to create the acme.sh image with the new alpine:3.15 version without errors and also create and deploy a certificate, but further testing would be useful.
When generating a CSR in Windows it seems to create a CSR header that looks like "-----BEGIN NEW CERTIFICATE REQUEST-----", but the addition of "NEW" breaks the parsing of the CSR. Making "NEW " optional fixes the problem.
Apparently certbot is tolerant of both forms, see: https://community.letsencrypt.org/t/error-parsing-certificate-request-resolved/40039/6 for more information.
