Jump to content

Setting up SSL for Emby (WIP)


Swynol

Recommended Posts

Tur0k

You know if you are using Lets encrypt certs I think you have to renew your certs every 60 days or so.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

chef

I bought the cert through godaddy before I read through many of the threads here at emby on how to create my own.

Really is starting to get in my nerves.

 

I'm going to test my SSL on line, like mentioned above.

 

Edit: yeah it has been revoked. I'm getting on the phone now with stupid godaddy to find out what the heck is going on.

Edited by chef
Link to comment
Share on other sites

chef

Okay just go off the phone with the cert supplier.

 

They said that the cert wasn't revoked, but that there may be a problem with how it is installed.

 

Just to make sure I haven't complete;y crapped up my emby domain settings.

 

I added the domain name to the advanced settings in emby.

I added the root to the PFX file which was created from my cert and key.

My PFX has no password... (please let me know if someone can hack me with that info and I'll erase this line)

 

This is what is returned when my domain SLL is checked on digicert:

DNS resolves xxxxxxxxxxx.online to ##.##.###.###

HTTP Server Header: Mono-HTTPAPI/1.0

SSL certificate

Common Name = Subject Alternative Names = 
Issuer = Go Daddy Secure Certificate Authority - G2
Serial Number = xxxxxxxxxxxxxxxxxxx
SHA1 Thumbprint = xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Key Length = 4096
Signature algorithm = SHA256 + RSA (excellent)
Secure Renegotiation: Supported
SSL Certificate is revoked

The certificate has been revoked. You should replace it with a new certificate as soon as possible.

OCSP Staple:	Revoked
OCSP Origin:	Revoked
CRL Status:	Revoked

SSL Certificate expiration

The certificate expires February 9, 2018 (235 days from today)

Certificate Name matches 


Subject
Valid from 09/Feb/2017 to 09/Feb/2018
Issuer	Go Daddy Secure Certificate Authority - G2
	 

Subject	Go Daddy Secure Certificate Authority - G2
Valid from 03/May/2011 to 03/May/2031
Issuer	Go Daddy Root Certificate Authority - G2
	 

Subject	Go Daddy Root Certificate Authority - G2
Valid from 01/Jan/2014 to 30/May/2031
Issuer	The Go Daddy Group, Inc.

I removed my IP.

Edited by chef
  • Like 1
Link to comment
Share on other sites

Untoten

 

Hey man, your DNS is in there,  Even with IP removed, DNS will resolve your IP, be careful!

Edited by Untoten
  • Like 1
Link to comment
Share on other sites

chef

Hey man, your DNS is in there,  Even with IP removed, DNS will resolve your IP, be careful!

Right! Thank you!  I removed from the original message. Would you mind editing the quote from your message?

 

Sorry about that.

Edited by chef
  • Like 1
Link to comment
Share on other sites

chef

Hmmm... Emby keeps creating certificates in the SLL folder, they have names which are GUIDs. any reason why that might be causing my issue?

Link to comment
Share on other sites

Swynol

Does that mean Emby is creating self signed certs? You could try removing your .pfx cert and let emby create a self signed. Then connect to emby and see what happens, if in chrome check in Dev tools, security for the cert.

 

On the latest emby server you can now use password protected .pfx you could try creating one with a password, you enter the password on the same page as the path to the cert in advanced - security.

 

 

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Tur0k

Hmmm... Emby keeps creating certificates in the SLL folder, they have names which are GUIDs. any reason why that might be causing my issue?

Are you using a reverse proxy or is the Emby Server publicly facing (meaning you opened a port on your firewall and port-forwarded it to your Emby Server)? 

 

Are you using a publicly trusted SSL or a self-signed one?  Would you check emby to see if the godaddy one is configured to use the correct SSL certificate (Manage server - Advanced - Custom certificate path).  also note that you can use password protected PFX certificates.  non-password protected certs are not a best practice. 

 

Sent from my iPhone using Tapatalk

Edited by Tur0k
Link to comment
Share on other sites

  • 3 weeks later...
chef

@@chef, did you get this figured out?  i specialize in infra so i would love to give a hand!

 

My setup here is completely a mess. I've gotta wait until my SSL is up with GoDaddy, then I was hoping to figure out LetsEncrypt to make my own.

 

unfortunately, my current setup makes it difficult for my mom and dad to visit my domain. They are not tech savvy, and the warning message in Chrome about unsafe SSLs stops them in their tracks. lol.

 

The worst part is that this morning Bell crashed my modem again with their crappy updates, and now my DNS is all messed up and I can't access my domain. 

 

My backup program should have reset the DNS IP at 8:00 this morning. That didn;'t happen which means that my entire Home Automation setup is down as well today. :(

 

The worst!

Edited by chef
Link to comment
Share on other sites

Swynol

i dont think you have to wait until your go-daddy cert expires. you can create a new one at anytime. Well worth using Let's Encrypt aslong as you remember to renew it before the 90 days is up

Link to comment
Share on other sites

  • 2 months later...
feerlessleadr

@@Swynol I'm trying to help set up my friend with a domain and SSL for his emby server, and I'm having a problem. I think I've done everything correct, but whenever I go to emby.hisdomain.com, my browser says that "

This site can’t be reached

emby.hisdomain.com’s server DNS address could not be found."

 

 

When I use his public IP address, I connect just fine and nginx redirects me to his emby server (the first block in his nginx conf). I have the same setup (although I use google domains, he is using namecheap), and while it appears that our domains are set up in the same way, I am obviously missing something. I believe I followed your guide, but I'm not sure what I'm doing wrong.

 

 

Here is a screenshot of his namecheap advanced DNS section (with the relevant domain bits blurred out:

 

 

59bf2e2c4f504_namecheaphelpcropped.png

Link to comment
Share on other sites

Hi @@feerlessleadr

 

the A+ record doesnt look right to me. 

 

if his DDNS address is dns.hisdomain.com then the A+ Dynamic DNS Record should be Host = DNS   Value = His external IP.  you dont need the hisdomain.com after it. The rest of it look correct.

 

you should be able to ping dns.hisdomain.com and it should return his external IP same with emby.hisdomain.com. if it isnt returning the IP or doesnt find it then its the A+ record causing issues

 

 

 

EDIT: its also the same for the acme_challenge you only need the subdomain not the full address. so for example   host =  _acme_challenge.emby   

Also for another Test you could create an A record. Host = Test       Value = {external IP}   then to test you can browse to test.hisdomain.com and as long as NGINX has a server block for test.hisdomain.com you should get a connection

Edited by Swynol
  • Like 1
Link to comment
Share on other sites

feerlessleadr

Thanks for the help, that fixed it.

 

One more question. All of the domains are coming back with the green https with the exceptions of 1, where my browser is giving me the error:  "NET::ERR_CERT_COMMON_NAME_INVALID"

 

Any idea what could be causing this for just 1 of the sites?

Link to comment
Share on other sites

does your certificate cover that subdomain? so for example if sonarr.hisdomain.com was giving that error is that subdomain listed on the cert?

 

if you browse to the one causing the error. if your using chrome go to tools > More Tools > Developer Tools > Security Tab

 

it should show you the certificate that you are using. View the cert and go to Details tab. Check the SAN (Subject Alternative Name) make sure the URL matches it exactly.

 

 

I have also seen this issue before when you connect from externally to your NGINX box with your Lets Encrypt cert, then NGINX connects to the backend service using a Self Signed Cert. So for example, if you go to sonarr.hisdomain.com NGINX matches it to a server block which forwards it to Sonarr. The connection from NGINX to Sonarr is setup to use SSL but a self signed cert. Self signed certs tend to use a CN or Common names where as a valid Lets encrypt cert uses a trusted Lets Encrypt CN and then use SAN or Subject Alternative Names for your domains/sub domains.

 

 

Also something else to check. i cant remember if this gave the same error or something different but if that service is using any external source for images or something else you need to make sure those sources use https. I used some custom CSS for my emby server, i hosted images on imgur and in the CSS i pointed it to HTTP://imgurl....I had an error but cant remember what the message was. anyway changing the external sources to HTTPS://imgurl fixed it. If you look at the security tab in chrome it should say if this is the case.

  • Like 1
Link to comment
Share on other sites

feerlessleadr

does your certificate cover that subdomain? so for example if sonarr.hisdomain.com was giving that error is that subdomain listed on the cert?

 

if you browse to the one causing the error. if your using chrome go to tools > More Tools > Developer Tools > Security Tab

 

it should show you the certificate that you are using. View the cert and go to Details tab. Check the SAN (Subject Alternative Name) make sure the URL matches it exactly.

 

 

I have also seen this issue before when you connect from externally to your NGINX box with your Lets Encrypt cert, then NGINX connects to the backend service using a Self Signed Cert. So for example, if you go to sonarr.hisdomain.com NGINX matches it to a server block which forwards it to Sonarr. The connection from NGINX to Sonarr is setup to use SSL but a self signed cert. Self signed certs tend to use a CN or Common names where as a valid Lets encrypt cert uses a trusted Lets Encrypt CN and then use SAN or Subject Alternative Names for your domains/sub domains.

 

 

Also something else to check. i cant remember if this gave the same error or something different but if that service is using any external source for images or something else you need to make sure those sources use https. I used some custom CSS for my emby server, i hosted images on imgur and in the CSS i pointed it to HTTP://imgurl....I had an error but cant remember what the message was. anyway changing the external sources to HTTPS://imgurl fixed it. If you look at the security tab in chrome it should say if this is the case.

 

Bah - you are right, there was a spelling error for the site name. Thanks!

Link to comment
Share on other sites

  • 1 month later...
drikosv8
Folks,

 

I'm in serious trouble.

 

I do not have https on my server and some clients are downloading and capturing my links from the server.

 

If I subscribe to an https SSL service, will I solve this problem?

 

I've been thinking about a No-ip service, will it solve?

 

 

Thank you for your help

 

 

 

 


Pessoal,

 

Estou com sérios problemas.

 

Eu não tenho https no meu servidor e alguns clientes estão baixando e capturando meus links do servidor.

 

Se eu me inscrever em um serviço https SSL, eu resolvi esse problema?

 

Estive pensando em um serviço de No-ip, ele resolverá?

 

 

obrigado pela ajuda

Link to comment
Share on other sites

Swynol

Sort of follow on from this thread - https://emby.media/community/index.php?/topic/47508-how-to-nginx-reverse-proxy/ and this thread - https://emby.media/community/index.php?/topic/44757-setting-up-ssl-for-emby-wip/ 

 

 

This is an alternate way to get a SSL cert, this replaces Part 3 on this thread.

 

Ok so SSLforFree and ZeroSSL both offer a way to get a cert using your browser and DNS verification. The problem with DNS verification which I and others have experienced is that it can take long time to setup depending on how many subdomains you have, DNS replication and other third party factors also contributed to issues. This guide will show you how to use NGINX for Windows and ZeroSSL le.exe tool. This uses HTTP verification and is almost automated and only takes a few mins to run after its been initially setup.

 

ZeroSSL - https://zerossl.com/ and the Windows Tool is available on github -  https://github.com/do-know/Crypt-LE/releases

 

Download above and extract it. I recommend C:\LE64

 

We now have to amend our NGINX config to include the below in each of our server blocks.

location ^~ /.well-known/acme-challenge/ {
}

here is my emby example block

##EMBY Server##
	
	server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name emby.mydomain.com; 
	
	include ssl.conf;
    	
     location / {
        proxy_pass http://127.0.0.1:8096;  

	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;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
		proxy_buffering off;
		}
	location ^~ /.well-known/acme-challenge/ {
}
	

}

Notice my SSL settings are missing. they are included in a separate file, i will post the contents below for anyone interested.

include ssl.conf;

Now we have the .well-known\acme-challenge location set we can run the le64.exe tool.

 

Open a cmd prompt (run as administrator)

le64.exe --key account.key --email "admin@mydomain.com" --csr domain.csr --csr-key domain.key --crt domain.crt --domains "mydomain.com,emby.mydomain.com,www.mydomain.com,plex.mydomain.com" --generate-missing --unlink --path E:\NGINX\html\.well-known\acme-challenge

from the above you need to change

 

--email "admin@mydomain.com" - to your email address keeping the ""

--domains "mydomain.com,emby.mydomain.com"   (list all your domains you want the cert to cover - i think max is 50~)

--path E:\NGINX\html\.well-known\acme-challenge   (change E:\NGINX to your NGINX locaiton, keeping the html\.well-known....

 

when you hit enter it will test your setup for the correct files and config, it basically gets a fake certificate. if this completes with no errors you now need to add the argument --live to the end of the script above, like so 

le64.exe --key account.key --email "admin@mydomain.com" --csr domain.csr --csr-key domain.key --crt domain.crt --domains "mydomain.com,emby.mydomain.com,www.mydomain.com,plex.mydomain.com" --generate-missing --unlink --path E:\NGINX\html\.well-known\acme-challenge --live

hit enter and it should go off an fetch your real domain.csr account.key and domain.crt and domain.key. these will be downloaded into the le64 folder. Keep the csr and account.key safe, you will need these for renewal.

 

Now you have all this setup you can re-run the above le64.exe script come renew and its all done.

 

 

My next plan is to somehow automate coverting crt to pem and pfx. which would then mean the whole SSL renwal process is completely automated.

Link to comment
Share on other sites

Just curious is there a reason why SSL is so difficult for Emby Server to implement easily? 

 

Why can't you just have Emby Server create a self signed certificate and force SSL connection? 

 

That seems pretty simple to me?

Link to comment
Share on other sites

Just curious is there a reason why SSL is so difficult for Emby Server to implement easily? 

 

Why can't you just have Emby Server create a self signed certificate and force SSL connection? 

 

That seems pretty simple to me?

 

Because pretty much every device will reject the self signed cert and most of the time there isn't a way to override that and force it to accept that.

 

So when the device rejects the cert it will look like a connection error and users will just come here and tell us that it "doesn't work".

Link to comment
Share on other sites

@@Luke can you not put some logic into the device apps that if certificate is self signed from the actual Emby Server the device is connecting to, to then accept it? If certificate is not issued by the Emby Server (or a public certificate) then to reject it?

 

Most applications/servers opensource etc all use self signed certs and unless you want to pay the money for a public certificate a self signed one works fine.

 

Even simple web browsers work fine with self signed certs, they give you a screen telling you its self signed and ask if you wish to proceed.  The data is still encrypted and there is no difference to the end user.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...