I'm working on this problem since hours. I read that I should include an A DNS record for a www. part of my domain. I tried it all, even a wildcard. Could you help me? My DNS records are set correctly or did I miss anything?
I ran this command: sudo caddy reverse-proxy --from ripped.link --to 0.0.0.0:9000
It produced this output:
tls.issuance.acme.acme_client challenge failed {"identifier": "ripped.link", "challenge_type": "tls-alpn-01", "status_code": 400, "problem_type": "urn:ietf:params:acme:error:dns", "error": "DNS problem: NXDOMAIN looking up A for ripped.link - check that a DNS record exists for this domain"}
My web server is (include version): caddy
The operating system my web server runs on is (include version): ubuntu 20.04
My hosting provider, if applicable, is: AWS Route 53
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): dunno sorry
ICANN whois lookup shows it registered via Gandi and even lists AWS nameservers. But yeah, it's weird that the TLD's nameservers aren't returning any NS records for it. That's the root of the problem.
You might want to open a ticket with Gandi and ask them what's going on assuming you're the registered owner, @raphaellueckl.
In any case: there's nothing "misleading" about the error: that's just what the Let's Encrypt validation servers DNS resolver sees.. And also the rest of the world.
Yeah the domain is registered by me. Weird enough that let's encrypt worked for me with other domains (but not with caddy, just with the certbot standalone).
Were the other domains you've used (that work) also .link or were they other TLDs? You can look at AWS's documentation on supported TLDs and see that .link is done through Gandi.
But in any event, AWS isn't currently giving you the product you've bought, as you've registered the name but the .link DNS servers don't know about it. You need to contact AWS Support and get them to fix it.
I had to update my personal data associated with this domain. The error I get now is a different. Bad gateway?! Not sure why that one happens. Any ideas?
2021/08/03 11:56:05.503 INFO tls.issuance.acme.acme_client trying to solve challenge {"identifier": "ripped.link", "challenge_type": "tls-alpn-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
2021/08/03 11:56:06.100 ERROR tls.issuance.acme.acme_client challenge failed {"identifier": "ripped.link", "challenge_type": "tls-alpn-01", "status_code": 400, "problem_type": "urn:ietf:params:acme:error:connection", "error": "Connection refused"}
2021/08/03 11:56:06.100 ERROR tls.issuance.acme.acme_client validating authorization {"identifier": "ripped.link", "error": "authorization failed: HTTP 400 urn:ietf:params:acme:error:connection - Connection refused", "order": "https://acme-v02.api.letsencrypt.org/acme/order/130671497/14228132870", "attempt": 1, "max_attempts": 3}
2021/08/03 11:56:07.480 INFO tls.issuance.acme.acme_client trying to solve challenge {"identifier": "ripped.link", "challenge_type": "http-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
2021/08/03 11:56:08.195 ERROR tls.issuance.acme.acme_client challenge failed {"identifier": "ripped.link", "challenge_type": "http-01", "status_code": 400, "problem_type": "urn:ietf:params:acme:error:connection", "error": "Fetching http://ripped.link/.well-known/acme-challenge/Qr4DKMU30cW34iRsoSgUrdDYga21tZhlEg1KvlqMdlw: Connection refused"}
2021/08/03 11:56:08.195 ERROR tls.issuance.acme.acme_client validating authorization {"identifier": "ripped.link", "error": "authorization failed: HTTP 400 urn:ietf:params:acme:error:connection - Fetching http://ripped.link/.well-known/acme-challenge/Qr4DKMU30cW34iRsoSgUrdDYga21tZhlEg1KvlqMdlw: Connection refused", "order": "https://acme-v02.api.letsencrypt.org/acme/order/130671497/14228138870", "attempt": 2, "max_attempts": 3}
2021/08/03 11:56:09.809 ERROR tls.obtain could not get certificate from issuer {"identifier": "ripped.link", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "[ripped.link] solving challenges: ripped.link: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[http-01 dns-01 tls-alpn-01] remaining=[dns-01]) (order=https://acme-v02.api.letsencrypt.org/acme/order/130671497/14228145490) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
2021/08/03 11:56:09.810 WARN tls.issuance.zerossl missing email address for ZeroSSL; it is strongly recommended to set one for next time
2021/08/03 11:56:10.663 INFO tls.issuance.zerossl generated EAB credentials {"key_id": "eZK6ek1WJEBicrZahdEOVQ"}
2021/08/03 11:56:10.871 ERROR tls.obtain could not get certificate from issuer {"identifier": "ripped.link", "issuer": "acme.zerossl.com-v2-DV90", "error": "provisioning client: HTTP 504: <html>\r\n<head><title>504 Gateway Time-out</title></head>\r\n<body>\r\n<center><h1>504 Gateway Time-out</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n"}
2021/08/03 11:56:10.871 ERROR tls.obtain will retry {"error": "[ripped.link] Obtain: provisioning client: HTTP 504: <html>\r\n<head><title>504 Gateway Time-out</title></head>\r\n<body>\r\n<center><h1>504 Gateway Time-out</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n", "attempt": 1, "retrying_in": 60, "elapsed": 6.55863172, "max_duration": 2592000}
The "BAD GATEWAY" seems to be generated when the ACME client tries to obtain a cert from ZeroSSL. 2021/08/03 11:56:10.871 ERROR tls.obtain could not get certificate from issuer {"identifier": "ripped.link", "issuer": "acme.zerossl.com-v2-DV90", "error": "provisioning client: HTTP 504: <html>\r\n<head><title>504 Gateway Time-out</title></head>\r\n<body>\r\n<center><h1>504 Gateway Time-out</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n"}
Unfortunately this forum doesn't support that CA.
As for the preceding (seemingly related) errors:
They all show "Connection refused".
Not being familiar with that client and those error messages, I am unclear if that is occuring when the client is trying to reach the CA or while the CA is trying to reach the FQDN to validate.
So... let's try and see which one is failing.
Please show the output of these commands: curl -v https://acme-v02.api.letsencrypt.org/directory curl -4 ifconfig.co
For some reason, Caddy attempts ZeroSSL as wel as Let's Encrypt as CA..? What kind of strange behaviour is that?
In any case, the two challenges attempted by the Let's Encrypt ACME validation servers both return a "Connection refused" error: your hostname needs to be available on port 80 or 443 (depending on the challenge used) to the world wide web.
ZeroSSL has no staging/test server equivalent as far as I know. I think some of these clients that now default to ZeroSSL still have some code that tries to use a staging server for test validations before moving to production.
Caddy is also owned by apilayer and afaik, has had this behaviour for quite some time now. It first tries Let's Encrypt and if that fails, it falls back to ZeroSSL.
