When I try to renew cert, getting 400 Bad Request!

My domain is: orin.app

I ran this command: certbot certonly --manual -d ‘orin.app,*.orin.app’

It produced this output:

root@woden:/etc/apache2/sites-available# certbot certonly --manual -d ‘orin.app,*.orin.app’
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for orin.app

NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you’re running certbot in manual mode on a machine that is not
your server, please ensure you’re okay with that.

Are you OK with your IP being logged?

(Y)es/(N)o: yes

Create a file containing just this data:


And make it available on your web server at this URL:


Press Enter to Continue
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. orin.app (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://orin.app/.well-known/acme-challenge/l-sk9F9exsjmfZvSzdBKBVyTVbBoZqN_ekVwOas_J5g []: “\n\n400 Bad Request\n\n

Bad Request</h1”


  • The following errors were reported by the server:

    Domain: orin.app
    Type: unauthorized
    Detail: Invalid response from
    []: “\n\n400 Bad

    Bad Request</h1”

    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.

My web server is (include version): apache

The operating system my web server runs on is (include version): Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-112-generic x86_64)

My hosting provider, if applicable, is: Digital Ocean

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): nop

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

1 Like

Welcome to the Let’s Encrypt Community :slightly_smiling_face:

Let’s see what we can do for you… :thinking:

Bad Request

Your browser sent a request that this server could not understand.
Reason: You’re speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.

Apache/2.4.29 (Ubuntu) Server at orin.app Port 443

This is what I see at http://orin.app

Please check your webserver error log for more information about this.

@griffin Oeeeehh, it’s sort of the other way around (your error message from Apache says “Port 443”)!

Check this:

osiris@erazer ~ $ curl -LI https://orin.app:80/.well-known/acme-challenge/l-sk9F9exsjmfZvSzdBKBVyTVbBoZqN_ekVwOas_J5g
HTTP/1.1 301 Moved Permanently
Date: Tue, 08 Sep 2020 19:17:00 GMT
Server: Apache/2.4.29 (Ubuntu)
Location: https://orin.app/.well-known/acme-challenge/l-sk9F9exsjmfZvSzdBKBVyTVbBoZqN_ekVwOas_J5g
Content-Type: text/html; charset=iso-8859-1

Notice the scheme (https://) and the port (:80).

It seems @cansonat s server is widely misconfigured.


Yeah shouldn’t that say port 443 not 80 considering HTTPS uses port 443?

1 Like


I figured you’d get a kick out of that. :slightly_smiling_face:

Backwards listen statements, perhaps?



Well, I can’t reproduce @griffin s output because for some reason my Chromium has cached your site as HTTPS and won’t connect to it through HTTP XD

In any case, it’s not important: see my curl output (low-level debugging owns browsers IMO): your Apache is misconfigured: it expects HTTPS on port 80.

1 Like


Where was it moved (301)? As in, what was the redirect to?

I don’t understand, how do you mean? And how is it related to the question/issue at hand?

1 Like

You got a redirect from:


Figured it was worth noting as it gives a hint into the configuration.

Yes, but that redirect is not interesting at all IMO. The problem lies with the HTTPS on port 80. I can force curl to use HTTPS, but the Let’s Encrypt validation server will speak HTTP, no matter what.

1 Like

I thought that the following address would automatically be directed to port 443 since it is https and no port is specified:

Hence the request for https on port 80 is being redirected to https on port 443, which works but shows an input box rather than the challenge file. I just thought this was interesting since port 80 here seems to speak https. That says to me that port 80 is both configured to speak https and is configured to redirect any request to speak https to port 443. :laughing:

“Pardon me sir, but do you speak English?”
“Why, yes, yes I do. Go talk to that guy over there.”

No. It’s not the problem, but it is good comedy.

Thank you so much for your quick reply.
When I check /etc/apache2/ports.conf I see on configuration file this output,

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
        Listen 443

<IfModule mod_gnutls.c>
        Listen 443

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

What should I do in this case?
1 Like


Sorry for not addressing you directly.

Can you run the following, please, and paste the response?

apachectl -S

No no, you’ve got to take one step back! I was forcing the HTTPS scheme on port 80 on my curl command. Something Let’s Encrypt will never do. So Let’s Encrypt will never see that redirect to https:// on port 443!

1 Like


Ah. It worked the same way on my browser though. As in I did get redirected. That is the correct behavior though, to redirect from 80 to 443 when https is requested. What, of course, is not the correct behavior here is https actually being used on port 80 when not requested.

Why did my “welcome post” get flagged? :anguished:

VirtualHost configuration:
*:443 orin.app (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
*:80 orin.app (/etc/apache2/sites-enabled/000-default.conf:4)
ServerRoot: “/etc/apache2”
Main DocumentRoot: “/var/www/html”
Main ErrorLog: “/var/log/apache2/error.log”
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
PidFile: “/var/run/apache2/apache2.pid”
User: name=“www-data” id=33
Group: name=“www-data” id=33

1 Like

And what’s the contents of /etc/apache2/sites-enabled/000-default.conf?

Please put three backticks ("```") on a single line above and below the contents for better readability.

1 Like

I’m off to lunch. Back later.


I’m sure that @Osiris can get you going in minutes. This situation really is a casual stroll for @Osiris to fix.


The input box showing up in the content rather than the challenge file might be another concern.