Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

So, I'm being lazy and am just going to punt this to the crowd and see if I get help.

MC now has support for secure connections to the server. (Yay, I waited for this for many years.) I'm not using it because I've been lazy, and it could be a little complicated to set up in my case.

Here's my story:
* I have a long-standing dyndns domain name for my home network.
* My firewall properly handles full-NAT so that I can access my MC server via its FQDN both inside and outside my network (eg. lan.mydomain.net:PORT).
* I do not use an access key to access my server from any of my devices. I don't need to because see above.
* I have a TLS cert for my hosted website but it isn't a wildcard cert, so it doesn't work for my lan subdomain.

What is the easiest way to get a TLS cert that works for MC in my situation with a reasonable cost? The most important thing to me, other than working with my setup, is that it is fully automated if it needs to be kept updated with any kind of frequency (less than 2-3 years) because otherwise I'll forget to do it and it'll break constantly.

So, what do I do? Should I just get a wildcard cert (which aren't cheap)? Or get it a cert from my DynDNS provider? Or is there a good way to have one of the "free/cheap/short ones" automated for usage with MC? If so, directions?

[zybex]

HOW TO ADD A LET'S ENCRYPT SSL CERTIFICATE TO MC:

Windows instructions are here: https://certbot.eff.org/lets-encrypt/windows-apache
For other OS, select it on the page above and follow the instructions there.

1. Download and install Certbot on your MC Server Box: https://dl.eff.org/certbot-beta-installer-win32.exe
2. open port 80 in your router/firewall, forward to the MC server box (certbot uses it to validate that you own the domain)
3. make sure you have nothing else running on port 80
4. Create a folder c:\certbot
5. open a CMD prompt as Administrator and go to that folder (cd c:\certbot)
6. run "certbot certonly --standalone"
7. follow the wizard - it will ask for your dyndns domain. It will generate the .pem certificates on c:\certbot\live\yourdomain
8. On MC, enable SSL and click on "SSL Certificate". Give it the new certs:
    Public key: c:\certbot\live\yourdomain\fullchain.pem
    Private key: c:\certbot\live\yourdomain\privkey.pem
9. Close port 80 (unless you need it)
10. done!

These certs expire every 3 months, so you need to repeat this again every 3 months. There's a "CertBot renew" command, so we can add a Scheduled Task to do that - but the renewed Cert still needs to be reimported into MC manually. To automate that as well, I've asked for an "MC /SSL pubkey.pem privkey.pem" command line option in another thread... hopefully Matt obliges.

(edited)

[glynor]

but the renewed Cert still needs to be reimported into MC manually. To automate that as well, I've asked for an "MC /SSL pubkey.pem privkey.pem" command line option in another thread... hopefully Matt obliges.

That's what I was afraid of. There's no way to script the filesystem to overwrite the cert MC actually uses (in AppData\Roaming or whatever) automatically?

Probably not (otherwise you wouldn't provide the full path I'm guessing, but hoping). I second your request for a command line utility to do it then. Otherwise, using Let's Encrypt (or other similar short-term services) is right-out.

And getting a long-duration cert is stupid expensive, and will eventually become impossible (because shorter duration certs are better since TLS cert revocation is totally broken).

[zybex]

MC writes the certs to Registry. The public Key is clear, but the private Key is re-encrypted by MC, so we can't update it.

[glynor]

Bah. Well crap-salad then.

Yes. Need a command-line option to automate the cert update process in MC. Otherwise, it is frankly unworkable for me.

[zybex]

https://yabb.jriver.com/interact/index.php/topic,128571.msg892392.html

[glynor]

Thanks, zybex. I appreciate the instructions even if I'm not going to use them just yet.

If Matt gives us the thing, though, I'll be looking these back up. That's the ticket.

[jmone]

Yeah, when I set mine up for testing was pretty manual for me as I had to:
1) turn off port forward port 80 to my NextClound server
2) turn on port forward port 80 to my MC server (and then disable the Windows Firewall)
3) Run "Certify the Web" GUI to get/validate Lets Encrypt SSL then extract the Cert and Password
4) change the port forwarding back and turn on the FW
5) Load the Cert & Password files in MC

