Help needed for upgrading letsencrypt cert for seafile

Help
1

My domain is:

wolke.sout.de

I ran this command:

sudo certbot renew --dry-run

It produced this output:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/wolke.sout.de.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for wolke.sout.de
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (wolke.sout.de) from /etc/letsencrypt/renewal/wolke.sout.de.conf produced an unexpected error: Failed authorization procedure. wolke.sout.de (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://wolke.sout.de/.well-known/acme-challenge/5wqshct85ZGYASEZlG2Wa7URLQW8JxIOMCuUxoX-BGk: Error getting validation data. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/wolke.sout.de/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/wolke.sout.de/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

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

   Domain: wolke.sout.de
   Type:   connection
   Detail: Fetching
   http://wolke.sout.de/.well-known/acme-challenge/5wqshct85ZGYASEZlG2Wa7URLQW8JxIOMCuUxoX-BGk:
   Error getting validation data

My web server is (include version):

 nginx-light               1.10.3-1+deb9u2

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

Debian 9.8 (Stretch)

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 0.28.0

The domain wolke.sout.de is a KVM virtual machine. It has only a public IPv6 address, no IPv4 address. It is running seafile behind an nginx webserver. It is used for no other purposes that providing seafile. Therefore HTTP is not used.

Any help is appreciated!

2

HTTP is required for (the simplest) authentication.
You have already obtained a cert (presumably by TLS-SNI-01 [HTTPS] authentication).
If you need to continue that method, the easiest workaround is to have an HTTP listener that redirects all HTTP to HTTPS.
Provided that your ISP allows port 80.
Then LE can follow that redirection and renew as you had in the past.

3

Sorry, that was an misunderstanding.

HTTP is not used, but redirects to HTTPS:

server {
  listen 80 http2;
  listen [::]:80 http2;
  server_name wolke.sout.de;

  rewrite ^ https://$http_host$request_uri? permanent;  #force redirect HTTP to HTTPS
  server_tokens off;
}

I do the same on other virtual hosts running apache and upgrading the LetsEncrypt certificates works there. So I assume the same is possible with nginx. And as you write

the easiest workaround is to have an HTTP listener that redirects all HTTP to HTTPS.

this seems to be the case.

Still, I have a problem upgrading the certificate...

4

Something “WEIRD” is going on…

curl -Ikig http://wolke.sout.de/
curl: (8) Weird server reply

5

In addition to fixing the above (your port 80 doesn't seem to talk HTTP at all), try:

Change this to:

location / {
  rewrite ^ https://$http_host$request_uri? permanent; #force redirect HTTP to HTTPS
}

and try using certbot --nginx again.

6

or:
return 301 https://$http_host$request_uri; #force redirect HTTP to HTTPS

7 
wget http://wolke.sout.de/
--2019-03-11 23:10:17--  http://wolke.sout.de/
Resolving wolke.sout.de (wolke.sout.de)... 2a01:4f8:120:5222::100:101
Connecting to wolke.sout.de (wolke.sout.de)|2a01:4f8:120:5222::100:101|:80... failed: Connection refused.
8

I have played around with the config and stopped and restarted seafile and nginx.

curl still produces the above mentioned error, but this seems to be a problem with curl, since wget downloads a correct html file and accessing it via browser works, too.

Still, the certbot error persists...

9

A bold claim ... it's by far the most popular HTTP client in the world. If it doesn't work, it's no surprise that other headless clients (like Let's Encrypt) don't.

10

Might be, but why is wget and browser access working? Both get correctly redirected to HTTPS. What is wrong there?

11

wget is falling back to an assumption that the response is HTTP/0.9 because it doesn't have HTTP headers:

HTTP request sent, awaiting response... 200 No headers, assuming HTTP/0.9

By contrast, curl isn't doing so.

1 Like
12

(…I wonder if the response is really HTTP/2, sent in response to a non-HTTP/2 capable client?)

13

It could be literally any protocol - you can use wget against something like sshd and it reports a similar HTTP/0.9 ‘success’.

I would guess, from the leading bytes 0000 1204, it is using maybe h2c or nginx PROXY protocol, this comes up in Google results: https://serverfault.com/questions/777961/nginx-proxy-0000-1204-0000-0000-0000-0300-0000-8000

1 Like
14

Oh, duh. That's h2c. Get rid of the http2.

1 Like
15

Thanks! That was the problem.

So, http2 is wrong, because http2 always wants to be encrypted?

But, what is h2c? I never heard of it. And googling actually didn't provide me some info about what it is.

16

h2c is HTTP/2 cleartext. Browsers only support HTTP/2 over TLS.

A reasonable person might expect nginx to downgrade its response to HTTP/1.1 only upgrade its responses to HTTP/2 when the client supports h2c, but that’s an open bug: https://trac.nginx.org/nginx/ticket/816

1 Like
17

Ah, ok.
Then again: Many thanks for your help!

1 Like
18

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