An error when try to get a certificate with webroot plugin


I was following the next tutorial to integrate collabora with nextcloud in Ubuntu.

Everything went well, until I reach “Set up Nginx Virtual Host” section, where the last command (“sudo letsencrypt certonly --webroot --email…”), gives me the next errors:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Using the webroot path /usr/share/nginx/office for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>404 Not Found</title>
<h1>Not Found</h1>

 - The following errors were reported by the server:

   Type:   unauthorized
   Detail: Invalid response from
   <title>404 Not Found</title>
   <h1>Not Found</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.

I try with letsencrypt and certbot, and the error is the same in both cases. My email is already in use in anohter server. This is going to be the second server where we are going to use the same domain and the same email.

I have to autheticate the client? In the other server I have no problems to create the certificates. And I don’t know why in this second server fails that command. In the documentation, it says thart I can use my email more than once.

I’m a little lost, any help is welcome thank you.


Hi @nmarmon,

Are you sure that the webroot path /usr/share/nginx/office is correct? If you put text files into this directory yourself, are they then visible on your web site?

I think before solving this, we have to solve what I indicated in this link The certificate is only valid for "" on all certificates, because I think it is related

Sorry for the delay, I’ve been busy.

I think I have not explained myself well and that my scenario prevents me from doing this test.

I have a reverse proxy with Nginx which redirects the corresponding container by domain. Both the Nginx and the containers are created on Proxmox and LXC containers with Debian 9.

In the proxy I have certbot installed and created several certificates with a domain for each service. So I need two equal certificates for each service, one for the proxy and one for the container where each service is.

I do not know if this is what is called “certificate duplication” in the certbot documentation, or not, but I am having the error indicated in the first message when I try to create the certificate.

I think that the problem may be one of the following options:

1- That what I am trying to do can not be done, because the certificate is already created and what I have to do is duplicate.
2 - I have to authenticate the new installation of certbot as I should have done in the container with Nginx, which is a reverse proxy.

If I create a certificate in this way from the reverse proxy if it works, then if it is not one of these two options or another that you can indicate I am lost.

I would greatly appreciate your help.

PD: The proxy redirects the requests from port 80 to port 443, so I do not know how you could do the test you comment @schoen, but explaining my scenario, you can see what problem I have, if I could not change it and do the test if you think it is essential to look for the error.

Greetings and thank you,

Hi @nmarmon,

I still didn’t fully understand what you’re describing, but I don’t think the certificate duplication is related in any way. The error that you saw is a failed authorization, which is completely independent of what other certificates have already been issued.

Certificate duplication in Certbot’s sense is about certificates covering the same names in the same operating system image, which is not prohibited either by the CA or by Certbot, but is usually not what a user intended to do because there is essentially no benefit to it. I don’t think this is related to your situation.

What protocols are involved here? On which TCP ports on each end?

In the case of having a service behind a proxy, for domain (for example), do I need a certificate in the proxy and another in the backend (server) with the same domain?. If I’m not wrong about something.

If I’m confused … how it will be done? And why do I get an error when creating the same certificate in the server but not in the proxy?


Depending on the protocol used between the proxy and the backend, you don’t necessarily need any certificate on the backend. Even if you do use HTTPS or another TLS-based protocol between the proxy and the backend, you don’t necessarily need a publicly-trusted certificate for that connection (a self-signed certificate would be acceptable), because it would be possible to tell the proxy that the backend’s certificate is correct.

Only the proxy absolutely needs a publicly-trusted certificate, because it’s the device that’s terminating the TLS connections from the outside world (from the general public).

Ok, I’ve been thinking about that idea, but maybe in the future the proxy and VMs can be in different points (LANs) and go abroad. Although at the moment it’s not my scenario.

For some reason, I have managed to create two equal certificates with another domain, both in the proxy and in the backend, which in this case instead of being an LXC is my own Linux Mint machine. I have to analyze why it happens to me with the real environment.

On the other hand, I can implement what you say. I already had it in mind, but I wanted to understand why I had the error. To do that, I’ve seen it in Apache but not in Nginx.

These are the directives that I have to replace in Nginx:

Container uses a unique non-signed certificate

SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off

I’m wrong?

In conclusion, I will look for these directives in Nginx and to prove it like this. And I will also try to understand why the front (proxy) and back pairs for the “collaborate” domain fail me when creating the same certificate in the backend and why now with a “docs” test I have been able to do it. If you have any ideas, it will be welcome.

Thank you very much for everything, I will tell you …

That’s a very good thing to be conscious of. :slight_smile:

I don’t really have any intuition about why your process is failing. If you can provide some log files associated with the failure and what inbound connections have occurred, it might be clearer to me or to someone else.

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