Caddy v2 - update and warning

[pwhodges 1855]

I have just tested this with Caddy2.  My test configuration has the reverse proxy directive and nothing else - no extra header specifications or anything.  I have no problem with resuming using this setup, so Caddy is passing the play position from the client back to the Emby server correctly.

I tested using the browser client on my desktop, but with the external IP of the machine running Caddy2, so it looped back through my router.

As I said, I have no experience of Kody, Embycon or CloudFlare, so I hope someone else will be able to step in to speak about them.

Paul

[pwhodges 1855]

Oops, I realise you said the problem arose using apps other than the browser.

I have now tested with the Android mobile app, and again there is no problem.

Paul

[neunghaha28 16]

6 minutes ago, pwhodges said:

Oops, I realise you said the problem arose using apps other than the browser.

I have now tested with the Android mobile app, and again there is no problem.

Paul

Yes, the problem is caddy v2 on kodi addons Emby and Embycon.

Caddy v1 Everything works.

Thanks for help.

 

Now I'm using nginx. 

[pwhodges 1855]

Glad you have a solution that works for you.

Caddy is probably as configurable if necessary.  What is your nginx config like?  I'd be interested to try to find what caddy directives need to be added.

Paul

Edited September 27, 2020 by pwhodges

[neunghaha28 16]

On 9/26/2020 at 4:27 AM, pwhodges said:

I have no problem with resuming, using Caddy v1.  I have no added headers or anything, as Caddy's defaults are generally correct.  I'm not at home, so I can't test it with my Caddy v2 setup until Sunday, but I'm pretty sure I tested that behaviour previously and found no problem.

However, I don't use the add-ons you have, nor CloudFlare.

Paul

