I’m trying to set up a Vaultwarden password vault, but i’m running into SSL errors.
This is not the first time i encounter SSL certificate problems, but i have no clue on where to start…
I read tons of guides, viewed multiple YT video’s but i don’t understand unfortunately.
Docker, compose, Treafik, NPM, TLS, Let’sEncrypt, … all these terms are mentioned, explained and i still have no clue at all what all that means.
And searching around the forum, i’m not the only one appareantly.
Docker and Traefik are not on the official apps list, also TrueCharts which contained these apps is no longer supported by Truenas Scale since Bluefin?
Now i found a newer guide on this forum, but i’d like to know if this wil solve my problems with SSL, before i go ahead and do things that i don’t understand. Especially concerning security.
These are complex topics that can’t be easily explained. Docker is installed in scale and that is what is used to run the apps (at least in TrueNAS Scale 24.10.0.0).
NPM (nginx proxy manager) is more beginner friendly than traefik. Both are reverse proxies but the configuration of NPM can be edited via a web interface.
If you want the service to be accessible from the internet, a cloudflare tunnel is the most beginner friendly option. Cloudflare will do the SSL termination for you - you don’t have to do anything SSL related yourself.
Yes, it’s native now. You can run any docker app using the “custom app” button. But I do recommend getting to know the docker command line… you’re probably going to need it at some point when things aren’t working.
Local only is definitely the more secure option! Bitwarden also works without connection to the server.
If you want a valid, browser-trusted ssl certificate it’s unfortunately not that easy. The steps are approx. as follows:
Buy a domain name, yes you need one. Doesn’t matter where you buy it, can be the cheapest you can find.
Create a cloudflare account and add your domain to it. You’re going to have to change the NS settings of your bought domain name, but cloudflare will probably guide you through that.
Create a API key for domain access in cloudflare.
Install Nginx Proxy Manager and setup the reverse proxy, use letsencrypt together with DNS-01 challenge using the cloudflare api key.
Note: There are other name servers that can be used for the DNS-01 challenge, but cloudflare is a pretty solid. Edit: cloudflare is also one of the few providers that is supported for the TrueNAS webui, in case you want https:// access to the webui without scary warnings.
It’s not easy, but you can probably find good guides somewhere
You can do it without having local dns by adding a “A” record in cloudflare and pointing it to your internal ip. Which is what I have to do because my router is very limited.
Thank you for your further explanation and tips!
Really appreciate that
I am however finding it hard to follow your first step, as i do not understand why i can’t just connect securely to my server from my desktop that are in the same house.
Or why i effectively have to buy (only rent available?) a domain, which contradicts the (or my) philosophy to self-host (local) in the first place.
(I do understand this in the way that it’s absolutely vital for general internet to be safe.)
Why isn’t it possible to create certificates or ID’s that are unique to my server and desktop, and exchange them so either system knows that system is thrustworthy?
I mean, to create that SSL cert, you need a domain (which is a specific IP adress?), which you point to a host (is my physical hostname?) through Cloudflare. Then Cloudflare authorises this specific certificate which enables SSL connections to that point eg everything hosted there (and allowed to connect).
I’d like that without a third party involved, especially one with annual billing plans.
There’s no way to “buy” a domain in such a way that it permanently belongs to you, so in that sense, yes, only “renting” is available. But doing this doesn’t contradict self-hosting; it leaves you free to run whatever you like on your own network and hardware (while simultaneously making it easier to host some of it remotely if desired at ant point). It does, however, incur a nominal additional cost, generally somewhere around US$10/yr, though that depends somewhat on the top-level domain you choose (and often you can get a discount on the first year).
Do you need to do this? No, but it is necessary to get a publicly-trusted certificate, which is the easiest way (by a long shot) to resolve certificate errors. By now, a whole lot of software knows how to work with Let’s Encrypt to get and renew certificates from them for free, and all your devices are going to trust those certificates.
The other option is to create your own certificate authority, which I’ve done following this guide:
No, a domain is a domain. Ordinarily there will be some DNS records pointing the domain to one or more IP addresses, but those are not necessary for this purpose.
This part is unnecessary, particularly if your router isn’t brain-dead. If your router is moderately featureful, or you run a local DNS host like Pi-Hole, you’d tie hostnames to IP addresses there, not at Cloudflare. If your router is brain-dead and you don’t want to run a local DNS server, you can also do it at Cloudflare, but that isn’t necessary (or recommended, really, for hosts on your LAN).
Not exactly. The certificate comes from Let’s Encrypt. In order to get it, you need to prove you control the domain. One of the ways you can do that is by creating a DNS record with pseudo-random contents. The reason Cloudflare is frequently recommended is because they provide DNS service for free, and much of the client software for Let’s Encrypt knows how to use Cloudflare’s API to create (and remove) the necessary DNS records.
With this scenario, only DNS is hosted at Cloudflare; your own applications can remain locally hosted, and none of your traffic runs through Cloudflare. It can if you want–you can, for example, set up a Cloudflare tunnel for that purpose–but it isn’t necessary in this application.
“I’ll do my own CA, with blackjack and H…” is how i read this…
Marvellous!
But indeed, i see your point, in hardware alone you could pay 10 years of ‘domain rent’.
That’s also a good point and a long story… I have been using Asus routers for all my life, but encountering issues with them with my ISP. The combination of their obliged modem and Asus’ routers is abominable. It’s just recent (01/11/24) that our state dept. has obliged my ISP (Telenet) to ‘open up’ their modem policy. Which in turn gives me a chance to investigate further… buying a 250€+ cable modem that my connection supports.
Current config = Telenet modem in “bridge mode” → MAC adress of my Asus router.
Router Specs
(i noticed that ‘Lets Encrypt’ is supported? Does this have any use in my case?)
Currrent network problems are DHCP handshake related… I see my external ip followed by “0.0.0.0”, then again a correct ext IP, then again 0.0.0.0, …
I swapped from official FW (multiple versions) to Merlin FW which seems to handle it better, although still with issues. I tried DHCP handshake ‘Normal’, ‘continuous’ and ‘Agressive’. Still have to reboot my router twice per day to be able to access internet.
So regarding modem and router, i’m not really sure too on how to continue…
I do run Pi-Hole on Truenas, so i got that goin’ already!
It doesn’t have to be on the rPi with the Yubikey and hardware RNG, but those combined make for a pretty darned secure solution. But you could just run it in a Ubuntu VM if you’re willing to accept somewhat less security for your certificate authority.
Editing to elaborate on the security issue: The guide I linked uses a dedicated device for the certificate authority, a Yubikey, and a hardware random number generator. All of these contribute to security:
Running the CA on a separate, dedicated piece of hardware means that it’s immune to a whole class of attacks that to which a VM could be vulnerable, whether from bugs in the hypervisor or from a malicious actor gaining access to that platform.
The Yubikey acts as a hardware security module. The root and intermediate CA’s private keys are generated on a USB stick, not on the main filesystem, and from there loaded into the Yubikey. The USB stick is then removed. It’s effectively impossible at this point to recover the private keys[1]; the Yubikey itself stores them and conducts the cryptographic signing operations. An attacker who gained access to your CA could issue new certs, but couldn’t clone your CA to create certs on a different device.
Many cryptographic operations depend for their security on truly random numbers, but those are very hard to generate in software. A hardware random number generator increases the security of those operations.
As I wrote above, all of these things are optional; you can run the Step CA under Ubuntu (or probably any other mainstream Linux distribution) in a VM without those extra devices.
a proper hardware security module behaves in the same general way, is yet more secure, and is considerably more expensive. ↩︎
Hmm this works for the TrueNas WebUI, but not for my Vaultwarden’s landing page. Still SSL error, but now, when i force ‘HTTPS’ it display’s “could not deliver secure connection - ERR_SSL_PROTOCOL_ERROR”
So i’ll re-try this, but not quite sure where i went wrong, as the Valtwardens landing page is on the same IP, different port.
It should work for Vaultwarden too (as long as you choose the new certificate in Vaultwarden config). It works for my Vaultwarden, Adguard Home, Nextcloud, Portainer and more.
So if i understand this all correctly to sum it all up there are 2 ways to complete this:
One, as in using @bacon@dan 's tips and hints to have an automated setup for signing certificates.
→ this automated setup handles the cert’s between devices automatically once fully setup correct. (through Cloudflare/DNS provider and rented domain)
→ can connect through the internet (as in external)
The other using @mps7 's guide for making a certificate yourself.
→ need to configure/import cert with each client manually
→ only works local
I also didn’t know that certificates can be used or configured on app basis. As the XCA guides goes through configuring the network controller too. I presumed that certificate was automatically inherited by the apps.
Just needed to edit every app’s cert, and now connecting securely to them as expected.
I still quite don’t fully understand, but i’m getting there i suppose!
This thread just ticked a box that was on the list to fix for a very long time…
My guide sets up a reverse proxy, and it’s that proxy that handles the certificate. You connect to that proxy, which in turn passes traffic back and forth between your client device and the application.
That’s an added step you could configure, but it isn’t included in my guide. If you wanted to do that you’d forward ports 80/443 to the NPM application in your router.
The difference in this regard between my guide and @mps7’s is that my guide gives you a publicly-trusted cert. Even for LAN-only use, this is easier in that you don’t have to do anything at all to your client devices for them to trust it. If you did want to expose these things to the Internet, you’d definitely want such a cert.
.
