Jump to content

Setting up SSL for Emby (WIP)


Swynol

Recommended Posts

Tur0k

Hey everyone,

 

First off I want to thank Swynol for putting in the effort to create this guide!

 

I'm currently trying to set this up so I can finally use my setup externally, but I'm struggling with Part 1a.

 

I bought my domain name via 123-reg, have created an account with no-ip to configure the DynDNS and can do this via my BT Homehub but as stated previously this will result in cert errors due to the domain mismatch.

 

Has anyone managed to complete Part 1a through 123-reg that can give me some help?

 

 

So, Dynamic DNS/A+ custom records essentially grant home users the ability to bind their domain DNS records to non static public IP addresses. This is useful because without purchasing a static IP address from your ISP your WAN public IP address could change. Dynamic DNS/A+ custom DNS records allow users to update their DNS records when their WAN IP address changes.

 

I am pretty sure that namecheap gives their customers access to manage their DNS, as well as, create dynamic DNS/A+ custom records when you register a Domain with them. I also know that google domains gives their customers access to manage their DNS, as well as, create dynamic DNS/A+ custom records when you purchase a domain with them. In the US i would expect this to cost somewhere around $10-$20 annually. I did some checking and it would appear that 123-reg gives users access to manage their DNS records but does not give them access to create dynamic DNS/A+ custom records directly. It seems that they want you to create a CNAME record in your public DNS config to redirect your 123-reg purchased domain to a separately hosted DDNS service record with dyndns/noip/etc.

 

1. Have you successfully configured your No-IP account and domain?

2. Have you conigured a dynamic DNS client to update your No-IP domain with your home's public WAN IP address?

3. have you created a CNAME to redirect a subdomain in your 123-reg domain to your no-IP domain?

myhome.mydomain.com -> myhouse.ddns.net

if you have completed steps 1-2 you should be able to complete step 3 based on the following link:

https://www.123-reg.co.uk/support/crmfileserver/UK/Root/Downloadable%20Guides/DNS%20Management/DNS%20Management%20guide.pdf

Edited by Tur0k
Link to comment
Share on other sites

aptalca

You know, you guys can also just get a dynamic dns url from duckdns. It's completely free, and it doesn't require any additional steps to renew or reactivate. It's super easy to renew the ip.

 

You can get up to 5 subdomains like yourcustomdomain.duckdns.org and it also allows unlimited sub-subdomains like www.yourcustomdomain.duckdns.org

 

And the best part is, you can get letsencrypt certs for these subdomains

Link to comment
Share on other sites

pr3dict

Ahh okay. some of the many benefits of a reverse proxy are:

A. All access from the public Internet comes from either port 80 (unsecured) or port 443 (secured).

B. No server aside from the reverse proxy receives transmissions directly from the public Internet (this helps to limit the vulnerable surface area of attack on your network).

C. present web services from different systems as though they are one contiguous directory structure.

D. You only need 1 domain for the reverse proxy.

E. You only need 1 public DNS record for the 1 reverse proxy.

F. You only need 1 signed SSL certificate for the reverse proxy (that matches the above domain).

 

So, to the best of my knowledge, to do what you want to do with sub-domains you would need:

1. A separate A, AAA, CNAME, or A+ record to your Public Internet DNS (this is likely accessible in your domain registrars domain management interface) for each sub-domain (Example: emby.mydomain.com, homeautomation.mydomain.com, etc) this will allow public Internet sources to resolve your subdomains to your publicly accessible IP. these records will need to be configured to point to your WAN IP using some type of DDNS (unless you have a static WAN IP address).

2. You will end up needing an SSL certificate for each sub-domain (Unless you are using a wildcard SSL certificate).

3. If you only have 1 WAN IP address (and not a block of public IP addresses to use) and want to host multiple web services on it, each web service will need a unique TCP port to listen on. You will end up creating firewall rules on your WAN firewall to open and forward each port through to the appropriate systems on your internal network.

