How to Configure SSL Support

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[Koleckai Silvestri 1150]

I am just using the self-signed certificate right now. No reason to spend money on a certificate unless you're going to be broadcasting to the public. A self-signed certificate will still encrypt the data to your private devices and since you don't need merchant insurance, then anything higher than 128-bit encryption doesn't add much.

 

Of course this may change when clients actually support it.

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[Koleckai Silvestri 1150]

I am well aware of the risks which is why it is currently restricted to a single IP address via my router. Just waiting for some client support and will go from there.

 

Anyway, good luck in finding your answer.

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[Luke 37096]

yea i'm sure eventually we'll be able to use certs that are installed on the server, but that will take longer because we have to implement, test and support individually for every server operating system. In the meantime, pointing to the pfx file will work.

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[moviefan 184]

Instead of going through the process of converting it back to a PFX without a password just create the PFX when you get the cert back from the CA.

 

Here are the steps I followed:

 

1)  openssl req -new -nodes -out mb.csr -keyout mb.key

2) Answer the prompts when asked.  Only important one is common name which much match DNS name.

3) Take the mb.csr and submit to CA

4)  Obtain certificate from CA, rename to mb.cer.  Put in same directory as mb.key you created in step 1

5)  openssl pkcs12 -export -in mb.cer -inkey mb.key -out mb.pfx

6) Just hit enter when it asks for password.  Both times.

 

You now have a pfx file you should be able to use with MB.

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[somy 24]

Hi, I'd like to ask does SSL work with MB connect? Thanks!

[jhoff80 87]

 

Researched the code and it uses OpenSSL.  The current requirement is to generate a PFX file without a password (not allowed by Windows tools) which is required by MediaBrowser.  This is accomplished using OpenSSL tools to convert the Windows exported PFX to a PFX file without a password.

1. Starting by having a certificate with a private Key on your Windows machine (MMC/Local Comp/Personal) then follow this process Exporting/Backing Up to a .pfx File  and REMEMBER PASSWORD.  Name the file X:\OpenSSL\certname.pfx
2. Download OpenSSL binaries.  Personally, I used this for x64 windows. Extract to a directory X:\OpenSSL.
3. Run Command (Cmd.exe) prompt and navigate to X:\OpenSSL directory (source). 

4. openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes 
   openssl pkcs12 -in certname.pfx -nokeys -out cert.pem
   openssl rsa -in key.pem -out server.key 
   openssl pkcs12 -export -out MediaBrowserCert.pfx -inkey server.key -in cert.pem
   

   Note 1 - Password on Line 1-3.  Use password from step #1 when you exported the .pfx file.

   Note 2 - Password on Line 4.  Hit enter (leave blank) when asked for password twice when asked.  This is very important or else steps 2-3 we're redundant if the PFX password has a password (which is currently not supported by MBS. 

   Note 2 - 4th line modified command from this post by @MBNWA 

Victory!  My family can now browser to https://media.%mylastname%.net and the MediaBrowser logon page loads.

 

Thanks for this, this was really helpful.  I already had the certificate installed for Windows itself as part of my 2012r2 Essentials setup, but wouldn't have been able to convert it to the proper PFX type file without this guide.

[studio-jurdan 9]

lol, it's ok, but a Certificate without password is not and never be a valide certificate. i have some real certificates and as i can read here, i think they never be usable with emby that not suport valid cert !

[Raff 51]

lbut a Certificate without password is not and never be a valide certificate.

It is a valid certificate, and can be used to create secure connections. There is a lot of PII removal going on in this thread, so I am not sure what the point of the OP was, but I assume it is using your own cert with HTTPS. I'd guess that Emby can't use one with a passphrase since you would have to type it in every time it restarted.

 

Here is what O'Reilly has to say on the matter:

 

 

In theory, the advantage of having a passphrase is that it increases protection. However, in practice the passphrase doesn't actually give that much protection. If someone can read or copy the private key, then they already have root-level access to the system and could obtain the passphrase, for example by using a program like keylogger. A passphrase will protect against script kiddies, but not against a serious hacker. For most people it's probably not worth using one.

