我有一个运行了Dokku的DigitalOcean小滴。我还有一个AWS Route 53托管区域(该域在其他地方注册,我将名称服务器更改为Route 53)。在该托管区域中,我创建了一个指向我的液滴的A记录。
A记录似乎运行良好(我可以按域从Postman访问我的Dokku容器): image。
我现在正尝试为我的域颁发“让我们加密”证书。我为此使用dokku-letsencrypt。但是,我收到以下错误:
CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/5705758732
Challenge validation has failed, see error log.
错误提供的link包含以下内容:
DNS problem: SERVFAIL looking up A for gmail-bot.bloberenober.dev - the domain's nameservers may be malfunctioning
我对unboundtest.com进行了查询,响应对我来说有点神秘,但这是最后几行:
Jul 06 18:40:21 unbound[5640:0] info: Missing DNSKEY RRset in response to DNSKEY query.
Jul 06 18:40:21 unbound[5640:0] info: Could not establish a chain of trust to keys for bloberenober.dev. DNSKEY IN
Jul 06 18:40:21 unbound[5640:0] info: 127.0.0.1 gmail-bot.bloberenober.dev. A IN SERVFAIL 6.743746 0 44
我做了一些研究,发现DNSKEY记录是DNSSEC的一部分,并且对于现有域,Route 53显然不支持它:
Amazon Route 53支持DNSSEC进行域注册。但是,无论域是否已在Route 53中注册,Route 53都不支持DNSSEC用于DNS服务。如果要为在Route 53中注册的域配置DNSSEC,则必须使用其他DNS服务提供商或进行设置您自己的DNS服务器。
我还尝试过手动运行certbot,并将TXT记录添加到我的托管区域,但是收到类似的错误:
Failed authorization procedure. gmail-bot.bloberenober.dev (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: SERVFAIL looking up TXT for _acme-challenge.gmail-bot.bloberenober.dev - the domain's nameservers may be malfunctioning
有问题的域是 gmail-bot.bloberenober.dev
我在做什么错?在这种情况下,我什至可以颁发“让我们加密”证书吗?
答案 0 :(得分:0)
我通过将DNS服务提供商更改为CloudFlare而不是Route 53来解决了此问题。它们提供了DNSSEC支持和开箱即用的通用SSL证书,足以满足我的需求,因此最终我不需要完全颁发“让我们加密”证书。