4. I don't know that you can configure a single instance of a reverse proxy to listen on different ports in order to: delivering differnet SSL certs depending on listening port, as well as, deliver different content based on listening port. if this isn't the case then you may need to host a separate reverse proxy for each port you are listening on. At this point I don't know that you need a reverse proxy for what you are trying to do with the separate sub-domain structure.

So after a night of a little frustration I got everything working semi perfectly.

 

Basically I have a few services listening under 1 public ip address using a bunch of different ports.

 

What I did was I got a domain, I setup a bunch of subdomains as cnames to point to the original domain.

 

Setup a reverse proxy to offload ssl once it gets inside the network so anyone that tries to reach *.mydomain.com will have ssl on port 443 so no need to add ports at the end. Then depending on the subdomain/host they were trying to reach the reverse proxy will route to the correct inside server on whatever ip address/port they are on. This is especially important for services on the same internal ip address. This allows me to have different dns records for the same internal ip address which is really cool. Also because of the wildcard everything has a great ssl rating.

 

The only thing I need to setup is the 503 error page so that when people that are not allowed d to access certain pages don't just go to 503 error. I may redirect them somewhere else but not sure yet.

 

The purpose of this was so that I could have a very easy name schema to remember and not have to type in ports at the end of all the names. Makes it super easy and secure that the proxy is the hub for everything. My only concern is that haproxy which is what I'm using seems to bypass firewall rules in pfsense, leaving security on haproxy as the only line of defense.

 

Sent from my VS987 using Tapatalk

  • Like 1
Link to comment
Share on other sites

Tur0k

So after a night of a little frustration I got everything working semi perfectly.

 

Basically I have a few services listening under 1 public ip address using a bunch of different ports.

 

What I did was I got a domain, I setup a bunch of subdomains as cnames to point to the original domain.

 

Setup a reverse proxy to offload ssl once it gets inside the network so anyone that tries to reach *.mydomain.com will have ssl on port 443 so no need to add ports at the end. Then depending on the subdomain/host they were trying to reach the reverse proxy will route to the correct inside server on whatever ip address/port they are on. This is especially important for services on the same internal ip address. This allows me to have different dns records for the same internal ip address which is really cool. Also because of the wildcard everything has a great ssl rating.

 

The only thing I need to setup is the 503 error page so that when people that are not allowed d to access certain pages don't just go to 503 error. I may redirect them somewhere else but not sure yet.

 

The purpose of this was so that I could have a very easy name schema to remember and not have to type in ports at the end of all the names. Makes it super easy and secure that the proxy is the hub for everything. My only concern is that haproxy which is what I'm using seems to bypass firewall rules in pfsense, leaving security on haproxy as the only line of defense.

 

Sent from my VS987 using Tapatalk

Now that is pretty cool. I was playing with HAproxy yesterday as I would like to look at the performance differences between the two.

So do you only have 1 port (443) punched in your firewall for the haproxy and HAproxy then determines the peer website by the sub-domain request of the client?

 

I am running into a little trouble finishing up my reverse proxy config because my home automation non-HTTPS management interface passes absolute links when navigating the site. This causes trouble for my my subcontainer config of myhome.mydomain.com/HA

Is rewritten to:

myhome.mydomain.com/subcontainer

whenever I try to navigate inside the site. When it should be:

myhome.mydomain.com/HA/subcontainer

 

I have not found a way to rewrite the absolute URL to the right way yet. Using the sub-domain I may be able to get it working, but I don't think that the squid reverse proxy can handle that, so I may be making the jump to HAproxy sooner than later.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

pr3dict

Now that is pretty cool. I was playing with HAproxy yesterday as I would like to look at the performance differences between the two.

So do you only have 1 port (443) punched in your firewall for the haproxy and HAproxy then determines the peer website by the sub-domain request of the client?

 

