Invalid response


#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. https://crt.sh/?q=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: m400cloud.com

I ran this command: in docker/ubuntu 18 server
docker run -it --rm
-v certs1:/etc/letsencrypt
-v certs2:/data/letsencrypt certbot/certbot
certonly --webroot --webroot-path=/data/letsencrypt -d m400cloud.com

It produced this output:
certbot

My web server is (include version): apache2.4(part of nextcloud docker image)

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

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


#2

Hi,

You have a universal redirection that redirects all ‘nit logined’ users / viewers to your login page…

This redirection prevents let’s encrypt validation server from accessing the validation token…

Please try to modify your vHost config and allow .well-known/acme-challenge…

Thank you


#3

Hi @m400

additional: Or share your apache configuration file.


#4
Here is my apache2.conf

root@f61e5a7d2ee6:/etc/apache2# cat apache2.conf
# This is the main Apache server configuration file.  It contains the
# configuration directives that give the server its instructions.
# See http://httpd.apache.org/docs/2.4/ for detailed information about
# the directives and /usr/share/doc/apache2/README.Debian about Debian specific
# hints.
#
#
# Summary of how the Apache 2 configuration works in Debian:
# The Apache 2 web server configuration in Debian is quite different to
# upstream's suggested way to configure the web server. This is because Debian's
# default Apache2 installation attempts to make adding and removing modules,
# virtual hosts, and extra configuration directives as flexible as possible, in
# order to make automating the changes and administering the server as easy as
# possible.

# It is split into several files forming the configuration hierarchy outlined
# below, all located in the /etc/apache2/ directory:
#
#       /etc/apache2/
#       |-- apache2.conf
#       |       `--  ports.conf
#       |-- mods-enabled
#       |       |-- *.load
#       |       `-- *.conf
#       |-- conf-enabled
#       |       `-- *.conf
#       `-- sites-enabled
#               `-- *.conf
#
#
# * apache2.conf is the main configuration file (this file). It puts the pieces
#   together by including all remaining configuration files when starting up the
#   web server.
#
# * ports.conf is always included from the main configuration file. It is
#   supposed to determine listening ports for incoming connections which can be
#   customized anytime.
#
# * Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/
#   directories contain particular configuration snippets which manage modules,
#   global configuration fragments, or virtual host configurations,
#   respectively.
#
#   They are activated by symlinking available configuration files from their
#   respective *-available/ counterparts. These should be managed by using our
#   helpers a2enmod/a2dismod, a2ensite/a2dissite and a2enconf/a2disconf. See
#   their respective man pages for detailed information.
#
# * The binary is called apache2. Due to the use of environment variables, in
#   the default configuration, apache2 needs to be started/stopped with
#   /etc/init.d/apache2 or apache2ctl. Calling /usr/bin/apache2 directly will not
#   work with the default configuration.


# Global configuration
#

#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# NOTE!  If you intend to place this on an NFS (or otherwise network)
# mounted filesystem then please read the Mutex documentation (available
# at <URL:http://httpd.apache.org/docs/2.4/mod/core.html#mutex>);
# you will save yourself a lot of trouble.
#
# Do NOT add a slash at the end of the directory path.
#
#ServerRoot "/etc/apache2"

#
# The accept serialization lock file MUST BE STORED ON A LOCAL DISK.
#
#Mutex file:${APACHE_LOCK_DIR} default

#
# The directory where shm and other runtime files will be stored.
#

DefaultRuntimeDir ${APACHE_RUN_DIR}

#
# PidFile: The file in which the server should record its process
# identification number when it starts.
# This needs to be set in /etc/apache2/envvars
#
PidFile ${APACHE_PID_FILE}

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 5


# These need to be set in /etc/apache2/envvars
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}

#
# HostnameLookups: Log the names of clients or just their IP addresses
# e.g., www.apache.org (on) or 204.62.129.132 (off).
# The default is off because it'd be overall better for the net if people
# had to knowingly turn this feature on, since enabling it means that
# each client request will result in AT LEAST one lookup request to the
# nameserver.
#
HostnameLookups Off

# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a <VirtualHost>
# container, error messages relating to that virtual host will be
# logged here.  If you *do* define an error logfile for a <VirtualHost>
# container, that host's errors will be logged there and not here.
#
ErrorLog ${APACHE_LOG_DIR}/error.log

#
# LogLevel: Control the severity of messages logged to the error_log.
# Available values: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the log level for particular modules, e.g.
# "LogLevel info ssl:warn"
#
LogLevel warn

# Include module configuration:
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf

# Include list of ports to listen on
Include ports.conf


# Sets the default security model of the Apache2 HTTPD server. It does
# not allow access to the root filesystem outside of /usr/share and /var/www.
# The former is used by web applications packaged in Debian,
# the latter may be used for local directories served by the web server. If
# your system is serving content from a sub-directory in /srv you must allow
# access here, or in any related virtual host.
<Directory />
        Options FollowSymLinks
        AllowOverride None
        Require all denied
</Directory>

<Directory /usr/share>
        AllowOverride None
        Require all granted
</Directory>

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

