I'm having trouble with one particular domain

RobertPHeller · August 14, 2024, 1:23pm

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:
rt.deepsoft.com
I ran this command:
sudo certbot -v run -d rt.deepsoft.com

It produced this output:
Originally:
Detail: 108.161.129.198: Invalid response from Login "\n\n\n<html lang="en">\n \n Login\n <meta http-equiv="X-UA-Compatible" content="IE=edge" />"
Now:
AttributeError: can't set attribute

My web server is (include version):
apache2 2.4.61-1~deb12u1
The operating system my web server runs on is (include version):
Debian 12.6
My hosting provider, if applicable, is:
N/A
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):
certbot 2.1.0

I have a whole slew of other domains with certs -- all worked properly. It is just this one that is having trouble.

linkp · August 14, 2024, 1:32pm

Welcome to the Let's Encrypt Community.

The output you shared looks like you are redirecting the ACME challenge to a login page. I can't reproduce it using Let's Debug. You may need to increase your Apache logging details of your aren't seeing anything helpful in your Apache logs.

https://letsdebug.net/rt.deepsoft.com

MikeMcQ · August 14, 2024, 1:39pm

I can The overall result is OK but the Verbose output shows the faulty redirect: Let's Debug

I also see it from my own test server. @RobertPHeller you need to find out where you do that redirect and stop doing it for inbound HTTP Challenge requests. If not possible, switch to a DNS Challenge.

curl -i http://rt.deepsoft.com/.well-known/acme-challenge/Test404
HTTP/1.1 302 Found
Server: Apache/2.4.61 (Debian)
Location: http://rt.deepsoft.com/NoAuth/Login.html?next=5c70775e4d91698270b17b33f1b34e9e

One odd thing is your error showed a URL starting with HTTPS. But, I did not get redirected to HTTPS just the original HTTP. Still, getting redirected to that NoAuth URI causes failure of the challenge.

RobertPHeller · August 14, 2024, 1:48pm

I restored the cert from my old server (CentOS 7, snap certbot 2.10.0), so it is now on the old cert (which works, but will expire in 19 days). When I attempt to renew it I get:

sharky5% sudo certbot -v renew --cert-name rt.deepsoft.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/rt.deepsoft.com.conf

Attempting to parse the version 2.10.0 renewal configuration file found at /etc/letsencrypt/renewal/rt.deepsoft.com.conf with version 2.1.0 of Certbot. This might not work.
Certificate is due for renewal, auto-renewing...
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate for rt.deepsoft.com
Performing the following challenges:
http-01 challenge for rt.deepsoft.com
Waiting for verification...
Challenge failed for domain rt.deepsoft.com
http-01 challenge for rt.deepsoft.com

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: rt.deepsoft.com
Type: unauthorized
Detail: 108.161.129.198: Invalid response from Login "\n\n\n<html lang="en">\n \n Login\n <meta http-equiv="X-UA-Compatible" content="IE=edge" />"

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Cleaning up challenges
Failed to renew certificate rt.deepsoft.com with error: Some challenges have failed.

All renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/rt.deepsoft.com/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
sharky5%

linkp · August 14, 2024, 1:50pm

You should not expect any different results until you exempt the /.well-known/acme-challenge path from your forced login redirect rule.

MikeMcQ · August 14, 2024, 1:53pm

Exactly what @linkp said.

I see a slightly different result now in that HTTP request first gets redirected to HTTPS and then the faulty redirect to the NoAuth login page. This matches your first and second error messages

curl -i http://rt.deepsoft.com/.well-known/acme-challenge/Test404
HTTP/1.1 301 Moved Permanently
Server: Apache/2.4.61 (Debian)
Location: https://rt.deepsoft.com/.well-known/acme-challenge/Test404

# Following that redirect gets redirected to NoAuth
curl -i https://rt.deepsoft.com/.well-known/acme-challenge/Test404
HTTP/1.1 302 Found
Server: Apache/2.4.61 (Debian)
Location: https://rt.deepsoft.com/NoAuth/Login.html?next=d887252188fba809b20f7bcdabc3185c