That got it working (and will need repeating every 3 months, but if I retire my NextCloud server there will be less to do).  The next part is that you then need to manually edit the Links generated to change the "http://144.137.208.82:52199/MCWS/v1/Share/Get?File=..." to "https://mymc.dyndns.info:52200/MCWS/v1/Share/Get?File="

So it JR goes down this path, it would be good if:
1) You could put in your FQDN into MC
2) Acquire/Validate/Renew the SSL Cert for the FQDN without needed to change ports etc (I'm not sure this can be done)
3) Generate the Share Links using the FQDN

[zybex]

Unfortunately I think the ACME APIs only work on ports 80 and 443. This is likely on purpose.
https://letsencrypt.org/docs/challenge-types/

There's a way to use TXT DNS records for the challenge, but that requires in turn that your dynDNS provider supports dynamic TXT record updates.

[glynor]

Unfortunately I think the ACME APIs only work on ports 80 and 443. This is likely on purpose.
https://letsencrypt.org/docs/challenge-types/

It is on-purpose, to prevent domain-jacking. It is too easy to get some weird software to serve random files on non-standard ports, especially for hosted sites (that might be on AWS or whatever). But control of Port 80 and 443 are so essential that they are sufficiently "trusted" as denoting ownership of the domain.

Domain validation is a rickety mess like the rest of the Internet, but it is what it is.

I'm fine with opening Port 80/443 when needed. I think I can even script that in my Firewall. But, in any case, the rest needs to be automated.

[glynor]

Turns out my firewall has LetsEncrypt support built in, and can itself automatically handle the certbot functionality (even handling opening and closing/reforwarding 80/443 automatically).

So, I just need MC to have a function to import these automatically, and to figure out how to get the cert files off of the UTM (though I’m sure there’s some method, I just haven’t looked).

[justsomeguy]

What firewall are you using? If it's something like pfSense then you can set that up as a reverse proxy with squid and use LetsEncrypt via the acme package to auto renew. Then MC doesn't need to handle the cert at all.

[glynor]

you can set that up as a reverse proxy

