Certbot permissions error - ubuntu 18.04 bionic

Hello, I have a problem that I’ve search on the boards but cannot seem to find.
I’ll start from the beginning and give as much information as possible.

I’m running an in-house server with Ubuntu 18.04 & nginx. I have a domain ssh2.uncool.club (which I do not own, but have its A name pointing to my box)
After installing certbot and running the command sudo certbot --nginx it popped out a port 80 error, I then installed apache and changed the port of nginx to 8080 so apache can use port 80 by default as root.

Now, when I run the command, I receive the following:

Performing the following challenges:
http-01 challenge for ssh2.uncool.club
Using default addresses 80 and [::]:80 ipv6only=on for authentication.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. ssh2.uncool.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://ssh2.uncool.club/.well-known/acme-challenge/J_3_pEuCxoZh5OxYvvG816TjBS64tQXiPmvnWGhAw1E: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"

 - The following errors were reported by the server:

   Domain: ssh2.uncool.club
   Type:   unauthorized
   Detail: Invalid response from
   2.0//EN\">\n<html><head>\n<title>404 Not
   Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"

   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’ve tried running this as root and receive the same error.

Now, this is all I’m trying to do: I want nginx setup (which I have, and it runs fine), but I need https for my stream not http, and for the life of me I cannot get it up and running with certbot. Believe me when I tell you I’ve pounded away at this, as from the very beginning it’s been error after error - and it’s a miracle I’ve gotten this far. Nginx runs fine when its conf ports ( /etc/nginx/sites-enabled/) is at 80, but not when I change it to 8080 or stop it so I can attempt to get the encryption to work. This is besides the port, however, I know even if I get certbot running as needed, I’ll need the extended ssl info for the nginx.conf. I need help, I don’t know what I’m missing.

Then you would need to run:
certbot --apache
[not cerbot --nginx]

I would remove Apache from the equation. That is only serving to (over)complicate the situation.
[if it wasn’t used before and isn’t required now - only used in an attempt to get a cert]

They both spit out the same error. I should of put that. That’s why I installed apache, to see if I could get it working on that end instead.
(you’re right about the latter, that was the only point of install)

Hi @refriedfood

your main configuration looks ok. The www has another ip address, but that’s not relevant if you don’t want a certificate with www + non-www.

Your port 80 is open, checking /.well-known/acme-challenge there is the expected result http status 404 - not found.