I am running into a little trouble finishing up my reverse proxy config because my home automation non-HTTPS management interface passes absolute links when navigating the site. This causes trouble for my my subcontainer config of myhome.mydomain.com/HA

Is rewritten to:

myhome.mydomain.com/subcontainer

whenever I try to navigate inside the site. When it should be:

myhome.mydomain.com/HA/subcontainer

 

I have not found a way to rewrite the absolute URL to the right way yet. Using the sub-domain I may be able to get it working, but I don't think that the squid reverse proxy can handle that, so I may be making the jump to HAproxy sooner than later.

 

 

Sent from my iPhone using Tapatalk

The way you described everything is correct. I did a lot of research on the haproxy vs nginx vs apache and I was hesitant to use haproxy but because I'm not hosting a web server and I didn't have to spin up another VM I figured I'd give it a try and it works perfectly.

 

Also the reason I used subdomains vs directory folders to route was the absolute link issue you described. I haven't run into that problem yet with the subdomains... You will need a wildcard ssl cert which costs money. Then you can offload the ssl from the the proxy and not worry about hosting ssl on the individual servers. Haproxy can also do ssl pass through in raw tcp forwarding but that's more intricate then Im ready for also I don't need that level of security on the private side of my router.

 

Sent from my VS987 using Tapatalk

  • Like 1
Link to comment
Share on other sites

Tur0k

The way you described everything is correct. I did a lot of research on the haproxy vs nginx vs apache and I was hesitant to use haproxy but because I'm not hosting a web server and I didn't have to spin up another VM I figured I'd give it a try and it works perfectly.

 

Also the reason I used subdomains vs directory folders to route was the absolute link issue you described. I haven't run into that problem yet with the subdomains... You will need a wildcard ssl cert which costs money. Then you can offload the ssl from the the proxy and not worry about hosting ssl on the individual servers. Haproxy can also do ssl pass through in raw tcp forwarding but that's more intricate then Im ready for also I don't need that level of security on the private side of my router.

 

Sent from my VS987 using Tapatalk

So, I couldn't figure out how to override the absolute URL problem outside of using subdomains instead of subdirectories. This would mean I would be in for at least another $90 annually from comodo (they were the cheapest I found) for a wildcard SSL if I couldn't figure out how to get the squid reverse proxy to use two different SSL certs based on URL request. The additional cost would cost me WAF points.

I got no replies from the PFsense forum on how to get squid reverse proxy to use different SSL certs based on the endpoint url request.

I read up on HAproxy and was confident I could configure it to use different SSL certs based on the endpoint URL request or the SNI TLS request.

 

I installed the HAproxy package and spun down my squid reverse proxy and spun HAproxy it up. Most of the guides I read were not well developed and didn't explain options at all. I read through the HAproxy PFsense docs and the HAproxy documentation on 1.7 and worked to get 2 of my web services (Emby https, and my http only web service) hosted on two separate third level domains under my 2nd level domain.

Sub1.mydomain.com

Sub2.mydomain.com

I assumed that this would be an effective test in order to determine if I can move forward.

 

In my ACME client, I setup an SSL cert request for:

Sub2.mydomain.com

 

In my public DNS for my domain I had to create a CNAME for:

Sub2.mydomain.com

And a TXT custom record in order to get a Let's encrypt SSL certificate for:

Sub2.mydomain.com

 

I already had this configured for:

Sub1.mydomain.com

 

In my ACME client I completed the issue for the SSL cert for:

Sub2.mydomain.com

 

In HAproxy, under the setting menu I enabled HAproxy and set my maximum number of connections. I left all else defaulted.

 

I setup 2 back end server pools, one for each service named sub1_8920 and sub2_80). For the moment I am not doing any health check or stats monitoring on them.

 

I then created a single front-end config for the WAN IPv4 address on port: 443, and enabled SSL offloading. I gave it a type of:

Http/HTTPS (offloading)

