Getting too many redirects

Help
1

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: labtop.com

I ran this command:www.labtop.com

It produced this output: www.labtop.com redirected you too many times.

My web server is (include version):apache 3.4.6
The operating system my web server runs on is (include version):centos 7

My hosting provider, if applicable, is:network solutions

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 1.11.0

Previously I had my webpage set to earth.labtop.com but found it was causing issues with clients going to www.labtop.com. I set network solutions domain settings to use cname and A records for www.labtop.com and deleting the earth.labtop certs and recreated them for www.labtop.com. Unfortunately I'm not sure what went wrong but it just comes back with too many redirects. I ran the onsite debug test and it came back with:

BadRedirect

Error

Sending an ACME HTTP validation request to www.labtop.com results in an unacceptable redirect. This is most likely a misconfiguration of your web server or your web application.

It appears that a redirect was generated by your web server that is missing a trailing slash after your domain name: https://www.labtop.com.well-known/acme-challenge/letsdebug-test. Check your web server configuration and .htaccess for Redirect/RedirectMatch/RewriteRule.

Trace:
@0ms: Making a request to http://www.labtop.com/.well-known/acme-challenge/letsdebug-test (using initial IP 174.1.56.247)
@0ms: Dialing 174.1.56.247
@364ms: Server response: HTTP 301 Moved Permanently
@364ms: Received redirect to https://www.labtop.com/.well-known/acme-challenge/letsdebug-test
@365ms: Dialing 174.1.56.247
@1163ms: Server response: HTTP 302 Found
@1163ms: Received redirect to https://www.labtop.com.well-known/acme-challenge/letsdebug-test

IssueFromLetsEncrypt

Error

A test authorization for www.labtop.com to the Let's Encrypt staging service has revealed issues that may prevent any certificate for this domain being issued.

174.1.56.247: Fetching https://www.labtop.com.well-known/acme-challenge/E_f7ij1Q2sYy7S6-53R7VnUGTt7-6RwE8BR5Dsho1Sc: Invalid host in redirect target "www.labtop.com.well-known". Check webserver config for missing '/' in redirect target.

At this point I'm at a loss as to where I go from here. The exact same web server settings haven't changed only the new certs are active.

Dry-run:

How would you like to authenticate with the ACME CA?

1: Apache Web Server plugin (apache)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)

Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 1
Plugins selected: Authenticator apache, Installer None
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c'
to cancel): labtop.com
Simulating a certificate request for labtop.com
Performing the following challenges:
http-01 challenge for labtop.com
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:

  • The dry run was successful.
    [root@earth conf.d]# certbot certonly --dry-run
    Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?

1: Apache Web Server plugin (apache)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)

Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 1
Plugins selected: Authenticator apache, Installer None
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c'
to cancel): www.labtop.com
Cannot extract OCSP URI from /etc/letsencrypt/archive/www.labtop.com-0001/cert1.pem
Cert not due for renewal, but simulating renewal for dry run
Simulating renewal of an existing certificate for www.labtop.com
Performing the following challenges:
http-01 challenge for www.labtop.com
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:

  • The dry run was successful.

So at this point I'm hoping someone can point me in the right direction.

2

Hello @thund3rbolt, welcome to the Let's Encrypt community. :slightly_smiling_face:

Using curl I get this
HTTP being redirected to HTTPS

$ curl -Ii http://www.labtop.com/.well-known/acme-challenge/sometestfile
HTTP/1.1 301 Moved Permanently
Date: Sun, 07 Dec 2025 20:34:16 GMT
Server: Apache
Location: https://www.labtop.com/.well-known/acme-challenge/sometestfile
Content-Type: text/html; charset=iso-8859-1

HTTPS being redirected to HTTPS but the domain name changed to www.labtop.com.well-known, now what you want likely.

$ curl -k -Ii https://www.labtop.com/.well-known/acme-challenge/sometestfile
HTTP/1.1 302 Found
Date: Sun, 07 Dec 2025 20:34:28 GMT
Server: Apache
Location: https://www.labtop.com.well-known/acme-challenge/sometestfile
Content-Type: text/html; charset=iso-8859-1

And show by you here as well

Following the redirect to www.labtop.com.well-known get an error.

$ curl -k -Ii https://www.labtop.com.well-known/acme-challenge/sometestfile
curl: (6) Could not resolve host: www.labtop.com.well-known

Please show the output of sudo apachectl -t -D DUMP_VHOSTS

Using the online tool Let's Debug yields these results https://letsdebug.net/www.labtop.com/2644456

image
image1325×715 44.6 KB

Using the online tool https://www.redirect-checker.org/ I see

image
image889×1998 135 KB

3 Likes
3

