Certbot renewal fails because of non http/s protocol

Help
1

Hi letsencrypt community

It seems like I've run into an issue that I didn't have before. When renewing my certs with certbot it throws errors immediately. The issue seems to be my Teamspeak 3 redirect. This did not cause any issues up until the last couple of system updates. I only noticed the issue because one of my certs ran out.
The error output is just for the main webserver domain. All subdomains fail as well. It does not matter if they are located in the same nginx config or in a seperate one.
To my knowledge I did never create a cert including my Teamspeak subdomain.
Any help or pointers to useful documentation is appreciated.

Edit: forgot to mention that when I comment out the Teamspeak redirect it does succesfully perform a renew or dry run for all certs

My domain is: swisssmp.ch

I ran this command: certbot renew

It produced this output:

- The following errors were reported by the server:

   Domain: web01.swisssmp.ch
   Type:   connection
   Detail: 2a01:4f8:13a:2699::2: Fetching ts3server://ts3.swisssmp.ch:
   Invalid protocol scheme in redirect target. Only "http" and "https"
   protocol schemes are supported, not "ts3server"

   Domain: www.swisssmp.ch
   Type:   connection
   Detail: During secondary validation: 2a01:4f8:13a:2699::2: Fetching
   ts3server://ts3.swisssmp.ch: Invalid protocol scheme in redirect
   target. Only "http" and "https" protocol schemes are supported, not
   "ts3server"

   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. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

My web server is (include version): nginx/1.18.0

The operating system my web server runs on is (include version): Debian GNU/Linux 11 (bullseye)

My hosting provider is: Hetzner

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

The version of my client is: certbot 1.12.0

2

If you've identified that the redirect is the issue, you can work around it, depending how you have written the redirect in nginx.

If you have something like:

server {
  server_name web01.swisssmp.ch;
  root /var/www/whatever;
  return 307 ts3server://ts3.swisssmp.ch;
}

You can amend it to something like:

server {
  server_name web01.swisssmp.ch;
  location / {
    return 307 ts3server://ts3.swisssmp.ch;
  }
  location /.well-known/acme-challenge/ {
      root /var/www/whatever;
  }
}

which is functionally identical, except for the Certbot bit.

4 Likes
3

Would that work regardless if the nginx or webroot authenticator was used?

1 Like
4

Iā€™m working on the assumption that webroot is the authenticator, because a bare redirect should still work with the nginx authenticator.

3 Likes
5

@_az Ah, makes sense :slight_smile:

@Mon3yb Are you aware your webserver is behaving differently for web01.swisssmp.ch when using IPv6 versus IPv4?

  • Using IPv6 there's only HTTP on port 80 listening, serving the redirect to TeamSpeak; no HTTPS on port 443 is listening;
  • Using IPv4 there's a HTTP port 80 to HTTPS port 443 redirect with a certificate on the HTTPS port for just swisssmp.ch, leading to a hostname mismatch, as it's missing web01.swisssmp.ch. And it's serving a huge HTML page with title "SwissSMP.ch Gaming & eSport Community Schweiz". No redirect to TeamSpeak present.
2 Likes
6

Thanks to both of you for the analysis. Maybe I have to get into a bit more detail on my setup.

There is only one external IPv4 and it should also only have one external IPv6 in use.
web01.swisssmp.ch is more of a legacy thing for my backend and currently should redirect to swisssmp.ch (gaming forum).
So you can treat web01.swisssmp.ch just like www.swisssmp.ch.
ts3server://ts3.swisssmp.ch is a completely separate redirect and should automatically trigger a protocol redirect on the users system to open up TeamSpeak. This also seemed to work for almost a year. Without any certification issues. I also did not request a cert for ts3.swisssmp.ch as it is not needed. There is no document root or anything behind it. Just the redirect in nginx.

The nginx config for that looks like this:

server{

        server_name ts3.swisssmp.ch;
        access_log /var/log/nginx/web-01/access.log;
        error_log /var/log/nginx/web-01/error.log;

        location / {
                return 307 ts3server://ts3.swisssmp.ch;
        }

    listen 443;
    listen [::]:80 ipv6only=on;
    listen 80;
}

I got that config from some other forum (can't find it right now).

The forum directive looks like this and should just server the ssl cert and proxy the connection to a virtual machine behind it.

server{
        server_name swisssmp.ch www.swisssmp.ch web01.swisssmp.ch;

        access_log /var/log/nginx/web-01/access.log;
        error_log /var/log/nginx/web-01/error.log;

        location / {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;

                proxy_pass http://xxx.xxx.xxx.xxx/;
                proxy_read_timeout 90;
                proxy_pass_request_headers on;
        }
}

I actually never noticed that. Thanks for pointing it out. Might have to add ipv6 listeners for the forum too.

Edit: Just to add more information here is the certbot addition to the config

server{
    if ($host = www.swisssmp.ch) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = swisssmp.ch) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = web01.swisssmp.ch) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        server_name swisssmp.ch www.swisssmp.ch web01.swisssmp.ch;
    listen 80;
    return 404; # managed by Certbot
}
8

This part should NOT be listening on port 443:

4 Likes
9

The block below has no listen clauses. This is probably why Certbot created another server block with these same names.

This one has a listen but only for IPv4. So, requests to your nginx with IPv6 will never use this server block. I am not clear on your intentions but these listen clause inconsistencies cause various problems.

5 Likes
10

I guess you are right. I removed it and it did resolve the certification issues. Strange that I never encountered any issues before. I always thought that the certbot only evaluates server blocks with actively managed certificates when renewing. If that behaviour is intended then that's fine for me.

Oh, I did cut out the lower part, there are some additional headers and security options in that block. Thought I omit that because I'm not sure on how safe it is to publish everything from my configs :wink:
Meaning certbot did create a 443 listen with all the usual certification configuration.

The other blocks with the redirects got created by certbot. If I remember correctly it should be that way and I originally only had port 80 listens in each server block.

I will go ahead and change my server blocks to listen on ipv6 and ipv4. As I have just read the "ipv6only=on" is no longer needed.

2 Likes
11

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