Let's Encrypt doesn't keep track of previous redirects. You can either use the HTTP or HTTPs version for validation.
Your error highlights a different problem
DNS problem: query timed out looking up CAA for [somedomain.com]
The validation system was not able to complete a DNS lookup of the domain. It may be possible that the DNS provider you are using had some problem, or that the route between Let's Encrypt servers and your server had some network issue.
This is a similar problem, described on the official LE community forum.
I think the problem is on the DN look-up step. There is no CAA record. Somehow it took very long time for domain name server to respond. Here are some results Osiris sent to me. He mentioned that getting ip is fast, but 'one but last step is often quite slow'. Slowness could be the reason for failing at CAA checking step.
and
Based on the original error and those times, it's very likely there are some problems with the DNS servers you're using or the route to them from Let's Encrypt's data center, and it's causing timeouts.
Investigate your DNS settings, and if the lookup is successful retry to submit the certificate request after some time.
Currently it is possible to perform DNS validation, also with the certbot LetsEncrypt client in manual mode. Automation is possible as well (see below).
Manual plugin
You can either perform a manual verification - with the manual plugin.
certbot -d bristol3.pki.enigmabridge.com --manual --preferred-challenges dns certonly
Certbot will then provide you instructions to manually update a TXT record for the domain in order to proceed with the validation.
Please deploy a DNS TXT record under the name
_acme-challenge.bristol3.pki.enigmabridge.com with the following value:
667drNmQL3vX6bu8YZlgy0wKNBlCny8yrjF1lSaUndc
Once this is deployed,
Press ENTER to continue
Once you have updated the DNS record, press Enter, certbot will continue and if the LetsEncrypt CA verifies the challenge, the certificate is issued as normally.
You may also use a command with more options to minimize interactivity and answering certbot questions. Note that the manual plugin does not yet support non-interactive mode.
certbot --text --agree-tos --email you@example.com -d bristol3.pki.enigmabridge.com --manual --preferred-challenges dns --expand --renew-by-default --manual-public-ip-logging-ok certonly
Renewal does not work with the manual plugin as it runs in non-interactive mode. More info in the official certbot documentation.
Update: manual hooks
In the new certbot version you can use hooks, e.g., --manual-auth-hook, --manual-cleanup-hook. The hooks are external scripts executed by certbot to perform the task.
Information is passed in environment variables - e.g., domain to validate, challenge token. Vars: CERTBOT_DOMAIN, CERTBOT_VALIDATION, CERTBOT_TOKEN.
certbot certonly --manual --preferred-challenges=dns --manual-auth-hook /path/to/dns/authenticator.sh --manual-cleanup-hook /path/to/dns/cleanup.sh -d secure.example.com
You can write your own handler or use already existing ones. There are many available, e.g., for Cloudflare DNS.
More info on official certbot hooks documentation.
Automation, Renewal, Scripting
If you would like to automate DNS challenge validation it is not currently possible with vanilla certbot. Update: some automation is possible with the certbot hooks.
We thus created a simple plugin that supports scripting with DNS automation. It's available as certbot-external-auth.
pip install certbot-external-auth
It supports the DNS, HTTP, TLS-SNI validation methods. You can either use it in handler mode or in JSON output mode.
Handler mode
In handler mode, the certbot + plugin calls external hooks (a program, shell script, Python, ...) to perform the validation and installation. In practice you write a simple handler/shell script which gets the input arguments - domain, token and makes the change in DNS. When the handler finishes, certbot proceeds with validation as usual.
This gives you extra flexibility, renewal is also possible.
Handler mode is also compatible with Dehydrated DNS hooks (former letsencrypt.sh). There are already many DNS hooks for common providers (e.g., CloudFlare, GoDaddy, AWS). In the repository there is a README with extensive examples and example handlers.
Example with Dehydrated DNS hook:
certbot \
--text --agree-tos --email you@example.com \
--expand --renew-by-default \
--configurator certbot-external-auth:out \
--certbot-external-auth:out-public-ip-logging-ok \
-d "bristol3.pki.enigmabridge.com" \
--preferred-challenges dns \
--certbot-external-auth:out-handler ./dehydrated-example.sh \
--certbot-external-auth:out-dehydrated-dns \
run
JSON mode
Another plugin mode is JSON mode. It produces one JSON object per line. This enables a more complicated integration - e.g., when Ansible or some deployment manager is calling certbot. Communication is performed via STDOUT and STDIN. Cerbot produces JSON objects with data to perform the validation, for example:
certbot \
--text --agree-tos --email you@example.com \
--expand --renew-by-default \
--configurator certbot-external-auth:out \
--certbot-external-auth:out-public-ip-logging-ok \
-d "bristol3.pki.enigmabridge.com" \
--preferred-challenges dns \
certonly 2>/dev/null
{"cmd": "perform_challenge", "type": "dns-01", "domain": "bs3.pki.enigmabridge.com", "token": "3gJ87yANDpmuuKVL2ktfQ0_qURQ3mN0IfqgbTU_AGS4", "validation": "ejEDZXYEeYHUxqBAiX4csh8GKkeVX7utK6BBOBshZ1Y", "txt_domain": "_acme-challenge.bs3.pki.enigmabridge.com", "key_auth": "3gJ87yANDpmuuKVL2ktfQ0_qURQ3mN0IfqgbTU_AGS4.tRQM98JsABZRm5-NiotcgD212RAUPPbyeDP30Ob_7-0"}
Once DNS is updated, the caller sends the new-line character to STDIN of certbot to signal it can continue with validation.
This enables automation and certificate management from the central management server. For installation you can deploy certificates over SSH.
For more info please refer to the readme and examples on certbot-external-auth GitHub.
EDIT: There is also a new blog post describing the DNS validation problem and the plugin usage.
EDIT: We currently work on Ansible 2-step validation, will be soon off.
Best Answer
The problem
You don't own the domain name
mynas.local, so of course Let's Encrypt won't sign a certificate saying that you own that domain. If they signed such certificates, browsers would very soon stop trusting Let's Encrypt.Instead what you need to do is to use your own domain name to access the NAS regardless of where you access it from. This is not only because of the certificate, it is also because it is more convenient if you have any mobile devices which need to access the NAS both from inside your LAN and from outside.
It sounds like you have a NAT on your network which is getting in the way of just pointing your domain name at the IP of your NAS. If you did not use NAT, this would just work.
The solution
The ideal solution is to use a network without NAT. You can still have a firewall blocking connections from the outside to everything but the HTTPS port on the NAS, if you want to.
It is unlikely that your ISP would give you enough IPv4 addresses for such a setup, so if you wanted to do it that way, you would have to do it with IPv6.
You can configure your LAN such that IPv4 is NATed by your gateway and IPv6 is routed without NAT. For the name you have chosen for your NAS you can then create both an A record pointing to your NAT and an AAAA record pointing to the NAS.
Clients on your LAN will then have an IPv6 path directly to the NAS and should prefer using the AAAA record. Using the IPv4 address would involve hairpin NAT, but that would only be used as fallback in case the IPv6 connection fails. Given that client and NAS would be just one hop from each other with no router between them, it should be rare that the IPv6 connectivity fails.
Clients from outside your LAN will use IPv4 or IPv6 depending on the network they are connected to. If they are on an IPv4-only network they will need to go through the port forwarding on your NAT, which you should leave configured the same way as it is now.
A workaround
If your ISP does not support IPv6 yet, then there isn't a clean solution to your problem. However there are still possible workarounds.
You can configure your own DNS server on the NAT gateway. This DNS server will need to consider itself authoritative for your domain and recurse for everything else. This DNS server will have to hand out local addresses when asked for your domain.
Clients on the LAN will be given a local IP address and connect directly to the NAS. Clients outside your LAN will not be using the DNS server on your NAT gateway, instead they will receive responses from the real authoritative server pointing to your external IP.