SSL fails to do HTTP lookup, falls back to DNS and fails

Support
1

Trying to install SSL for an addon domain that uses 3rd party nameservers but has the @ and www record pointing to the server. When doing the request, it fails to resolve the .well-known folder because of a 302 and falls back to DNS and fails becuase the acme record cannot be created since it’s 3rd party nameservers.

There’s nothing in the website’s .htaccess doing a 302 redirect or a SSL redirect. It’s a Wordpress site and has the standard wordpress rewrite and that’s it. What else can I check to ensure HTTP verification works for Addon Domains?

During this process, there isn’t a .well-known folder created that I can even test access to.

DEBUG  : SSL challenge attempt: http (domain.com)
DEBUG  : query response for domain.com (NS: 127.0.0.53): 167.253.62.11
WARNING: Opcenter\Crypto\Letsencrypt\Solvers\Http::reachable(): Request for `/.well-known/acme-challenge/acme-test67f55f8a27d887.56035813' returned HTTP code 302
DEBUG  : SSL challenge attempt: dns (domain.com)
DEBUG  : _acme-challenge.domain.com pdns dirty
DEBUG  : _acme-challenge.domain.com pdns dirty
DEBUG  : Setting DNS TXT record _acme-challenge.domain.com with value LJ6_ML4uTYBw9ijWYo09gHHvjoUiOrhB_Aak8lRLJ8E
DEBUG  : _acme-challenge.domain.com pdns dirty
WARNING: Opcenter\Crypto\Letsencrypt\AcmeDispatcher::solve(): dns challenge failed: Challenge failed (response: {"type":"dns-01","url":"https:\/\/acme-v02.api.letsencrypt.org\/acme\/chall\/1967387106\/502467974267\/tNwk1A","status":"invalid","validated":"2025-04-08T17:40:54Z","error":{"type":"urn:ietf:params:acme:error:unauthorized","detail":"Incorrect TXT record \"saTNT_WCThzONizxNNxLovq3sA8QLjZHIPGT1P5MwK4\" found at _acme-challenge.domain.com","status":403},"token":"UHTcrYcgsajtufQC2FI9Qf9Xk198Dz1e7aAYeteQC28"}).
2

There may be an .htaccess in any ancestor directory up to /var/www within the account’s VFS responsible for a redirect. I just tested with a http => https redirect on a test domain. In this situation the following behavior is observed:

cpcmd -d benchmark.test web:set-ssl benchmark.test 1
# cpcmd -d benchmark.test test:mockup-case
DEBUG  : query response for benchmark.test (NS: 1.0.0.1): NULL
INFO   : 302 redirect encountered to https://benchmark.test/.well-known/acme-challenge/acme-test67f57787aac413.01045367
DEBUG  : Invalid response on HTTP solver: cURL error 35: error:1408F10B:SSL routines:ssl3_get_record:wrong version number (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://benchmark.test/.well-known/acme-challenge/acme-test67f57787aac413.01045367
3

It seems the redirect issue is gone but now it’s a 404.

DEBUG  : SSL challenge attempt: http (domain.com)
DEBUG  : query response for domain.com (NS: 127.0.0.53): 167.253.62.11
DEBUG  : Invalid response on HTTP solver: Client error: `GET http://167.253.62.11/.well-known/acme-challenge/acme-test67f669174f1316.25464005` resulted in a `404 Not Found` response:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found (truncated...)

DEBUG  : SSL challenge attempt: dns (domain.com)

Why is it attempting the server IP?

I was able to work around this by having the customer delegate the _acme_challenge and _acme_challenge.www NS records to my Nameservers. This allows the DNS validation to work but is a bit cumbersome for the average user.

4

It sends a Host: header, which is consistent with how HTTP/1.1 requests work under the hood. HTTP_HOST is inferred from that header, if not the IP.

Given the test script:

<?php print_r($_SERVER);

Both produce the same result:

curl  -H'Host: benchmark.test' http://192.168.0.26/test.php
curl  --resolve benchmark.test:80:192.168.0.26 http://benchmark.test/test.php

I’d be interested to see how this works:

touch /tmp/acme/.well-known/acme-challenge/abc
curl -v --resolve domain.com:80:167.253.62.11 http://domain.com/.well-known/acme-challenge/abc

Your client may need to temporarily remove the NS records as well as flushing local DNS on the server with resolvectl flush-caches to make sure we’re reproducing the original issue appropriately.

5 
[root@p111 ~]# touch /tmp/acme/.well-known/acme-challenge/abc
[root@p111 ~]# curl -v --resolve domain.com:80:167.253.62.11 http://domain.com/.well-known/acme-challenge/abc
* Added domain.com:80:167.253.62.11 to DNS cache
* Hostname domain.com was found in DNS cache
*   Trying 167.253.62.11...
* TCP_NODELAY set
* Connected to domain.com (167.253.62.11) port 80 (#0)
> GET /.well-known/acme-challenge/abc HTTP/1.1
> Host: domain.com
> User-Agent: curl/7.61.1
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Wed, 09 Apr 2025 17:07:55 GMT
< Server: Apache
< Content-Length: 311
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
<p>Additionally, a 302 Found
error was encountered while trying to use an ErrorDocument to handle the request.</p>
</body></html>
* Connection #0 to host domain.com left intact