#<Directory /srv/>
#       Options Indexes FollowSymLinks
#       AllowOverride None
#       Require all granted
#</Directory>




# AccessFileName: The name of the file to look for in each directory
# for additional configuration directives.  See also the AllowOverride
# directive.
#
AccessFileName .htaccess

#
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#
<FilesMatch "^\.ht">
        Require all denied
</FilesMatch>


#
# The following directives define some format nicknames for use with
# a CustomLog directive.
#
# These deviate from the Common Log Format definitions in that they use %O
# (the actual bytes sent including headers) instead of %b (the size of the
# requested file), because the latter makes it impossible to detect partial
# requests.
#
# Note that the use of %{X-Forwarded-For}i instead of %h is not recommended.
# Use mod_remoteip instead.
#
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

# Include of directories ignores editors' and dpkg's backup files,
# see README.Debian for details.

# Include generic snippets of statements
IncludeOptional conf-enabled/*.conf

# Include the virtual host configurations:
IncludeOptional sites-enabled/*.conf

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
root@f61e5a7d2ee6:/etc/apache2#

> Preformatted text

#5

Under /etc/apache2/sites-available i have
000-default.conf and default-ssl.conf which one should have the .well-known/acme-challenge… allowed


#6

Hi,

You should add the ‘allow’ under the default.conf for now
(not the default-ssl.conf since you aren’t automatically redirecting to https)

However, after successfully obtained a certificate, you should consider adding the allow to default-ssl.cobf too.

Thank you


#7

should i add ServerName .well-known/acme-challenge ?
not sure how to allow it, heres my 000-default.conf

<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

`# vim: syntax=apache ts=4 sw=4 sts=4 sr noet`

root@f61e5a7d2ee6:/etc/apache2/sites-available#


#8

/.well-known/acme-challenge/ is a directory, not a server name.

As @stevenzhu wrote:

You have a universal redirection

I can’t find such a redirect. Is this managed by your application? You have to stop this redirect, if a user / Letsencrypt loads /.well-known/acme-challenge/.

To test it, create a file 123456789 and save it in /.well-known/acme-challenge/.

Then you should be able to load this file via browser:

http://m400cloud.com/.well-known/acme-challenge/123456789

That must work.


#9

Im using docker and have /var/www/html mapped to /var/lib/docker/volumes/myvolume
created directories and file in myvolume
this url now loads http://m400cloud.com/.well-known/acme-challenge/123456789
Going to try running certbot again. Ty


#10

This works, so this looks good.

But:

Is Certbot able to save the files there? If not, your mapping may be the next problem.


#11
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for m400cloud.com
Using the webroot path /data/letsencrypt for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. m400cloud.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://m400cloud.com/.well-known/acme-challenge/eJybKk7BT2aLqrkCWBAxlnN82oRc0uZSBGx8ZLv_eiU: "<!DOCTYPE html>
<html class="ng-csp" data-placeholder-focus="false" lang="en" >
        <head data-requesttoken="7FFoBpPl9qoM11cQQuVQ4f"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: m400cloud.com
   Type:   unauthorized
   Detail: Invalid response from
   http://m400cloud.com/.well-known/acme-challenge/eJybKk7BT2aLqrkCWBAxlnN82oRc0uZSBGx8ZLv_eiU:
   "<!DOCTYPE html>
   <html class="ng-csp" data-placeholder-focus="false" lang="en" >
           <head data-requesttoken="7FFoBpPl9qoM11cQQuVQ4f"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

#12

I think your right about mapping. I need to map /myvolume/.well-known/acme-challenge/
to certbot /etc/letsencrypt or /data/letsencrypt ?


#13

Simpler: Remove the mapping partial, so that /.well-known/ isn’t mapped.

Certbot finds your “normal root”

and should save the validation file under

/var/www/html/.well-known/acme-challenge/eJybKk7BT2aLqrkCWBAxlnN82oRc0uZSBGx8ZLv_eiU

The name of the file changes.


#14

The /var/www/html is inside the nextcloud container. The certbot container cannot access the /var/www/html path inside the nextcloud container. Containers share data through mapped volumes, I think to do it they way your describing would require installing certbot inside the nextcloud container so that it has direct access to /var/www/html, otherwise it has to be mapped. Or i don’t know how to do what your asking.

I could map myvolume(/var/www/htm) to certbots internal directory /etc/letsencrypt or /data/letsencrypt
What ever is written to /data/letsencrypt would also be written to myvolume(/var/www/htm)

@stevenzhu said to add an allow statement under the virtualhost file, not sure how


#15

Yep, I didn’t see that you use

--webroot --webroot-path=/data/letsencrypt

This is the place where certbot saves the file:

/data/letsencrypt/.well-known/acme-challenge/123456789

So this is your mapping destination.


#16

m400cloud.com/data/letsencrypt/.well-known/acme-challenge/123456789
redirects me to my login page
maybe i need to do this idk
@stevenzhu "add an allow statement under the virtualhost file, not sure how


#17

ty, @JuergenAuer @stevenzhu
heading over to apache forum to ask about “allow statement virtualhost”


#18

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