How NOT To Install Self-Signed Certs On Our Plex Server

I have just installed a Plex server, on the host-machine I have on my LAN, that host-machine being named ‘Phoenix’. The purpose of this server is to allow me to access Media Files – i.e. Movies and Photos – Not Just from anyplace within my LAN, but from any place outside my LAN as well, which only I will have access to – as we don’t share our Plex passwords with friends.

Some people might wonder why this is useful to me, especially since Plex is a paid-for service, and since I already have a VPN. And the reason is simply the fact, that to access certain resources on my LAN by way of the VPN, can be slow and cumbersome. It might work for a Samba share, just to fetch a file, but if the objective was to watch a movie which I own, and the original format of which I did pay for, then to leave my tablet with a modified network configuration, and logged in to my VPN, for the duration of the entire movie, would become quite impractical. So Plex was my chosen answer.

One problem which some Plex users could run in to, is the idea that when outside their LAN, they first contact a Web-server, which then redirects them to their private IP address. This idea can lead to another idea, which would be that the following connection from their client-program to their Home LAN is not secure, for which reason some Plex users might want to set up an SSL / TLS certificate to secure that second, redirected connection.

The problem with that last part is, that if our Plex server version is reasonably up-to-date, then we don’t need to do this, because Plex has already done so. There exist several tutorials on the Web, one of which explains to us how to set up a self-signed cert, and another which explains to us how Plex on the Web has already got us covered.

My misfortune last night was the fact that I stumbled on these tutorials, roughly in the order in which they occur above: First, to try to install a self-signed cert, then to learn that Plex already has a system in place with “DigiCert”.

The way in which Plex is intended to work with basic users like me, we all have URLs with the Plex site, that run roughly like so:


  1. The user first connects to the Web-server-URL, for which Plex inc. has a certificate, which in turn encrypts communication from that point on.
  2. The URL is then not just redirected, but actually rebound, with the IP address of our Home LAN, so that the same cert encrypts the media-flow to our personal server.

What this means is that for most small-scale uses, we don’t need to acquire our own certificate, to secure a direct connection to our LAN. We can just configure our server like so:


If we feel that we need greater security, we can change the settings to “Required”, meaning that all connections to our Plex server, except from the same computer (from ‘localhost’), and except from within our LAN, will need to be secure in order to proceed. And then most of us still won’t have to fill in any of the fields below, to set up a custom cert.

But there is a disadvantage to settings ‘Secure Connection’ to ‘Required’. The simple usage-scenarios can be given, that we want to connect to our media-server using an app that doesn’t support TLS, or through the ‘Plex Web’ site, but from within our own LAN. What Plex Web will try to do, is to rebind the IP-address to the IP-address  which our server has on the WAN, and to give us a secure connection that way – even though we’re connecting to a place on our own LAN!

This can easily fail, because It can go against router policy, to rebind IP addresses to our own LAN. It can also go against browser policies, in the form of ‘Application Boundary Security’, where an external site is not supposed to gain access to resources on our LAN…

But as it stands, each of my Android clients was already set up by default, to ‘Allow Insecure Connections: Never’, my Roku works, and there is no need to use Plex Web from home.

I suppose the reader might wonder, what would happen if indeed, he was to set up a Custom Certificate for his Plex server at home…

Continue reading How NOT To Install Self-Signed Certs On Our Plex Server

SSL Certificate Update Runs In Background Successfully Now.

For the parts of my Web-site – that have nothing to do with my blog – which use SSL, I have been subscribing to certificates from ‘Let’s Encrypt‘. These certificates have as their basis a ‘Certbot‘ robot, that runs on each subscribing server, and that tries to renew certificates when the time has come to do so.

On some past occasions, this robot has failed to do this in the background, requiring that I manually restart my Apache Web-server.

Due to the recent ‘normalization’ of my server-configuration – setting Apache to listen on port 443 again – I’m happy to find out that the Certbot has renewed my SSL Certificate as a background task, without requiring my manual participation, and that it was able to restart Apache as well, without resulting any any disruption, to the availability of my blog to readers. Yay!



Experimenting with Tor

I own an old, beat-up laptop I name ‘‘, from circa 2005. And with this laptop, I am exploring the fantasy that it should be configured to connect to the Internet, entirely using ‘‘. I am trying to replicate what the USB-stick is said to do, but in the hopes that my own achievements will be more credible. You see, I doubt that really accomplishes what it claims to accomplish.

I have to admit, that I really have no idea, what that old laptop is supposed to do, once it is connected via . This just seems like a fun project. And, there exist few services today, which will just let people connect via . What one can do is browse, using a Web-browser, and not use Google, because the geolocation services of Google tend to blacklist most of the exit nodes of .

But, wanting one additional ability, I also decided that should connect to a less-important email server of mine via IMAP, and through . What I discovered, was that the email client I was using for this does not itself support a Proxy, through its own GUI. And so I read that some command-line utilities exist for Linux, which will force the programs specified to use such a proxy.

The first utility I tried was called ‘‘. But there is a caveat with this utility, that people fail to point out. It will negotiate the email client to connect to Port 143 in plain-text, rather than in cipher-text. I had not noticed this, until my laptop had connected to my email service, in plain-text in fact. This means that a corrupt exit node would have been able to sniff my password.

This is the full extent to which I was compromised. There was really no other sign, that anybody might have tried to connect to my (subscribed, paid-for) email server, in my place. But such a single exposure was more than what I was willing to let sit.

So I immediately changed the password of this subscribed, paid-for email service, to a much harder password, before anybody else got the chance, and I am still able to use that email address fully.

But then the question lingers in my head, of how I might nevertheless connect to it via . There exists another command-line utility named ‘‘, which claims to tunnel all the TCP/IP connections of its designated program, through the Proxy, without analyzing what types of authentication may be taking place.

I tried to use as described, but only found the comforting message, that the stream could not reach the IMAP server in question. So here there was no evidence that the utility in question actually breaks TLS encryption.

But ultimately, I would still not feel comfortable using , after the experience I had with , because I need to take the idea that does not break encrypted protocol, entirely on the words of software-authors who I cannot ultimately trust. These are specialists after all. Even might eventually compromise my connection-security, even though it is not supposed to.

And so my little laptop remains useless, from any practical perspective.


Continue reading Experimenting with Tor