Cite: http://www.onlamp.com/pub/a/onlamp/2008/03/04/step-by-step-configuring-ssl-under-apache.html

 

Now, if you were using the cert for something else other than HTTPS, I may agree with you that it is certainly not optimally secure, but then as Heartbleed taught us - there is no perfect security, it is all about risk mitigation. I would (do) use a passphrase on my ssh keys for example.

 

I'm curious what attacks you believe can be made, that don't require stealing the private key in the first place.

[studio-jurdan 9]

NO one certification syst can make a certificate without password, a have 4000 certificate for 13 industry and NEVER, NEVER  i was able to make one without passwortd. NEVER.

 

 

ANd all my certificate  BUYED, class 1, 2 an 3  are signet with passowrd so, no one is usable here !!!!!!!!!!!!!!!!!!!!

 

Without paraphrase i can crack your certif in 10 minute, you need to try? i pay 4 ingeneer to help you to understand if you need. 

 

I'd contacted open ssl too, becaus the possibilitie to make certf without paraphrase is a BIG, real enormous mistake all the cerif industry will be bad with this big mistake

Edited July 28, 2015 by studio-jurdan

[moviefan 184]

NO one certification syst can make a certificate without password, a have 4000 certificate for 13 industry and NEVER, NEVER  i was able to make one without passwortd. NEVER.

 

 

ANd all my certificate  BUYED, class 1, 2 an 3  are signet with passowrd so, no one is usable here !!!!!!!!!!!!!!!!!!!!

 

Without paraphrase i can crack your certif in 10 minute, you need to try? i pay 4 ingeneer to help you to understand if you need. 

 

I'd contacted open ssl too, becaus the possibilitie to make certf without paraphrase is a BIG, real enormous mistake all the cerif industry will be bad with this big mistake

 

Certification systems can make certificates without passwords.  They are less secure.  But it can certainly be accomplished.  I provided steps above for how to do this.

 

Certificates aren't password protected anyway.  It's their private keys that are.

[studio-jurdan 9]

lol wirhout paraphrase i can crack your certt in 10 minutes.  and... i'm BELGIUM  and ALL BELGIAN people have a CLASS 2  cert in there ID card and we have all a card id reader in our PC. but password is needed to take your id card in the office that give them.

 

i suggest you to read the usage off certificate. and you'll see taht how it is easy to bring a cert without paraphrase. the paraphrase is th KEY to obtrain something working. and must be very diificult paraphrase not a "1234"  butr somthing like "DerDD,juioj8526€"   and ONLY at this time you can HOPE for SOME security level.

 

Openssl have a error off usage , it must fore you tu use a paraphrase like all other are doing. this will be corrected soon  ;-)

Edited August 2, 2015 by studio-jurdan

[studio-jurdan 9]

FOr peolpe that can thinks 2 minutes, when you make a cert, you give some info and a PARAPHRASE.

when ytour cert is on line, all the info are readable (but not the paraphrase)

so if you don't use a paraphrase i can make exacly the same cert without paraphrase with your other infos redable on thye cert.

SO after 3 minute have got a copy off ytour cert, and your private key TOO ;-)  security of these cert  nearly 0.00001%

Edited August 2, 2015 by studio-jurdan

[moviefan 184]

studio-jordan I'm not sure if it's just your english skills that are weak but given these last two posts you seem very confused on the difference between a public SSL certificate and a private decryption key.

 

You do not give the private decryption key when "your cert is online."  You are just providing the public information about how to encrypt a message that the private key will decrypt.  And there is no password or passphrase needed for a public cert when using SSL/TLS.  If this was required then you would need to obtain a password for every site you use HTTPS on prior to browsing.

Edited August 3, 2015 by moviefan

[Lumute 89]

Hi Guys,

 