Thank you for helping. This community is so helpful and it's appreciated. I'm not sure I am understanding what I should do next. If it's the apachectl command that's not available:

apachectl -t -D DUMP_VHOSTS
Passing arguments to httpd using apachectl is no longer supported.
You can only start/stop/restart httpd using this script.
If you want to pass extra arguments to httpd, edit the
/etc/sysconfig/httpd config file.

2 Likes
4

I'm not an Apache person.
Kindly wait for more knowledgeable Let's Encrypt community volunteers to assist. :slight_smile:

2 Likes
5

Thanks all the same Bruce. Very nice of you. In the meantime I'll keep trying on my end. :+1:

2 Likes
6

I believe the command on Centos is: sudo httpd -t -D DUMP_VHOSTS

I agree with @Bruce5051 that is looks like an Apache config problem.

The Certbot dry-run tests using the --apache plugin worked because it adds temporary changes to your Apache config to handle the challenge. But, once those are gone "normal" requests to your domain are affected by your faulty Apache config.

Those faulty redirects are either in your VirtualHost config files or perhaps a .htaccess file. You may have to hunt around for stray .htaccess files.

2 Likes
7

Resulting output from httpd -t -D DUMP_VHOSTS
VirtualHost configuration:

*:80 is a NameVirtualHost
default server www.labtop.com (/etc/httpd/conf.d/earthconf.conf:1)
port 80 namevhost www.labtop.com (/etc/httpd/conf.d/earthconf.conf:1)
alias www.labtop.com
port 80 namevhost www.labtop.com (/etc/httpd/conf.d/le-redirect-earth.labtop.com.conf:1)
alias www.labtop.com
*:443 is a NameVirtualHost
default server www.labtop.com (/etc/httpd/conf.d/earthconf-le-ssl.conf:2)
port 443 namevhost www.labtop.com (/etc/httpd/conf.d/earthconf-le-ssl.conf:2)
alias www.labtop.com
port 443 namevhost www.labtop.com (/etc/httpd/conf.d/ssl.conf:54)

8

I did a locate and the only one I could find is in the www folder:

[root@earth www]# cat .htaccess

Block SEMalt botnet

SetEnvIfNoCase Referer fbdownloader.com spammer=yes
SetEnvIfNoCase Referer descargar-musicas-gratis.com spammer=yes
SetEnvIfNoCase Referer baixar-musicas-gratis.com spammer=yes
SetEnvIfNoCase Referer savetubevideo.com spammer=yes
SetEnvIfNoCase Referer srecorder.com spammer=yes
SetEnvIfNoCase Referer kambasoft.com spammer=yes
SetEnvIfNoCase Referer semalt.com spammer=yes

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Order allow,deny
Allow from all
Deny from env=spammer

9

I found this in the httpd.conf file:

AllowOverride none Require all denied

Is this what might be causing the issue?

10

You have two VirtualHost for the same domain and port. Apache does not issue an error but it won't work. The faulty redirect is likely in one of those.

Please show the contents of both of those config files.

Oddly, the cert used for HTTPS requests was issued by the Let's Encrypt staging system so is not valid for production use. A --dry-run test would not cause that. You would have to explicitly request a staging cert and use that in your config. I think the reason will become clear once you show us the two config files.

You have a similar problem for port 80 but let's work on port 443 first.

1 Like
11

[root@earth conf.d]# vi earthconf-le-ssl.conf

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin labtop@gmail.com
    ServerName www.labtop.com
    ServerAlias www.labtop.com
    DocumentRoot /var/www/html
    Redirect / https://www.labtop.com
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/www.labtop.com-0001/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.labtop.com-0001/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.labtop.com-0001/chain.pem
</VirtualHost>
</IfModule>

[root@earth conf.d]# cat ssl.conf

#
# When we also provide SSL we have to listen to the 
# the HTTPS port in addition.

Listen 443 https

##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.

#   Pass Phrase Dialog:
#   Configure the pass phrase gathering process.
#   The filtering dialog program (`builtin' is a internal
#   terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

#   Inter-Process Session Cache:
#   Configure the SSL Session Cache: First the mechanism 
#   to use and second the expiring timeout (in seconds).
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300

#   Pseudo Random Number Generator (PRNG):
#   Configure one or more sources to seed the PRNG of the 
#   SSL library. The seed data should be of good random quality.
#   WARNING! On some platforms /dev/random blocks if not enough entropy
#   is available. This means you then cannot use the /dev/random device
#   because it would lead to very long connection times (as long as
#   it requires to make more entropy available). But usually those
#   platforms additionally provide a /dev/urandom device which doesn't
#   block. So, if available, use this one instead. Read the mod_ssl User
#   Manual for more details.

SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random  512
#SSLRandomSeed connect file:/dev/random  512
#SSLRandomSeed connect file:/dev/urandom 512

# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names.  NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly. 
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec

##
## SSL Virtual Host Context
##

<VirtualHost _default_:443>

# General setup for the virtual host, inherited from global configuration
DocumentRoot "/var/www/html"
ServerName www.labtop.com:443

# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on
#

#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3
#

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
#       SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA

#   Speed-optimized SSL Cipher configuration:
#   If speed is your main concern (on busy HTTPS servers e.g.),
#   you might want to force clients to specific, performance
#   optimized ciphers. In this case, prepend those ciphers
#   to the SSLCipherSuite list, and enable SSLHonorCipherOrder.
#   Caveat: by giving precedence to RC4-SHA and AES128-SHA
#   (as in the example below), most connections will no longer
#   have perfect forward secrecy - if the server's key is
#   compromised, captures of past or future traffic must be
#   considered compromised, too.
#SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
#SSLHonorCipherOrder on 

# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/letsencrypt/live/www.labtop.com/cert.pem

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)

SSLCertificateKeyFile /etc/letsencrypt/live/www.labtop.com/privkey.pem

#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate. Alternatively
#   the referenced file can be the same as SSLCertificateFile
#   when the CA certificates are directly appended to the server
#   certificate for convinience.
SSLCertificateChainFile /etc/letsencrypt/live/www.labtop.com/chain.pem
#

#   Certificate Authority (CA):
#   Set the CA certificate verification path where to find CA
#   certificates for client authentication or alternatively one
#   huge file containing all of them (file must be PEM encoded)
SSLCACertificateFile /etc/letsencrypt/live/www.labtop.com/cert.pem

#   Client Authentication (Type):
#   Client certificate verification type and depth.  Types are
#   none, optional, require and optional_no_ca.  Depth is a
#   number which specifies how deeply to verify the certificate
#   issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth  10

#   Access Control:
#   With SSLRequire you can do per-directory access control based
#   on arbitrary complex boolean expressions containing server
#   variable checks and other lookup directives.  The syntax is a
#   mixture between C and Perl.  See the mod_ssl documentation
#   for more details.
#<Location />
#SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
#            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
#            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
#            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
#            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
#           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>

#   SSL Engine Options:
#   Set various options for the SSL engine.
#   o FakeBasicAuth:
#     Translate the client X.509 into a Basic Authorisation.  This means that
#     the standard Auth/DBMAuth methods can be used for access control.  The
#     user name is the `one line' version of the client's X.509 certificate.
#     Note that no password is obtained from the user. Every entry in the user
#     file needs this password: `xxj31ZMTZzkVA'.
#   o ExportCertData:
#     This exports two additional environment variables: SSL_CLIENT_CERT and
#     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
#     server (always existing) and the client (only existing when client
#     authentication is used). This can be used to import the certificates
#     into CGI scripts.
#   o StdEnvVars:
#     This exports the standard SSL/TLS related `SSL_*' environment variables.
#     Per default this exportation is switched off for performance reasons,
#     because the extraction step is an expensive operation and is usually
#     useless for serving static content. So one usually enables the
#     exportation for CGI and SSI requests only.
#   o StrictRequire:
#     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
#     under a "Satisfy any" situation, i.e. when it applies access is denied
#     and no other module can change it.
#   o OptRenegotiate:
#     This enables optimized SSL connection renegotiation handling when SSL
#     directives are used in per-directory context. 
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
    AllowOverride none
</Directory>

#   SSL Protocol Adjustments:
#   The safe and default but still SSL/TLS standard compliant shutdown
#   approach is that mod_ssl sends the close notify alert but doesn't wait for
#   the close notify alert from client. When you need a different shutdown
#   approach you can use one of the following variables:
#   o ssl-unclean-shutdown:
#     This forces an unclean shutdown when the connection is closed, i.e. no
#     SSL close notify alert is send or allowed to received.  This violates
#     the SSL/TLS standard but is needed for some brain-dead browsers. Use
#     this when you receive I/O errors because of the standard approach where
#     mod_ssl sends the close notify alert.
#   o ssl-accurate-shutdown:
#     This forces an accurate shutdown when the connection is closed, i.e. a
#     SSL close notify alert is send and mod_ssl waits for the close notify
#     alert of the client. This is 100% SSL/TLS standard compliant, but in
#     practice often causes hanging connections with brain-dead browsers. Use
#     this only for browsers where you know that their SSL implementation
#     works correctly. 
#   Notice: Most problems of broken clients are also related to the HTTP
#   keep-alive facility, so you usually additionally want to disable
#   keep-alive for those clients, too. Use variable "nokeepalive" for this.
#   Similarly, one has to force some clients to use HTTP/1.0 to workaround
#   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
#   "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