NOTE: this is important if you want to handle SSL from your proxy and not at the backend server. This setting has an effect on which ACL expressions are available.

 

I created an ACL for my sub2 subdomain named sub1_acl with an expression of:

Host starts with:

And a value of:

Sub2

 

NOTE: I had to do it third level domain only, with no domain.com otherwise it would never work.

 

I then created an action of:

Use back end

Selected "sub2_80"

And listed the above acl name (sub1_acl) in the condition field.

 

I set the default backend to:

sub1_8920

 

I checked the box for:

use "forwardfor" option

 

I set the certificate field to my Let's encrypt cert for:

Sub1.mydomain.com

I checked the boxes for:

Add ACL for certificate common name

NOTE: this configures an ACL to use this cert when the SNI TLS Request matches the cert's identifies CN (FQDN). So when you request the TLS cert for "Sub1.mydomain.com" HAproxy will give you this certificate.

 

In the additional certificates field I added the SSL certificate for:

Sub2.mydomain.com

I checked the box for:

Add ACL for certificate common name

NOTE: this configures an ACL to use this cert when the SNI TLS Request matches the cert's identifies CN (FQDN). So when you request the TLS cert for "Sub2.mydomain.com" HAproxy will give you this certificate.

 

I already have the hole for port 443 punched in my firewall-rules, so I didn't have to worry about that.

 

Currently, HAproxy is working perfectly with both subdomains, both certificates, and both web services. I am not having trouble with absolute URL redirection and have not seen any issue with headers.

 

 

My next steps are to

1. setup an HTTP redirect to push all http requests to https port 443.

2. See if it is possible to get client authentication working so that only end point clients with a cert I gave them can access my equipment from the public Internet.

3. ensure I have hardened this implementation (ensure I am following security best practices, check performance, and configure monitoring and logging)

4. Ensure that my SSL configuration is A+ rated.

 

Sent from my iPhone using Tapatalk

Edited by Tur0k
Link to comment
Share on other sites

Swynol

Hey everyone,

 

First off I want to thank Swynol for putting in the effort to create this guide!

 

I'm currently trying to set this up so I can finally use my setup externally, but I'm struggling with Part 1a.

 

I bought my domain name via 123-reg, have created an account with no-ip to configure the DynDNS and can do this via my BT Homehub but as stated previously this will result in cert errors due to the domain mismatch.

 

Has anyone managed to complete Part 1a through 123-reg that can give me some help?

 

Also, I'm in the process of creating an AD domain for testing and might eventually host my own web server so what's the best way of implementing a reverse proxy? I have enough hardware to host many VMs on site so you ideally like to have a setup that splits the reverse proxy, web server and any other required systems I need on to their own VMs.

 

I'm comfortable with complicated VM setups as I do this at work, but proxies and firewalls and things are something that I've not done much with outside using pre-configured systems.

 

Will nginx work fine in this config or am I complicating things more than I need?

 

Thanks,

 

M_Taylor40

 

 

Sorry i havent replied sooner i have been away. 

 

Ok with no-ip is your dynamic DNS something like MYDOMAIN.no-ip.info?  if so then yes that would cause a cert mismatch as when you navigate to emby.MYDOMAIN.com it forwards you to MYDOMAIN.no-ip.info which you dont have a cert for. 

 

not familiar with 123.reg  but what you need is a registrar that you can park your domain name at and that supply you with a dynamic DNS service. The reason is you need your Dynamic dns to be something like DDNS.MYDOMAIN.COM is because that way your certificate would include both DDNS.MYDOMAIN.COM and emby.MYDOMAIN.com and then they wont get a cert error.

 

as you mention you have a BT homehub, this router only supports a limited selection of DDNS hosts. from the list i think DynDNS supports domain parking and DDNS. although never used them myself. you shoudl be able to move your domainname from 123.reg to DynDNS. Alternatively you can transfer it to namecheap and then have a little program running on your emby server which updates your DNS service with your WAN IP everytime it changes. (i did it this way with my BT setup, before upgrading)

