How to remove an already non-existent redirect when checking a domain?

Help
1

There is a first domain (social.bet) and a second domain (socialbet.ru). From the second domain there was a 301 redirect to the first domain.

We lost control over the first domain and moved the site a month ago to the second domain. Now no more redirects to the first.

But upon issue of the certificate, letencrypt redirects to the first domain:

socialbet.ru:Verify error:2606:4700:3031::6815:b9c: Invalid response from https://social.bet/.well-known/acme-challenge/r4c8ocmK7kPIS8BtsO3DMeEUlBaJdrRVt2Ulc0BJAlk: 404

There is no redirect when checking for the presence of a check file:

$ curl -I http://socialbet.ru/.well-known/acme-challenge/r4c8ocmK7kPIS8BtsO3DMeEUlBaJdrRVt2Ulc0BJAlk
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 24 Apr 2023 07:19:07 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 87
Last-Modified: Mon, 24 Apr 2023 07:17:55 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "64462d23-57"
Accept-Ranges: bytes

How to solve the problem with the redirect?

We use acme.sh.

2

Hi @zevilz, and welcome to the LE community forum :slight_smile:

Then there is a redirect within your web server configuration.

Notice the IPv6 address in the message.
Is that IP correct?
Is your server responding correctly to HTTP requests via IPv6?

3 Likes
3

Your own webserver is responsible for the redirect(s), Let's Encrypt just follows them.

As Rudy already noted, this might also be due to the IPv6 address being present, those are often overlooked when something changes due to lack of awareness.

Unfortunately you haven't provided your real domain name(s), which actually is mandatory for getting help on the Community, see the questionnaire below which should have been presented to you when you opened this thread in the #help section.. Either something went wrong or you chose to delete it for some reason:

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

4 Likes
4

There are no redirects to old domain.

Virtual host configured for working with ipv4 and ipv6

I don't use ipv6 and don't know :slightly_smiling_face:

Yes

5

I updated first post (domains added).

I use nginx/1.22.1 on Debian 11 without web panels. I use acme.sh, not a certbot.

6

if you don't use ipv6 remove it from dns record

3 Likes
8

Cloudflare adds them.

9

No problems without Cloudflare proxy.

10

I'm not that familiar with Cloudflare, but I thought Cloudflare only redirects from HTTP to HTTPS and not from domain A to domain B?

3 Likes
11

When you disabled Cloudflare proxy you then setup your domain with no AAAA record in your DNS so are not using IPv6.

You probably have something wrong in your IPv6 config in your origin server. But, yes, if you don't use IPv6 it won't be a problem.

4 Likes
12

You can perform redirects to other domains at the Cloudflare edge. It's a pretty common configuration.

5 Likes
13

Good to know, I didn't know that.

4 Likes
14

Isn't this because only talks to origin by https on port 443 and acme client only provides acme response on port 80?

3 Likes
15

Normal traffic between the Cloudflare proxy and the origin server use the same port and protocol as the request from the visitor to the Cloudflare proxy.

This doesn't mean people can't do bad things like turn on Flexible SSL which sends all requests to the origin over HTTP and deceives visitors about the encryption status of their connection. They technically do have an encrypted session to the Cloudflare edge. It just travels from Cloudflare to the webserver in the clear.

One of the most common Cloudflare disruptions of ACME HTTP-01 validation is the Always Use HTTPS setting. I've not done a thorough debugging to determine why it can interfere with ACME HTTP-01 validation. I just know that disabling the HTTP -> HTTPS redirect at the Cloudflare edge mitigates the interference.

The Cloudflare proxy is always available over both IPv4 and IPv6. Both A and AAAA records are published for hostnames that are set to Proxied, even if only one or three other is present in the zone. When a zone has both A and AAAA records, IPv4 is the preferred origin route.

5 Likes
16

With Cloudflare using "Always HTTPS" then the Origin Server needs to handle an ACME Challenge on the port 443 virtual host. This is contrary to what is normally shown in examples.

For example, with nginx using Certbot --webroot we often see a location for it with a unique root just for the ACME challenge. This is fine but with "Always HTTPS" they need to place it in port 443 server block rather than the more commonly used port 80 server block.

Certbot's --nginx plug-in prior to 1.13 only setup the port 80 server block so would fail with "Always HTTPS". Starting 1.13 it adds the temp nginx changes to both 80 and 443 server blocks.

3 Likes
17

Can you explain why Apache using certbot webroot might not work in the Always Use HTTPS environment? That is what I used before moving to Apache mod_md.

I used TLS-ALPN-01 with mod_md after certbot. I created my Community account here when some renewals failed, but I worked it out before I ever posted. Sadly, I don't recall what went wrong, although I am fairly certain that I was able to continue with TLS-ALPN-01.

It is worth mentioning that TLS-ALPN-01 cannot be used with the Cloudflare proxy for what I hope are obvious reasons. In case it is not as obvious for some readers, the TLS connection required to complete the challenge ends up terminated at the Cloudflare proxy instead of the origin host, causing it to fail.

5 Likes
18

First, with your skills mod_md is much better anyway :slight_smile:

As for Apache and "Always HTTPS" with certbot --webroot, it should be fine as long as the --webroot-path matched the DocumentRoot in the HTTPS (port 443) VirtualHost.

I can imagine the "Always HTTPS" would be tricky for a new domain as you would need to setup a VirtualHost with self-signed cert to handle the incoming HTTPS Challenge request from Cloudflare. Without that Apache would serve the HTTPS request from the default VirtualHost which may have a different DocumentRoot.

4 Likes
19

I missed the detail there...
What prefers IPv4?

2 Likes
20

Cloudflare prefers IPv4 from their proxy to the origin server when both are available. When you proxy an A or AAAA record (only one) you will still wind up with both an A and AAAA published. If you want traffic between Cloudflare and your origin to use IPv6, you will want to only enter a AAAA record in the Cloudflare DNS.

5 Likes
21

When Cloudflare connects to the origin server...
Does that use an FQDN or hard set IP address? [pardon my lack of middle-man knowledge]
What if then that FQDN (or IPv6) only resolves to AAAA record?
Wouldn't Cloudflare still publish both [A and AAAA] records for the proxied name [and be required to connect to the origin via IPv6]?

3 Likes