I too was just configuring Emby to use my own SSL certificate. I have a wildcard certificate that i use for everything (email server, and others) and wanted to use it for Emby. Now I do agree that not having a password on the file in order to access the private key does not make the certificate invalid, but it certainly makes me feel uneasy having this PFX file lying around in the file system without a password...

 

Of course there are other ways to extract Private Keys, I once lost my PFX file and after a couple of hours or research and googling around was able to export it from the Windows Certificate Store even though it was marked as not exportable. There will always be a way but not having a password on a file its like saying you don't put a lock on your house's main door because a good locksmith can still open it...

 

I don't know the ins and outs of how Emby's web server works so please forgive me if I am oversimplifying things, but should be possible to import the certificate's private key into some kind of encrypted certificate store to be used by Emby's web server, and then ask for the password when the certificate file is imported using the Web GUI.

[Raff 51]

Hi Guys,

 

I too was just configuring Emby to use my own SSL certificate. I have a wildcard certificate that i use for everything (email server, and others) and wanted to use it for Emby.

I definitely wouldn't use the same cert - but if you must (or really want to) then yes, you need to treat it a lot more secure than if it was just for creating HTTPS connections to Emby. The moment it is protecting PII (Personally Identifiable Information) you definitely need a passphrase, but that is not what we were talking about above. You probably want to check into getting certs for specific purposes, since wildcard certs scare me and once upon a time there were a lot of cheap/free cert providers that likely can meet your security needs.

 

If you have PII in Emby, you probably need to rethink what security you need - but that can be a discussion all its own.

 

but it certainly makes me feel uneasy having this PFX file lying around in the file system without a password...

It should - but that is my point above. You don't leave it lying around! Studio-Jurdan was blathering on about how fast his team could crack it, but missed the point that he has to get it first. Once you have your key you put it in a secure location. Any remote attacker who can access your keystore likely has root/admin permissions and can do a lot more damage than pulling your key. Assuming this is just for HTTPS, not only do they have to take your key but they also have to poison DNS to use it!

 

There are many more nefarious things to do if you have that access. HTTPS is designed to prevent snooping and provide reasonable confidence the site you are connected to really is where you want to go. It does not provide Authentication - your users still have to log in. If you can access the keystore, you have pretty much complete control over the server - snooping is trivial and the PK doesn't matter. As for cloning your site (the confidence in the endpoint) that is a lot of work to steal a handful of passwords. It would be WAY easier to hit the original server with a keylogger!

 

Of course there are other ways to extract Private Keys, I once lost my PFX file and after a couple of hours or research and googling around was able to export it from the Windows Certificate Store even though it was marked as not exportable. There will always be a way but not having a password on a file its like saying you don't put a lock on your house's main door because a good locksmith can still open it...

Yes - admin and local access opens up a ton of ways to get into "secure" areas of your computer. That is by design in most user level OSs - don't want to brick grandma's computer because she forgot her password. Assume we are just talking HTTPS, a better analogy is "I am putting a padlock on my shed instead of thumbprint scanner because if they really want my lawnmower they are going to break the door. Once they do that, they can take whatever so why would they want my broken lawnmower?"

 

Leaving your door unlocked is called HTTP.

 

I don't know the ins and outs of how Emby's web server works so please forgive me if I am oversimplifying things, but should be possible to import the certificate's private key into some kind of encrypted certificate store to be used by Emby's web server, and then ask for the password when the certificate file is imported using the Web GUI.

If Emby is anything like my various servers, you have to provide the passphrase every time you restart the server. This means Emby must have access to (store) the passphrase to do it automatically. Instead of needing an exploit in the OS to root the server, now I just need an exploit in Emby, the .NET library, whatever webserver platform Emby runs on, etc. The term used is "Surface Area" when you talk about points of attack. Increasing surface area (and providing a false sense of security) are two big bad ideas.

 