Link to comment
Share on other sites

pr3dict

Currently, HAproxy is working perfectly with both subdomains, both certificates, and both web services. I am not having trouble with absolute URL redirection and have not seen any issue with headers.

 

 

My next steps are to

1. setup an HTTP redirect to push all http requests to https port 443.

2. See if it is possible to get client authentication working so that only end point clients with a cert I gave them can access my equipment from the public Internet.

3. ensure I have hardened this implementation (ensure I am following security best practices, check performance, and configure monitoring and logging)

4. Ensure that my SSL configuration is A+ rated.

 

Sent from my iPhone using Tapatalk

 

Glad HAproxy is working for you as well... when you speak about client auth are you talking about using 509x certs? If so, let me know when you do that. I want to work on getting that done as well but havent had time to mess with it. 

 

HTTP Redirect should be easy. Last issue is the 503 no backend server found. I need to make a graceful error so that subdomains that I do not allow based on ACL's need to go somewhere instead of just haproxy saying sorry nowhere to go.

Link to comment
Share on other sites

  • 2 weeks later...
Untoten

I've just set mine up using a certificate from SSL Dragon.59316af31e486_Desktop.jpg

I checked your site.

1) dont put your hostname publicly, this is asking for trouble.

2) you didn't force https so I can visit http just fine

3) it's signed by localhost, basically defeats the purpose.

  • Like 1
Link to comment
Share on other sites

Swynol

@@David Martin 

 

strange SSL dragon gave you a cert with no root CA and issued to localhost. Have you uploaded your cert to emby? maybe its still using the self signed cert. See part 4 of the guide where you define the cert location. also you can ignore the part about using a .pfx without a password. emby now supports password protected .pfx files.

 

also you may want to edit/remove the image with the URL.

 

if your looking at upping the security i highly recommend running Emby behind a reverse proxy such as NGINX. 

  • Like 1
Link to comment
Share on other sites

Tur0k

Yea, you should be very careful what you list in forums. Things like screenshots of your domain, any view of your media, access to your username list, your public IP address invite trouble.

 

Instead of giving your domain or actual username name use examples like "mydomain.com" "username". If you have to post screenshots, remember to redact personal information from them.

 

 

Sent from my iPhone using Tapatalk

Edited by Tur0k
Link to comment
Share on other sites

Untoten

Err 

1 I agree

2 its fine can be fixed with HSTS

3 why? only difference from LE/ other CA is that root CA is trusted, site is still secure

 

 

I did with with TLS1.3 and more split proxy so i can just add a /emby /meh for every service i want :P

 

5945ba5b76dbb_emby.png

3. W/O Root CA isn't it easily attacked via MITM?  Obviously upstream attacks are rare and usually never happen, but planning worst case is always best.

  • Like 1
Link to comment
Share on other sites

Tur0k

3. W/O Root CA isn't it easily attacked via MITM? Obviously upstream attacks are rare and usually never happen, but planning worst case is always best.

THe lack of a CA whether publicly trusted or otherwise is the problem with self-signed certificates. This is part of the reason most smart device manufacturers are disabling the feature altogether. And you are right they do put the end user at risk for MITM attacks. SSL deliver authentication of the website, facilitate encryption end to end, and ensures that there are only two points within any communication.

 

https://www.sslshopper.com/article-when-are-self-signed-certificates-acceptable.html

 

Using a self-signed key negates two of the three features of PKI. While the PKI isn't perfect it is the best that society can offer. And there are improvements being made to it, like CAA.

 

The other problem that I see is the use of weak SSL types and cipher. Take a look at the following: https://www.digicert.com/cert-inspector-vulnerabilities.htm

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Using a self-signed key negates two of the three features of PKI. While the PKI isn't perfect it is the best that society can offer. And there are improvements being made to it, like CAA.

 