# Emby Subdomain
# Replace DOMAIN.TLD with your domain
server {
        listen 80;
        server_name emby.xxx.me;
        return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
server_name emby.xxx.me;   #your subdomain.domainname.com here

ssl_session_timeout 30m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate      /etc/ssl/certs/cert.pem;
ssl_certificate_key  /etc/ssl/private/key.pem;
ssl_session_cache shared:SSL:10m;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
ssl_stapling_verify on;
ssl_session_tickets on;
resolver 8.8.8.8 8.8.4.4 valid=200s;
resolver_timeout 5s;
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
add_header X-XSS-Protection "1; mode=block";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
http2_max_field_size 16k;
http2_max_header_size 32k;
ssl_ecdh_curve secp384r1;
proxy_set_header Host $host;
fastcgi_pass_request_headers on;

proxy_hide_header X-Powered-By;
add_header X-Xss-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff"  always;
add_header Strict-Transport-Security "max-age=2592000; includeSubdomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header 'Referrer-Policy' 'no-referrer';

add_header Content-Security-Policy "frame-ancestors emby.xxx.me;";   #add your domainname and all subdomains listed on your cert

access_log /var/log/nginx/emby.access.log;
error_log /var/log/nginx/emby.error.log;


location / {
proxy_pass http://127.0.0.1:8096; # Local emby ip and non SSL port

proxy_hide_header X-Powered-By;
proxy_set_header Range $http_range;
proxy_set_header If-Range $http_if_range;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#Next three lines allow websockets
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location ^~ /swagger {   ## Disables access to swagger interface
        return 404;}
}

 

Edited September 27, 2020 by neunghaha28

[akakza 1]

Had same problems with Kodi addon for Emby since updating from Caddy v1 to v2 (2.2.1) (2.3.0) and as a workaround i simply used a VPN connection to the host server. Not anymore! Happy to say that Caddy v2.4.0 fixed it all. Can finally resume, skip ahead etc.

Edited May 11, 2021 by akakza

[Mookdog 90]

Hey guys

 

I installed caddy v2 and I have the caddyfile in the folder that I created. I know with the new version of caddy u can install zerossl as your ssl certificate instead of LetsEncrypt
I have the website explaining how to add it to your caddyfile but for some reason it dont work when I add it. I get an error from caddy. Was wondering if someone who is a genius can add it for me bc I have no clue what I am doing. Here is the site that explains how to add it

https://caddy.community/t/using-zerossls-acme-endpoint/9406

 

Thanks in advance

Mook

[Mookdog 90]

Edit to my other post

I found another site discussing using zerossl but its way above my payscale of learning lol

https://caddyserver.com/docs/caddyfile/directives/tls

 

Mook

[akakza 1]

2 hours ago, Mookdog said:

Edit to my other post

I found another site discussing using zerossl but its way above my payscale of learning lol

https://caddyserver.com/docs/caddyfile/directives/tls

 

Mook

Recently had to switch Emby over to ZeroSSL cause of some outdated Root certificeres on some LG, Samsung TVs and very unknown when they decide to update those devices so LetsEncrypt work again.

 

Have to go over to https://zerossl.com, create account and get your personal API key. Caddyfile example:

 

emby.example.com {
	tls {
		issuer zerossl "APIKEY"
	}

	etc...
	etc..

	reverse_proxy 127.0.0.1:8096 {
	}

	encode gzip zstd
}

 

 

[chef 3808]

Hi there, I am still using caddy v1 because I wasn't able to be successful writing a caddy file for my emby server with v2.

I tried to follow the documentation, but I wasn't understanding it properly, and resorted to using my old caddy v1 setup.

Would someone be so kind as to show a caddy file example for emby on a reverse proxy?

Or perhaps if I shared my v1 caddy file, someone would be able to help we make the move to v2?

Thank you. 

-Ben

[seanbuff 1146]

54 minutes ago, chef said:

Would someone be so kind as to show a caddy file example for emby on a reverse proxy?

hey @chef, this is what I use and it seems to work fine for me on caddy v2

 

{
        email name@address.com
}

# Site Name
my.domain.com {
        encode gzip
        log {
                output file D:\caddy_logs\emby_access.log {
                        roll true               # Rotate logs, enabled by default
                        roll_size_mb 10         # Set max size 10 MB
                        roll_gzip true          # Whether to compress rolled files
                        roll_local_time true    # Use localhost time
                        roll_keep 7             # Keep at most 7 log files
                        roll_keep_days 7        # Keep log files for 7 days
                }
        }
        reverse_proxy localhost:8096
		tls {
			issuer acme {
				preferred_chains {
					root_common_name "ISRG Root X1"
            }
        }
    }
}

 

[chef 3808]

1 hour ago, seanbuff said:

hey @chef, this is what I use and it seems to work fine for me on caddy v2

 

{
        email name@address.com
}

# Site Name
my.domain.com {
        encode gzip
        log {
                output file D:\caddy_logs\emby_access.log {
                        roll true               # Rotate logs, enabled by default
                        roll_size_mb 10         # Set max size 10 MB
                        roll_gzip true          # Whether to compress rolled files
                        roll_local_time true    # Use localhost time
                        roll_keep 7             # Keep at most 7 log files
                        roll_keep_days 7        # Keep log files for 7 days
                }
        }
        reverse_proxy localhost:8096
		tls {
			issuer acme {
				preferred_chains {
					root_common_name "ISRG Root X1"
            }
        }
    }
}

 

Thank you Sean. Currently I allow caddy v1 to update my let's encrypt keys. Does the issuer line in this example have to point to let's encrypt, do you happen to know? Or maybe it is default? 

[akakza 1]

LetsEncrypt is the default, but ISRG Root X1 is not ("DST Root CA X3" is). Likely added cause of the issue i talked about earlier. Will try and implement this, so i dont have to use ZeroSSL anymore. Thanks seanbuff

 

 

[pwhodges 1855]

4 hours ago, chef said:

Would someone be so kind as to show a caddy file example for emby on a reverse proxy?

 

 

I'm not one for using directives that I see no need for.  The part of my Caddyfile dedicated to Emby reads:

emby.mydomain.org {
    reverse_proxy http://myembyserver:8096
}

It works, so why would I want more?

Paul

[Mookdog 90]

6 hours ago, akakza said:

LetsEncrypt is the default, but ISRG Root X1 is not ("DST Root CA X3" is). Likely added cause of the issue i talked about earlier. Will try and implement this, so i dont have to use ZeroSSL anymore. Thanks seanbuff

 

 

So this  ISRG Root X1 should fix the LG TV problem ?

Thanks

Mook

[seanbuff 1146]

8 hours ago, chef said:

Does the issuer line in this example have to point to let's encrypt, do you happen to know?

 

7 hours ago, akakza said:

LetsEncrypt is the default, but ISRG Root X1 is not ("DST Root CA X3" is). Likely added cause of the issue i talked about earlier.

 

Correct, the tls section was just added to resolve the recent issue with the expired DST Root CA X3 certs, and thus switch it to the ISRG Root X1 chain instead when using Let's Encrypt.

@chef you can of course run it without this section if you like:
 

		tls {
			issuer acme {
				preferred_chains {
					root_common_name "ISRG Root X1"
            }
        }
    }

 

[Mookdog 90]

4 hours ago, seanbuff said:

 

 

Correct, the tls section was just added to resolve the recent issue with the expired DST Root CA X3 certs, and thus switch it to the ISRG Root X1 chain instead when using Let's Encrypt.

@chef you can of course run it without this section if you like:
 

		tls {
			issuer acme {
				preferred_chains {
					root_common_name "ISRG Root X1"
            }
        }
    }

 

I added this to my caddyfile all works fine but caddy just freezes at this line when grabbing certs
 

2021/10/23 02:48:56.421 INFO    tls.obtain      releasing lock  {"identifier": "mydomain.com"}

[seanbuff 1146]

1 hour ago, Mookdog said:

2021/10/23 02:48:56.421 INFO    tls.obtain      releasing lock  {"identifier": "mydomain.com"}

silly question but you replaced "mydomain.com" with your actual domain name yeah?

[Mookdog 90]

13 minutes ago, seanbuff said:

silly question but you replaced "mydomain.com" with your actual domain name yeah?

Yeah I took my domain out when I paste the line lol

 

Mook

[Mookdog 90]

On 10/22/2021 at 10:50 AM, akakza said:

LetsEncrypt is the default, but ISRG Root X1 is not ("DST Root CA X3" is). Likely added cause of the issue i talked about earlier. Will try and implement this, so i dont have to use ZeroSSL anymore. Thanks seanbuff

 

 

Its funny when using the Root X1 for the lets encrypt ssl cert my daughters LG TV still dont work. Everyone else in my family can log in but her with the LG. But yet when using a Zerossl cert without using the reverse proxy it works fine for my daughter. 

 

Mook

[Fretawekakoep 3]

On 04/05/2020 at 15:27, pwhodges said:

OK, I have run an initial trial of Caddy version 2, and it works as simply as they say it should.  I used Caddy 2 rc3 for the trial.  Note that you can no longer get Windows binaries of Caddy v1, only source, so v2 is where it's at now!

 

First, the setup I tried it in, and the assumptions I made.  A domain name is required for external access; you need to get that and specify your IP address in the DNS.  I use ports 80 and 443 for Caddy, because this enables it to get the required certificate from Let's Encrypt; it does this completely automatically in most circumstances, but you must have port 80 open for the process to work.  When you try to access port 80, however, Caddy automatically redirects the request to port 443 - again, you don't need to configure this or think about it.  So, I open ports 80 and 443 in my router to the machine running Caddy (and in the router's firewall as well, if this is a separate action), and ensure that the Windows firewall will also allow these ports through to caddy.exe.

 

Next, I am running Emby in another machine, which for this example has IP address 192.168.1.66.  I leave its ports as default, and only use the http one (8096).  As it's on a different machine I could change this to port 80 for convenience, but I don't bother for other reasons.

 

For an initial test, I went to the directory where I had dropped the Caddy executable and in a command window in the directory containing Caddy typed the command:

caddy reverse-proxy --from emby.mydomain.com --to http://192.168.1.66:8096

That's it - the first time it may take a little while to get the certificate organised, but subsequent runs will be almost instant, as the certificate is already in place.  The command doesn't return, so the window needs to be preserved while Caddy is running in this manner.  Then simply typing emby.mydomain.com in a browser shows me what I expect.  Note, I use the external domain name for internal access as well - this means that I can set up mobile devices to work whether I am at home or away.  This does require a router that will loop back internal requests to the outside address efficiently, though; my Draytek Vigor does this perfectly.

 

Finally I tried a config file for Caddy which enables running in the background or as a service (I haven't checked setting Caddy 2 up as a Windows service yet, which is how I'm running Caddy v1).

 

This went as follows: in the same directory as caddy.exe I created a file called caddyfile (no extension).  In this I placed the following text:

{
    email name@maildomain.com
}

emby.mydomain.com {
    reverse_proxy http://192.168.1.66:8096
}

Note the underscore in "reverse_proxy" where the command line version had a dash.  If you can't find how to edit a file without an extension, create it with ".txt" and then delete the extension after editing it.  The email directive enables Let's Encrypt to email you warnings if problems arise in the future.  If Caddy is started in the directory containing the exe file and caddyfile, it will automatically use the specified configuration.  I first simply ran it in the command window using the following command:

caddy run

As before, this does not return, and the proxy is now operating.  It is also possible to start Caddy in the background from a command, thus:

caddy start

In this case you can stop it using the command:

caddy stop

which is rather unsurprising.  If you ran caddy using the previous commands which held the window without returning, Ctrl-C will stop it in the usual manner, as will closing the window, or using the "caddy stop" command in another window.

 

At least in my system, this really is all it takes for the proxy to work and do all the things required.  But Caddy can be extensively customised if other systems require tweaks.  There is even a facility to give it an nginx config file which it should then translate internally, but as I don't use nginx, I'm not going to try that out - in any case, it would take as much typing to specify that as to provide the trivially simple Caddy commands that work.

 

Paul

Hi Paul, Thank you so much for this excellent write up! 

I followed all the steps and I think I've managed everything up, the DNS setup, SSL certificate and Port Forwarding untill the Caddy part. I was wondering if the results below are expected return values or is something going wrong? Sorry for the dumb question but appreciate your expertise on this

 

Edited April 26, 2022 by Fretawekakoep

[pwhodges 1855]

Nothing there concerns me.  The last line is slightly surprising, but the rest is just reporting the processes of getting https set up and running - so the last might come from the same, but just be badly worded.

Paul

[Fretawekakoep 3]

2 hours ago, pwhodges said:

I'm now getting this error...

2022/04/26 17:00:27.738 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "xxxxx.xxxxxxxxxx.xxx", "issuer": "xxxx-xxxx.api.letsencrypt.org-directory", "error": "HTTP 429 urn:ietf:params:acme:error:rateLimited - Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/"}

 

Edited April 26, 2022 by GrimReaper
Personal details removed

[pwhodges 1855]

1 hour ago, Fretawekakoep said:

2022/04/26 17:00:27.738 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "xxxxx.xxxxxxxxxxx.xxx", "issuer": "xxxx-xxx.api.letsencrypt.org-directory", "error": "HTTP 429 urn:ietf:params:acme:error:rateLimited - Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/"}

 

The only fix for this:

too many failed authorizations recently

is to wait a bit.  The link at the end of the error message describes the limits in detail, and the delay required depends on which limit you've hit.  In your case it seems to be:

"There is a Failed Validation limit of 5 failures per account, per hostname, per hour."

so waiting a hour or so should clear it, but I can't guarantee that.  As it happens, I never hit any of the limits when creating my setup, so I can't speak from experience on this one!

Paul

Edited April 26, 2022 by GrimReaper

[Fretawekakoep 3]

Appreciate the swift reply Paul! I was indeed tinkering a bit with the config and was trying to add a reverse proxy for Ombi at localhost:5000 but that was giving me trouble. Probably because I need to follow the same steps to get an SSL certificate for that domain in place. Hope to test in an hour, still having troubles setting up the HTTPS connection though. It seems as if my Emby remote connection only works via the standard ports. As soon as I try to map the ports to 80 and 443 the app does not load back up.. To be honest I’ve been taking so many attempts and reading a lot on this forum, I was already amazed I got this far…