And I see only nginx (checked with https://check-your-website.server-daten.de/?q=ssh2.uncool.club ).

So check your config file to find your root, then use it:

certbot run -a webroot -i apache -w yourRootDirectory -d ssh2.uncool.club

I removed apache2, and set my nginx back to port 80, and then ran sudo certbot --nginx and it went through. But, when I test at https://www.ssllabs.com/ssltest/analyze.html?d=ssh2.uncool.club it errors out. Now I’m totally baffled. This was spit out:

 - Congratulations! Your certificate and chain have been saved at:
   Your key file has been saved at:
   Your cert will expire on 2019-06-07. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"

So, I’m assuming I’ve gotten it, but now I’m lost. Can I add the ssl to my nginx.conf, if so how. Or do I need to do something else within the nginx configuration for certbot to work with it? sorry, I’m new to this.

You have created a new certificate.


But it’s not visible.

Domainname Http-Status redirect Sec. G
http://ssh2.uncool.club/ 301 https://ssh2.uncool.club/ 0.350 A
http://www.ssh2.uncool.club/ 301 https://www.ssh2.uncool.club/ 0.343 A
https://ssh2.uncool.club/ -2 3.856 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it
https://www.ssh2.uncool.club/ 200

Instead, there is a blocking firewall.

But if this is only a private domain, it’s not a problem.

The cert isn’t intended to be used for webhosting, just nginx streaming so the domain/ip is https. There is no site running off that subdomain, it only points to nginx’s port for streaming.

So, does that mean it’s all a matter of integrating the pems into my nginx.conf for use? Thanks for the help.

Do you see the certificate internal? If that works and if that is enough, it’s ok.

The only thing: You can’t use such public tools like Ssllabs to check your configuration.

It’s added all the pem files, yes.


I just don’t know how to get it working now in nginx correctly. I’ve been modifying my conf as it’s supposed to be, but it still doesn’t work when trying to grab the m3u8.

Do you mean you are not using HTTP for your streaming? i.e. using ngx_stream?

Certbot won’t automatically configure this for you, but it’s not that complicated: https://nginx.org/en/docs/stream/ngx_stream_ssl_module.html

Just match up ssl_certificate to fullchain.pem and ssl_certificate_key to privkey.pem.

I am literally on that page. I’ve been trying all types of additions to my nginx.conf file with no results. I can get it to say the conf is fine via nginx -t testing, and then when I run it and stream, I cannot connect via https. Here’s my latest conf if you’re interested:

#worker_processes  auto;
worker_processes  1;
events {
    worker_connections  100;

# RTMP configuration
rtmp {
    server {
        listen 1245; # Listen on standard RTMP port

        chunk_size 6000;
	sync 5000ms;

        application show {
            live on;
            # Turn on HLS
            hls on;
            hls_path /mnt/hls/;
            hls_fragment 3;
            hls_playlist_length 60;
            # disable consuming the stream from nginx as rtmp
            deny play all;

http {
    sendfile off;
    tcp_nopush on;
   #aio on;
    directio 512;
    default_type application/octet-stream;

    server {
        listen 443 ssl;

        ssl_certificate /etc/letsencrypt/live/ssh2.uncool.club/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/ssh2.uncool.club/privkey.pem;
        ssl_session_cache shared:SSL:5m;
        ssl_verify_client off;
        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers RC4:HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;

        location / {
            # Disable cache
            add_header 'Cache-Control' 'no-cache';

            # CORS setup
            add_header 'Access-Control-Allow-Origin' '*' always;
            add_header 'Access-Control-Expose-Headers' 'Content-Length';

            # allow CORS preflight requests
            if ($request_method = 'OPTIONS') {
                add_header 'Access-Control-Allow-Origin' '*';
                add_header 'Access-Control-Max-Age' 1728000;
                add_header 'Content-Type' 'text/plain charset=UTF-8';
                add_header 'Content-Length' 0;
                return 204;

            types {
                application/dash+xml mpd;
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;

            root /mnt/;

So what happens if you run e.g. (substituting the m3u8 URL for the real one):

ffplay -nodisp https://ssh2.uncool.club/your_stream.m3u8

In particular, looking for the specific error message.

Continuous loading. I’m using OBS to stream to rtmp, and then I have it running out into a clapper html page that worked before as http, but now not as https.

This might further reveal what it’s doing in terms of network:

-loglevel trace

Tricky to debug this one without being able to connect ourselves …

Yeah, I literally don’t know what all I can give you that isn’t right there. I can stream fine to it, but that just means the listening rtmp port works, and then in the page I try it locally and with various ports and it never kicks over. So, I think it’s with the conf as there is no errors when starting the process (nginx), testing it, or even netstat -p -c -t, which bring up its workers:

tcp 0 0 Unknown.domain:1245 Unknown.domain:49989 ESTABLISHED 1815/nginx: worker

This is all normal for http, it’s literally the same output, it just won’t play with https. Ugh.

I don’t see where you listen to SSL, nor use the newly created certs, nor how you connect the default https port 443 to port 1245.

Look again at UTC #11

http {

    server {
        listen 443 ssl;

Non ssl looks like this:

    server {
        listen 9256;

It isn’t the rtmp that is needing to be secure, it’s the output. So if you stream using rtmp to the server (which is via the box anyhow and not remote), it’s insecure which is fine, but the output can only be grabbed insecurely via http://domain:port/path/file.m3u8 not https. When that conf is used, you can no longer connect to the listening rtmp port as it errors anyway (this is with certbot). I’m about to give up. There are https streams out there so I know it’s possible, but for some reason I’m not finding the correct methods.
I spent hours last night trying to get stunnel to work with it to no avail, either. I’m just not clever enough to figure this out.

I do see that you obtained a cert.
Are running RTMP on port 1245 (or 9256).
Have TLS/SSL enabled on port 443.

I’m not 100% certain (as I haven’t worked with RTMP)…
But it looks like all you need is to proxy_pass connections to RTMP.

That said, I can’t find anything online on how to do that - so I’m thinking that is just not going to be possible.

I did find mention of RTMPS.
You might want to look at if your software supports that instead.

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