This is an extremely important point.

 

Most of our users want to use SSL only for its encryption (no spying) feature but one of the most important features of the certificate from the standpoint of the normal user is that it is supposed to guarantee that you are actually connected to the site you think you are.

Link to comment
Share on other sites

pir8radio

No, since private key is still a secret, so all you will get is a untrusted warning security is still safe, from a certificate standpoint as long as they are generated a good way. you still need proper protocols and ciphers, but that is easy to fix. 

 

But I thought the question was a MITM attack?  With a self signed cert, the users are used to getting the "warning". So in my attack I inject some new DNS records (or gain access to your DNS provider account), route your domain name to my nginx server with a self signed cert, then the backend of my server points to your server.. Now i'm in the middle and have full viability of un-encrypted traffic. Users don't suspect anything because the self signed warning is normal..     MITM attacks are easier with a self signed cert. Even if not using the DNS method above.

 

If you use DNSSEC that adds quite a bit of difficulty to my attack.   https://dnssec-debugger.verisignlabs.com/    

 

Last result box is what says you are using dnssec or not.

594699ebef176_Capture.png

Edited by pir8radio
  • Like 2
Link to comment
Share on other sites

pir8radio

DNSSEC requries your own domain :P,  and MITM attack on private key with selfsigned is as difficult if not more than a public CA; since  you controll the CA, and only one that can issue certificates from that CA; and not if an other CA like LE gets hack and they can issue certificates for any domain. 

 

I understand, I'm not saying its not a secure link, I'm saying its easy to be the man in the middle, when users expect to receive a cert warning and do, nothing looks out of the ordinary when someone is in the middle is feeding them yet another self signed cert, vs receiving a warning when they shouldn't.   Yes there are other things you can do to not have the warning, but we are talking web users, where you will have random clients connecting. 

 

Chances are if you are trying to be super secure you have your own domain name..  

 

lol, that's all, just wanted to add my 2 cents  :)

Link to comment
Share on other sites

Tur0k

It isn't just a warning. Training end users to ignore messages like this causes a bad reaction to this type of message in the future. Personally, I would want people to head this type of warning when making online purchases or accessing their banks online.

By hosting Emby on the public Internet you are inviting client devices to connect to your Emby service. Making anything publicly available should be a very serious question, as it is a wild environment out there on the big I.

While our home movies, shows, music, and TV data are likely not high value targets, control of your client device is. An MITM routing device between an Emby service and a client device could inject code or commands that take advantage of vulnerabilities on client devices. This attack vector is one of the many root causes for so many IOT and smart device manufacturers making it systematically more difficult to use self-signed certificates.

 

"It all comes down to, can you determine that you are using the same crypto key that the server is? The reason for signing certificates and the like is to try to detect when you are being hit with a man-in-the-middle attack. In a nutshell, that attack is when you try to open a connection to your 'known' IP address, say, 123.45.6.7. Even though you are connecting to a 'known' IP address of a server you trust, doesn't mean you can necessarily trust traffic from that IP address. Why not? Because the Internet works by passing data from router to router until your data gets to it's destination. Every router in between is an opportunity for malicious code on that router to re-write your packet, and you'd never know the difference, unless you have some way to *verify* that the packet is from the trusted server.

A crypto key, if you have the *correct* key, can verify for you that the data hasn't been tampered with. The problem is, however, that before you can begin encrypted communications, you must do an *unencrypted* key exchange, where the server gives you it's crypto key. Here's where the man-in-the-middle has an opportunity. If your traffic is going through my router, I can intercept the self-signed key from the server, and generate a new self-signed key with the same server name, etc in it, so that it *looks* like the self-signed key from your server, but which allows me to decrypt the communications between you and the server. My router then establishes a connection to the server using the *correct* key, and as data passes between you and the server, I unencrypt the data using the real key, then re-encrypt it using the 'fake' key. So, the data is encrypted between me and the server, and between me and you, but gets unencrypted in my router, giving me the opportunity to spy on your data, or even alter if if I want.