#   Per-Server Logging:
#   The home of a custom SSL log file. Use this when you want a
#   compact non-error SSL logfile on a virtual host basis.
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>

[root@earth conf.d]#

12

This is the broken config file. And, given your other port 443 VirtualHost file has many default SSL settings you should probably just remove this one.

The line causing the redirect loop is this

Redirect / https://www.labtop.com

You are redirecting every inbound HTTPS request on port 443 to itself. And, that is not the correct format of that redirect anyway. It is missing a trailing slash. Really is better to delete that file altogether :slight_smile:

After you do that and restart Apache rerun that -D DUMP_VHOSTS command from earlier. Make sure only the one port 443 config is active.

Let us know and we can check it out

2 Likes
13

Moved earthconf-le-ssl.conf out of the folder.

[root@earth bak]# systemctl restart httpd
[root@earth bak]# httpd -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80 is a NameVirtualHost
default server www.labtop.com (/etc/httpd/conf.d/earthconf.conf:1)
port 80 namevhost www.labtop.com (/etc/httpd/conf.d/earthconf.conf:1)
alias www.labtop.com
port 80 namevhost www.labtop.com (/etc/httpd/conf.d/le-redirect-earth.labtop.com.conf:1)
alias www.labtop.com
*:443 www.labtop.com (/etc/httpd/conf.d/ssl.conf:54)

14

www.labtop.com is now up and running! I can't thank you enough. :slight_smile: Pure genius. I spend from 4 am till now (11 hrs) trying to solve this.

Thank you sooo much, I hope your Christmas is the best ever friend.

2 Likes
15

Also thank you as well Bruce. You were definitely on the right track and I appreciate that. Have a great Christmas and safe holiday to both of you for your help.

2 Likes
16

You are very welcome. Hope a nice Christmas to you too.

But, there is still some work to do. You need to fix the duplicate VirtualHost configs for port 80.

And, it looks like you have extra Certbot certs that we need to delete. Let's start with that. What does this show

sudo certbot certificates
2 Likes
17

Oh... okay.

[root@earth conf.d]# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cannot extract OCSP URI from /etc/letsencrypt/live/www.labtop.com-0001/cert.pem
Cannot extract OCSP URI from /etc/letsencrypt/live/www.labtop.com/cert.pem

Found the following certs:
Certificate Name: www.labtop.com-0001
Serial Number: 2c6376ec7733fc1393d7719891f3c6546902
Key Type: RSA
Domains: www.labtop.com
Expiry Date: 2026-03-07 18:14:01+00:00 (INVALID: TEST_CERT)
Certificate Path: /etc/letsencrypt/live/www.labtop.com-0001/fullchain.pem
Private Key Path: /etc/letsencrypt/live/www.labtop.com-0001/privkey.pem
Certificate Name: www.labtop.com
Serial Number: 50b65c62334c9e591a9079de6a3f483dafe
Key Type: RSA
Domains: labtop.com www.labtop.com
Expiry Date: 2026-03-07 16:19:17+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/www.labtop.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/www.labtop.com/privkey.pem

[root@earth conf.d]#

18

This step should be easy. You don't need this certificate. There are better ways to test

sudo certbot delete --cert-name www.labtop.com-0001

Once that is done, have you sorted out your duplicate VHosts for port 80? If not, please post those two configs

1 Like
19

Not sure if it's sorted or not but this is the output from those 2 files

[root@earth conf.d]# /etc/httpd/conf.d/earthconf.conf:1
bash: /etc/httpd/conf.d/earthconf.conf:1: No such file or directory

[root@earth conf.d]# cat /etc/httpd/conf.d/earthconf.conf

<VirtualHost *:80>  
    ServerAdmin labtop@gmail.com
    ServerName www.labtop.com
    ServerAlias www.labtop.com
    DocumentRoot /var/www/html
    Redirect / https://www.labtop.com
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.labtop.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

[root@earth conf.d]#
[root@earth conf.d]#
[root@earth conf.d]# cat /etc/httpd/conf.d/le-redirect-earth.labtop.com.conf

<VirtualHost _default_:80>
ServerName www.labtop.com 
ServerAlias www.labtop.com 
ServerSignature Off

RewriteEngine On
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

ErrorLog /var/log/httpd/redirect.error.log
LogLevel warn
</VirtualHost>
20

In that one remove this line

Redirect / https://www.labtop.com

And remove that conf file altogether. I don't see anything useful in it and you can't have two for the same domain and port anyway.

After those changes rerun that -D DUMP_VHOSTS command and show that

1 Like