I am not aware of a "automated keyring/wallet" system that has been vetted by security professionals, but it may be out there. I'm not sure it actually solves the "Emby must know something to access the info, so compromising it compromises my core security" issue but I would be willing to listen to arguments. Personally, I use separate certs for separate concerns with each at the appropriate level of security. As an additional disclaimer, all my certs do have passphrases but I don't use certs for my vanity blog (because it is HTTP and who cares?) or Emby (because it is local only and if you can get past my firewall into my LAN, I probably have more serious issues than you taking my media).

[Lumute 89]

Hi Raff, thanks for the comments.

 

I ended getting a free StartCom certificate just for this. Nothing wrong with wildcard certificates as long as you properly used them and protect them.

 

I'm not concerned at all about someone someone going though the trouble of hacking my Emby install to get to my movie library, there's tons of sites out there that give you all the content you could ever want for free and without having to do any hacking. Nor I am a celebrity (yet?) so my personal videos are quite boring. It does concern me that someone can hack into my Emby to gain access to other things, that's why it sits on a DMZ segragated from my network as any Front End server exposed to the world should be. In my opinion security is all about making it difficult so the work is not worth the prize, there will always be a way to do it.

 

Why am I using SSL in Emby then? the only thing that really concerns me is the snooping of the traffic, specially by my ISP, that's about it. But implementing this should not compromise my other systems.

 

I think you missed the point on my analogy, I'm in no way discussing the security aspects of HTTP vs HTTPS, my post was about the security implications of having a certificate private key in a file in the file system without a proper password on a server that's considered a Front End server. To be honest this is the first time I've encountered a server that requires the private key file without a password instead of importing it into an encrypted store, maybe I have not worked with that many but at least IIS, Juniper and Watchguard SSL VPN software and HTTPS proxies, ISA and Forefront do it that way...

 

I don't understand either why you think you are increasing what you call the "Surface Area", Emby will have the private key in any scenario you can think of so all that area is already exposed. So importing the private key into an encrypted store and not leaving it in an unprotected file is actually reducing that surface area.

 

In any case, I am happy with this now that I use the StartCom cert, but I still think this is not a good practice...

Edited August 5, 2015 by Lumute

[Raff 51]

Looks like we are actually on the same page, were it not for my brain jumping back and forth between discussing certs in general and my personal opinions on wildcard certs.

 

I ended getting a free StartCom certificate just for this. Nothing wrong with wildcard certificates as long as you properly used them and protect them.

 

My primary issue with wildcard certs is simply putting all your eggs in one basket, but YMMV. You clearly understand the importance in protecting them, which I feel becomes more difficult the more services that use them. In Emby's case, it doesn't work because you have two very different security concerns and capabilities of the application - but you already figured that out. I personally have different services bound to different subdomains so it makes sense for me to use different certificates so one being compromised doesn't impact others.

 

 

I think you missed the point on my analogy, I'm in no way discussing the security aspects of HTTP vs HTTPS, my post was about the security implications of having a certificate private key in a file in the file system without a proper password on a server that's considered a Front End server.

I was objecting to the "don't put a lock on the door" statement. No lock is HTTP in my opinion. A weak cert (one using deprecated encryption as well as no passphrase) is like a simple padlock - keeps out snoopers. Certs without passphrases would have to rely on the file system and the application using it to keep safe, but that isn't the same as leaving the door open.

 

I don't understand either why you think you are increasing what you call the "Surface Area", Emby will have the private key in any scenario you can think of so all that area is already exposed. So importing the private key into an encrypted store and not leaving it in an unprotected file is actually reducing that surface area.

I was thinking about your wildcard certificate - not the principle in general. You could have it installed in your web server, your mail server and sftp/ftps/ssh server, etc. Adding Emby just means there is one more point of attack. Originally, there were a few vectors that may have some bug and adding Emby would make it one more. The villain just needs to find the weakest link among them, often with a quick port scan. Now that it has its own certificate, it has the same surface area of attack regardless.

 

Anywho, for what my opinion matters, I think you made the right decision and maybe this discussion will help someone else.