The point of a CA-signed certificate is to give slightly stronger verification that you are actually using the key that belongs to the server you are trying to connect to."

 

https://www.sslshopper.com/article-when-are-self-signed-certificates-acceptable.html

 

While the solution of importing a self-signed certificate into a browser may be seen as a simple way to circumvent a MITM attack, it assumes that the MITM node is not already placed in between the client and the Emby service when you instruct the end user to import the cert. Again, the PKI offers the ability to effectively authenticate and confirm identity using publicly trusted certificates at the point where the connection is being established.

 

While the PKI isn't perfect, and heavily relies on CAs being secure, server side certificates being properly secured at the file and password level (self-signed certificates have the same secure condition), and assumes that publicly trusted CAs don't spit out SSL certs for domains without properly confirming ownership (see new dns custom record CAA type 257 which is due to be enforced in September of this year). it is the best society can do, at this point, and is a continual work in progress.

 

Sent from my iPhone using Tapatalk

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

Tur0k

Also, agreed, I currently try to stay closer to the forward edge of cipher and encryption technology. I program my reverse proxy to

1. Only support the latest ciphers

2. Only allow TLS1.2 or higher (I should probably start testing TLS1.3).

3. Force the cert to 4096 bits.

 

I am fortunate at home our devices seem to be refreshed every 2 years or so. Deployments with a wider age range of client devices and pre-req compatibility will mean that cipher and encryption types will have to be "loosened".

 

https://wiki.mozilla.org/Security/Server_Side_TLS

 

Sent from my iPhone using Tapatalk

Edited by Tur0k
Link to comment
Share on other sites

Swynol

MiTM attacks are very easy if using a self signed or a cert for localhost. I do it at home with my firewall. user connects to my network all traffic going through my firewall gets a MiTM attack to decrypt any HTTPS traffic. I can if i want import a MiTM cert to all my browsers this way the browsers wont get the untrusted warning and get the green SSL connection. To most people they wont notice that there SSL connection being monitored. 

 

IF guests connect to my Wifi, when they first connect they get a captive portal which gives the user a choice to install the cert, 99% of the time people just click 'yes' without reading and automatically get the MiTM cert installed.

 

I havent explored using different ciphers yet, need to upgrade my NGINX version and test which works best for my setup.

  • Like 1
Link to comment
Share on other sites

chef

I have my SSL written for my domain, I added it to emby, and things were working fine.

 

Over the last couple days when people visit my domain, they are present with a warning saying that the SSL has been revoked and they're told to browse away from my domain.

 

In Chrome it allows some advanced options on the page to try and browse to the emby login.

 

Does anyone know why that is happening?

 

I would like to fix it.

 

Many thanks.

Link to comment
Share on other sites

chef

I have my SSL written for my domain, I added it to emby, and things were working fine.

 

Over the last couple days when people visit my domain, they are present with a warning saying that the SSL has been revoked and they're told to browse away from my domain.

 

In Chrome it allows some advanced options on the page to try and browse to the emby login.

 

Does anyone know why that is happening?

 

I would like to fix it.

 

Many thanks.

Link to comment
Share on other sites

Swynol

Chef where did you get the cert from? I had similar issue when i used Starcom, they became untrusted as a CA and all the browsers started throwing that error as the CA root of my cert was untrusted.

 

either that or the cert has expired. 

 

i doubt it would be HSTS/HPKP as i dont think Chef uses key pinning.

 

are you using a wildcard cert so *.mydomain.com or specifed with subdomains i.e. emby.mydomain.com, sonarr.mydomain.com etc?

 

 

EDIT: another option is that your CA has revoked it, doesnt often happen but not unheard of. you can contact whoever supplied it. or if you want a quick fix, create a new one using Let's encrypt.

Edited by Swynol
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...