I think this perhaps turned out to be a very good suggestion. I had tried (not even trying to do HTTPS) putting a reverse proxy in front of MC once before (to abstract the server from the outside) but I had hit a stumbling block trying to get it to work inside my LAN with my FQDN server address added in MC (so that I didn't have to have a different connection setup in MC for outside my network as inside).

But I was overthinking it, I think. I went down a rabbit hole of DNS redirections to make my public FQDN name resolve internally differently than it does externally (which would break access to other services via the public FQDN). I'm not sure why I didn't think of it before, but your post made me come back and try again. A full-NAT rule nearly identical to the one I had for direct use seems to have solved that simply. It loads up internally lickety-split now with the internal proxy enabled.

I haven't tested it outside my network yet (and I might need to refine the rules there a bit) but I think it'll work.

EDIT: And I tested tethered to my cell phone, and it works just fine. Awesome. Now I can actually harden the connections coming into MC quite a bit more, via the proxy (and they're HTTPS finally).

[glynor]

Sweet. Now I just need JRemote to support HTTPS so that I can close down non-secure access entirely.

[jmone]

I'm intrigued!  Is my understanding correct that if you setup a reverse proxy then everything on the "home" side of the router gets SSL'ed?  ...and if so how to do setup a reverse proxy (I've a Ubiquiti UDM Pro if that matters)?

[glynor]

Nathan, yes. You have the general idea.

A reverse proxy is basically a fake webserver front-end for your webserver. Instead of directly exposing the "real server" to the outside world, you put a separate webserver up that does nothing but accepts the incoming commands, optionally filtering them for nefariousness, and then forwards the commands along to the "internal-only real server" (and then does the reverse back to the client with responses). Reverse Proxy servers are used very commonly for servers on the Internet for security and load balancing (you can have one reverse proxy "front end" that handles incoming requests and forwards to a load-balanced "pool" of actual web servers behind the scenes). Probably nearly every single website you go to regularly is behind at least one reverse proxy of some kind.

In this way, you can abstract and hide the workings of the "real server" from the Internet. And, of course, because the proxy is a full-fledged webserver, it can apply TLS and do HTTPS.

So, in my case, my firewall, which is a Sophos UTM (which I love), has a built-in reverse proxy feature (called Web Application Firewall in their terminology, but I bet it is just squid under the covers). I was able to set it up like so:

* Virtual Proxy Server: MCWS Encrypted (External) - Running on TCP port 53199 bound to External Interface on my Router.
     > TLS enabled using my LetsEncrypt cert
     > Mine can also do hardening (looking for "bad traffic, known attacks, etc). I don't have this on yet, but am going to test it and enable that.
     > Real Server it uses: MC running in NON-encrypted mode, when I'm done, I'll have NO port forwarding enabled for it anymore at all.

Then, to make it work inside my network without having to make a special "external-only" Library for MC on my laptop...

* Virtual Proxy Server: MCWS Encrypted (Internal) - Running on TCP port 53199 bound to the INTERNAL interface on my Router.
     > Identical settings as the external version (except I won't bother with the hardening stuff probably).

And, lastly, to make it still available both internally and externally as non-encrypted, I'm going to (I haven't done this yet) make two more Virtual Servers set to HTTP (no encryption) mode, exactly the same except they'll actually run on 52199. I haven't done this because I'll need to switch the port MC uses on the "real" server and I don't want to break all my clients until I can get it all tested/set up. Really the only reason I even need these is because of JRemote (which doesn't support HTTPS connections yet). Panel and MC itself all works fine through the encrypted connection to the proxy server.

Then, the last part, to make it so I can just set my laptops and mobile devices up with my FQDN:Port setup as I have them now (without resorting to using the JRiver Media Network key system) was to set up a Full-NAT rule on my router. This rule looks for traffic coming from any device on the Internal network on TCP Port 53199 going to my WAN address (because looking up my FQDN via DNS will result in my WAN address, so the device will "try" to connect there) and then changes it so that:
* Destination: Internal Virtual Proxy Server (in my case, on the Router itself, so the Router's internal IP address)
* Source: WAN Address

That way, when I enter lan.mynetwork.net:port as the setup in MC, it works whether I'm inside the network or outside the network. Inside, the Full-NAT rule triggers and all traffic going to WAN from inside my network on port 53199 gets automatically re-routed to the proxy server Outside, the rule doesn't trigger at all, and traffic just comes in to the External version of the Proxy server.

So, I know a bit about Ubiquiti routers. The UDM Pro cannot act as a Reverse Proxy itself. So, to do this (at least without replacing the UDM), you'd need to set up a separate reverse proxy machine/VM inside your network yourself. Squid is a very popular Linux GPL application designed for this purpose (that justsomeguy mentioned and is apparently available as a plugin for pfsense). But NGINX and Apache can both be set up in reverse proxy mode too, and there are a wide variety of other options (for Linux and Windows of course):
* https://dannyda.com/2020/01/03/list-of-open-source-free-proxy-forward-proxy-reverse-proxy-cache-server-software/
* https://github.com/dariubs/awesome-proxy

I'm not sure if your UDM can do full-nat rules (which are like SNAT and DNAT combined, and can modify BOTH the source and the destination addresses, instead of just one way like a typical Port Forwarding setup). If so, you could totally set one up like I did, only on a separate box or VM from your Router inside your network (and then you'd just need a couple extra port-forwarding rules to allow the external access to get through to the proxy server, just like you have now for MC directly, only pointed at the proxy server instead).

[glynor]

Shorter: Get a webserver for your webserver so you can TLS there instead of on the webserver.