Secure Certificate for SRS server Docker Container fails

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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

I'm trying to create certificate only for my srs server which is a Docker container on ubuntu

My domain is: live.bellezas.co

I ran this command:
sudo docker run -it --rm --name certbot
-v "/etc/letsencrypt:/etc/letsencrypt"
-v "/var/lib/letsencrypt:/var/lib/letsencrypt"
certbot/certbot certonly

It produced this output:

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: live.bellezas.co
Type: unauthorized
Detail: 172.233.190.207: Invalid response from http://live.bellezas.co/.well-known/acme-challenge/Se5l_DPa5-YPoL_Zq-DPRDfIdbpA7VGYv2hAG9X0znw: 404

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

Some challenges have failed.

My web server is (include version):

linode server running ubuntu ver 24.04.1 LTS

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

I'm not currently running a webserver only a SRS media streaming server on this linode

My hosting provider, if applicable, is:

Akamai

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

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

Hi @mstrdlo, and welcome to the LE community forum :slight_smile:

Be sure that the HTTP challenge requests (from the Internet) can reach your Docker container.

Also, be sure both of these are reaching your system:

Name:      live.bellezas.co
Addresses: 2a01:7e04::f03c:95ff:fea4:84ee
           172.233.190.207
1 Like

Good morning, thank you for reaching out, so here's what I did so far, one I checked reverse lookup on both the ipv4 and ipv6 and both point to the domain live.bellezas.co, also dns lookup points to both ipv4 and ipv6. So I SSH to the server and ran

sudo python3 -m http.server 80

at the root then I tried

sudo docker run -it --rm --name certbot \
            -v "/etc/letsencrypt:/etc/letsencrypt" \
            -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
            certbot/certbot certonly

same exact reply as originally posted, I would hate to have to use nginx as a proxy server for two reason, one extra worker on the server and two I really don't know how to do a proxy server to point to my Docker container, I've never configured a proxy server before. One more note I'm not a server administrator I'm a developer so it's not as clear to me on how to configure the server very well, I'm just trying to follow documentation.

thanks

1 Like

What's usually running on port 80? Because currently I'm getting a connection refused.

Also:

What root would that be? Because your docker run command only runs Certbot with the certonly subcommand without any other options? How did you configure Certbot?

1 Like

Looking at your original post I see --standalone with a "404" (http Not Found) error to the IPv4 address.

This means a few things

  1. Let's Encrypt Server starts with IPv6 so that must have timed out for it to retry as IPv4
  2. The '404' should never happen if the request reached the Certbot --standalone server
  3. The Cerbot --standalone requires exclusive use of port 80

Your most recent post says you started a python server on port 80. Which is fine for testing. But, it won't cohabit with Certbot --standalone.

You could start that python server and leave it running and let us test connections to you. Because I also cannot reach you using IPv4 or IPv6 from the public internet

2 Likes

Ah, missed that.

I think for Docker to be able to be contacted on port 80 (like for the standalone plugin), one needs to "map" the port to that Docker container, right? That said, I have the faintest clue about Docker.. But I've seen those port mappings before, so surely they are probably needed for something.

Yes. I'm not sure exactly what they are trying to achieve. Might be easier to instead run Certbot in their host (not a container). Then just share that host cert directory as a volume with the container running their SRS server.

2 Likes

Certainly, no need to put everything in a container, right? (Or even any container if you'd ask me :rofl:)

1 Like

It's all tradeoffs, like anything else :slight_smile: With multiple containers something has to direct the inbound HTTP(S) requests to the correct one. Or, handle some in the host (like HTTP port 80) and others (like HTTPS) in a container (like their SRS server).

Setting up containers is similar to setting up multiple machines. You need to sort out what goes where. Definitely a learning curve involved.

You are now :slight_smile:

5 Likes

I totally agree I'm new to SRS, and Docker ti be honest I think containers are worthless to be honest. I totally get that it makes it easy for installation but give the whole package I mean who in the world now a days runs any server without ssl? SSL should be a major part of security why not include certbot in the original configuration instead of making nubes jump through hoops to try to figure out a solution. I think I'm going to trash Docker install and do direct without a container. I was just following SRS recommendations, it's only making me waste countless hours researching.

Well, I don't know that Certbot is the best choice for integration like that but agree HTTPS should be a basic element of any publicly accessible service.

A quick glance suggests SRS recommend something like Caddy or other reverse proxy "in front of" their origin HTTP server. Is this what you are trying to configure?

Because Caddy manages certs for you. I don't know it well but it is very popular and has an active community. https://caddyserver.com/ It has HTTPS (certs) built-in compared to nginx which requires more diy.

These SRS Server docs refers to it. I'd guess their community or even their wiki probably have sample setups for this.

SRS also works well with HTTP reverse proxy servers, like NGINX and Caddy.

3 Likes

First of all I want to thank all of you who took the time to lend a helping hand, much appreciated. Here's what I did to make it work.

  1. Got rid of Docker and installed SRS on the server, MikeMcQ thanks a bunch for that suggestions.
  2. I configured SRS server and then I installed NGINX, and did proxy pass to SRS server.
  3. Then I went through the regular installation of certbot and BOOM got issued s Certicate.

There's still much more for me to learn but this weekend was a great experience working this issue out. I'm sure I still have to fine tune the install but I'm in no rush and will get some more knowledge base on how to do all the right things.

So thank you everyone, I got it to work, I am now livestreaming and able to view from a browser via HTTPS and it's all good. So happy to have gotten to this stage. I was very reluctant to explore as much as I did, but it helped me learn how important you expert server admins are in our internet world. Much respect... I'm just a very very junior server baby admin SMH, but I love this stuff. Oh and one more thing, I think SRS (Simple Realtime Server) they should change their name to NSRS (Nothing Simple Realtime Server). How does that sound?

2 Likes

Worth reiterating that if (when running the server directly on your machine) you'd use Caddy instead of nginx as your front end proxy, you would have got the https configuration automatically without using certbot or other acme tools.

3 Likes

Good point I'll try that in a future build, right now I'm still learning the WebRTC on SRS part so a lot of things to learn, I only used NGINX because I'm familiar with it somewhat and wanted to get over this initial hump.

2 Likes

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