106 replies to this topic

[anakron]

https://letsencrypt.org/ the free certificate authority it in public beta now and allows everybody to get valid free SSL certificates.

 

It would be nice to have support for getting SSL certificates via their ACME protocol directly from emby.

This would make it really easy for people to setup secure access to the server from the internet.

[Luke]

Thanks, that looks very promising.

[Oakington]

OK. I've immersed myself in the acme protocol for 3 days and I've come up with a solution that works. It is not drop in ready, nor is it broken up into functions. On the contrary, I tried to make it as linear as possible to demonstrate the steps needed. Let me know what you think Luke. https://github.com/D...LetsEncryptEmby

[Oakington]

Another few things that we will need to address. LE will only issue a cert for domain names, not IP addresses. There are a few dynamic DNS hosts which are now on the public suffix list so they can now have certs issued for them. This would require the user to setup the DDNS though. 

 

Second, the ACME challenge verification protocol that I'm using here (http-01) requires the negotiation take place over port 80. This can create a few headaches as Emby normally runs under 8096 to avoid the types of conflicts that arrive with hosting on 80. 

 

I'm sure there are ways to overcome these hurdles. Hopefully without too many compromises.

 

Let me know your thoughts.

[Oakington]

Updated to make the file more readable and maintainable. I tried to integrate into the server repo but couldn't reconcile the INetworkManager interface between the two projects (Server.Mono &ServerApplication) in order to test it out with the c# webhost on port 80 (line 199). I'll throw up my clone to my github with the errors later tonight and maybe someone can help me out with the compilation errors.

Does anyone know if any DDNS hosts out there have am API for registering a DDNS hostname? It would be very useful in this case. Otherwise we can perhaps make the letsencrypt certs an option from the server settings->advanced->hosting page, requiring a hostname and email address for cert registration.


Kinda quiet out there...you guys have any thoughts on any of the stuff I'm talking about here?

Sent from my Nexus 6 using Tapatalk

[Luke]

i haven't had a chance to look closely at it yet although my first observation was that it's a lot of code. although if it's necessary then so be it.

 

What is the output of this? can it generate a pfx? we need something that can be fed into the http server.

[Oakington]

Yep. Pfx un-passworded. Line 54 for cert renewal and 282 for a new cert.

Sent from my Nexus 6 using Tapatalk

Edited by Oakington, 17 December 2015 - 11:53 PM.

[Luke]

ok that's perfect then. is a domain name required or can it be generated based on an IP?

[Oakington]

No, domain. Names only. It can be a DDNS hostname though as long as its on the public suffix list https://publicsuffix.org There's a list in the letsencrypt repo. Can't find it right now.

It also requires an email for account registration...not sure how happy they'd be if we hardcoded an @example.com name though. May be considered abuse.

Sent from my Nexus 6 using Tapatalk

[Oakington]

Updated my repo. It is almost drop in ready. I added the ApplicationHost.cs file to show how to implement it in Emby Server. the methods need to be defed in network managers and the interface. I've gotten it to build and it obtains the certificate as expected. After which it starts the server using the LetsEncrypt cert as well. 

 

The global variable "CA" that is commented out is the production one. The staging URL in use in the code generated from a fake root authority and won't be trusted in browsers. Once you have it all worked out, the CA should be swapped. 

 

If you want me just to make a pullrequest on the Emby repo, let me know and I'll clean it up. 

 

Lastly, port 80 needs to be Wan accessible. i.e. virtual server in your router. I'm not sure how to handle this for the masses. 

[Luke]

port 80? ouch. that's not going to fly. there's also the challenge of domain names, we might just have to create our own ddns in order to make this just work out of the box for people.

[Oakington]

So the user would request a subdomain from Emby's servers, then you would request the cert on their behalf, authenticating with LE on the DDNS then change the A name to their IP then give their local Emby instance the cert? I guess it can work. Is there a lot of traffic overhead for running a DDNS?
Also LE's certs are only good for 90 days and should be renewed every 60. That can be built into an Emby task.
I like it. I'd be willing to help setup the DDNS and underlying API for cert generation if you'd like.

Sent from my Nexus 6 using Tapatalk

[Luke]

yea but requiring users to open port 80 isn't going to work. can we improve that?

[Oakington]

[STRIKE]It looks as if there is a way to reply to a challenge on a non root port. I'll continue to investigate and test it out.[\STRIKE] There is definitely no way around the hostname requirement though...

EDIT:
This was only in testing. Not available in the production CA.
Your suggestion of setting up a DDNS would solve both issues though. By maintaining the DNS, we'd be able to handle all future renewals as well using the dns-01 challenge which consists of adding a DNS TXT entry to the record. There would be no need for the users to open port 80, no need to get a DDNS hostname, and the API can have a way or securely updating the clients WAN IP. This could really work but would be a bit complicated to set up initially. If you think this would be a viable solution, in the next week or two, I'll see if I can't get a prototype working with DDNS mgmt, initial cert verification, WAN IP updates, cert renewals and underlying API for it all.


Sent from my Nexus 6 using Tapatalk

Edited by Oakington, 19 December 2015 - 10:13 PM.

[ebr]

Complicated for whom to setup initially?  If it is complicated for the user then it won't do what we want.  If it is complicated for us, then we can deal.

[dragon2611]

I haven't tried it for the apps but for the webui I have it sitting behind a reverse proxy.

Currently using CaddyServer - http://caddyserver.com

 

 

Config is below - Note mine does more than just Emby and mydomain uses an older SSL cert issued by wosign, mydomain2 is using lets encrypt.

:80 {
redir https://{host}{uri}
}