RobertPHeller · August 14, 2024, 2:01pm

It is something RT is doing. Here is the Apache2 conf file:
sharky5% less -X /etc/apache2/sites-available/rt4.conf

<VirtualHost *:80>
        ServerName rt.deepsoft.com
        ServerAlias rt2.deepsoft.com
        ### Optional apache logs for RT
        ErrorLog /opt/rt4/var/log/apache2.error
        TransferLog /opt/rt4/var/log/apache2.access
        LogLevel debug

        AddDefaultCharset UTF-8

        DocumentRoot "/opt/rt4/share/html"
        <Location />
            Require all granted

            SetHandler modperl
            PerlResponseHandler Plack::Handler::Apache2
            PerlSetVar psgi_app /opt/rt4/sbin/rt-server
        </Location>
        <Perl>
            use Plack::Handler::Apache2;
            Plack::Handler::Apache2->preload("/opt/rt4/sbin/rt-server");
        </Perl>
RewriteEngine on
RewriteCond %{SERVER_NAME} =rt.deepsoft.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [L,NE,R=permanent]
</VirtualHost>

RobertPHeller · August 14, 2024, 2:08pm

So is certbot expecting a 404 result? Or something else? RT seems to want to do a login, then will give a 404 after that.

MikeMcQ · August 14, 2024, 2:16pm

Yes, in my test a 404 is expected. The problem is your redirect to a login page.

An HTTP Challenge is prepared by Certbot (an ACME Client). But, a Let's Encrypt ACME Server sends the HTTP request to your server. It expects to be returned the challenge token created by Certbot on your system.

Redirects are allowed but the result of following them must still be that you send back the challenge token. You are sending a login page.

I'm not sure what "RT" is all about but you should not redirect to a login page for any inbound URI that starts with /.well-known/acme-challenge

In fact, would be best to not even redirect that to HTTPS and reply from the port 80 VHost

RobertPHeller · August 14, 2024, 2:21pm

Does certbot want to create the directory and files in the DocumentRoot? Maybe it needs the right permissions?

MikeMcQ · August 14, 2024, 2:32pm

It depends which option you used. The --apache and --webroot do different things but you didn't show which. But, no, file system permissions are not involved with this issue.

The --apache option might work-around your login page redirect problem but I am not sure it will parse your perl stuff properly. As a test try

sudo certbot certonly --apache --dry-run -d rt.deepsoft.com

If you were using --webroot you need to add appropriate location block for the HTTP Challenge URI as I noted.

RobertPHeller · August 14, 2024, 2:41pm

Same error. I think it was defaulting to --apache. Should I try --webroot?

linkp · August 14, 2024, 2:49pm

It won't hurt to try webroot, but again, until you exempt the ACME challenge from the forced login redirect, no HTTP-01 challenge is going to succeed.

RobertPHeller · August 14, 2024, 2:55pm

OK, I added:

        <Location /.well-known/acme-challenge/>                                                                                                                                
            SetHandler send-as-is                                                                                                                                              
            Options -Indexes                                                                                                                                                   
        </location>

to the conf files and the dry-run succeded!

linkp · August 14, 2024, 3:10pm

I'm glad that worked. The use of SetHandler send-as-is is an approach that I have never seen.

MikeMcQ · August 14, 2024, 3:12pm

Looks like you already tried it without --dry-run as I see your domain is using a cert created about 10 minutes ago.

Is there anything else you need help with?

RobertPHeller · August 14, 2024, 3:17pm

Yes, it is all good now.

system · September 13, 2024, 3:18pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
AttributeError: can't set attribute Help	9	481	April 18, 2024
Certbot issual failure Help	6	573	October 21, 2023
Certbot failed to authenticate some domains (authenticator: apache) Help	13	1087	December 21, 2022
Certbot failed to authenticate some domains (authenticator: apache) Help	3	205	June 2, 2024
Raise errors.AuthorizationError('Some challenges have failed.') Help	14	3294	June 23, 2022

I'm having trouble with one particular domain

Related topics