https://subdomain.mydomain.com {
tls /usr/share/caddy/ssl/mydomain.bundle.crt /usr/share/caddy/ssl/mydomain.key 
log /var/log/caddy/mydomain.log {
rotate {
age 90 }
}
redir /owncloud /owncloud/ 302
proxy /owncloud/ http://10.0.244.184/ {
proxy_header X-Forwarded-For {remote}
proxy_header X-Real-HOST {host}
proxy_header Proxy_hostname {scheme}{host}
}
proxy /emby http://10.0.244.188:8096
}

https://nms.mydomain2.com
log /var/log/caddy/mydomain2.log {
rotate {
age 90 }
}
tls myemail@mydomain.com
proxy / http://10.0.244.193
}

For Emby only the config could probably be shortened to.  (Note I haven't tested this config for syntax errors, it's possible I might have missed some {} somewhere.

:80 {
redir https://{host}{uri}
}

https://subdomain.mydomain.com {
tls myemail@mydomain.com 
proxy /emby http://<embyIP>:8096 
}

Breaking it down as follows:

:80 {
redir https://{host}{uri}
}

This part essentially told the server to listen on port 80 and redirect any request to the same URL but on https (port 443)

https://subdomain.mydomain.com {
tls myemail@mydomain.com 
proxy /emby http://<embyIP>:8096 
}

This 2nd block  defines the domain to use for https, the email address to use for the lets encrypt account, it then proxies /emby on port 443 to the emby UI, The communication between the proxy and emby is on HTTP not HTTPS (you can use https if you want).  But as they are on my internal network I don't really care at that point.

Edit:

Just tested with the android app and it seems to work through the proxy

Edit2: Fixed caddyserver url, sorry it's .com not .org

Edited by dragon2611, 20 December 2015 - 11:04 AM.

[Oakington]

Complicated for whom to setup initially? If it is complicated for the user then it won't do what we want. If it is complicated for us, then we can deal.

It would be complicated for us to set up. All the user would have to do is chose a subdomain name.

Sent from my Nexus 6 using Tapatalk

[Oakington]

I haven't tried it for the apps but for the webui I have it sitting behind a reverse proxy.

Currently using CaddyServer - http://caddyserver.org


Config is below - Note mine does more than just Emby and mydomain uses an older SSL cert issued by wosign, mydomain2 is using lets encrypt.

:80 {
redir https://{host}{uri}
}

https://subdomain.mydomain.com {
tls /usr/share/caddy/ssl/mydomain.bundle.crt /usr/share/caddy/ssl/mydomain.key 
log /var/log/caddy/mydomain.log {
rotate {
age 90 }
}
redir /owncloud /owncloud/ 302
proxy /owncloud/ http://10.0.244.184/ {
proxy_header X-Forwarded-For {remote}
proxy_header X-Real-HOST {host}
proxy_header Proxy_hostname {scheme}{host}
}
proxy /emby http://10.0.244.188:8096
}

https://nms.mydomain2.com
log /var/log/caddy/mydomain2.log {
rotate {
age 90 }
}
tls myemail@mydomain.com
proxy / http://10.0.244.193
}



 

For Emby only the config could probably be shortened to. (Note I haven't tested this config for syntax errors, it's possible I might have missed some {} somewhere.

:80 {
redir https://{host}{uri}
}

https://subdomain.mydomain.com {
tls myemail@mydomain.com 
proxy /emby http://<embyIP>:8096 
}
 

Breaking it down as follows:

:80 {
redir https://{host}{uri}
}

This part essentially told the server to listen on port 80 and redirect any request to the same URL but on https (port 443)

https://subdomain.mydomain.com {
tls myemail@mydomain.com 
proxy /emby http://<embyIP>:8096 
}

This 2nd block  defines the domain to use for https, the email address to use for the lets encrypt account, it then proxies /emby on port 443 to the emby UI, The communication between the proxy and emby is on HTTP not HTTPS (you can use https if you want).  But as they are on my internal network I don't really care at that point.


 

Edit:
Just tested with the android app and it seems to work through the proxy

I mean yea, I also run a reverse proxy using nginx on my box as emby is only 1 of a half dozen virtual hosts and uwsgi vassals. But I don't think evey Emby user that wants domain verified encryption should have to know how to setup a reverse proxy. It would be nice if Emby had an easy solution for out of the box encryption. And I think the DDNS is the easiest from the end user's POV.

Sent from my Nexus 6 using Tapatalk

[Luke]

It would be complicated for us to set up. All the user would have to do is chose a subdomain name.

Sent from my Nexus 6 using Tapatalk

 

actually if the ddns is ours then they wouldn't choose anything.

[Oakington]

I took your DDNS idea and ran with it. The DDNS server running BIND9 also hosts an API written in python-flask that will communicate with EmbyServer to register a subdomain and keys with the nameserver, update IP address, and  all necessary communication with LetsEncrypt to get a certificate. Since we have full control over the nameserver, the API will leverage the DNS-01 letsencrypt domain validation method. It registers with LE, gets the challenges, and creates a TXT record for the subdomain.

 

I'll put the API/letsencrypt code up once I remove all my domain specific stuff and make it a config parameter, do a bit of code cleaning, and create a README. I'll also put up an example named.conf.local for the BIND9. 

 

It's not going to work immediately as the DNS-01 validation method is not fully implemented in the public beta of LE as of yet. From the forum posts I've read over there, they're saying sometime in January it will be ready. There is also a limit on the number of subdomains that can have certificates issued to it (not sure about the # ottomh) but this can be overcome by putting the DDNS's hostname into the public suffix list.

 

still todo: 

code up c# parts for EmbyServer

tidy up API and letsencrypt code

wait for DNS-01 validation to go live

get all of this onto an instance and try it out (which arch/distro?)

Edited by Oakington, 29 December 2015 - 12:56 AM.