Hi everyone.
I have recently set up a Raspberry Pi as a web server, and on that I use let's encrypt for HTTPS. That part of my setup is working great.
My problem right now is that I would like to use a let's encrypt cert on my file server as well (uses HTTPS for file transfer), which is a separate machine. They both share IP and domain name since they are behind NAT.
What I would like is this:
www.example.com - Goes to my Raspberry Pi (this part already works)
files.example.com:2000 - Goes to my file server (this part also works, but it does not use a let's encrypt cert and therefore throws an error) (port number needed because of NAT)
Both servers are running Debian based distros and my domain-name provider is namecheap, if that matters. I have full access to both servers.
Is this possible and if yes, how would I set this up?
I can't quite wrap my head around how I would register files.example.com since I need the :2000 at the end, and I don't get how I would get the cert from one server to the other.
Certificates don't contain or specify port numbers, only names. Once you get the certificate, you can use it for a TLS service on any port number and any TLS-capable protocol.
For certificate issuance, Let's Encrypt requires the use of inbound port 80 or 443, or the ability to change a DNS record. This is only to verify that you really control the domain name; after the certificate is issued, there's no limitation to using it with some other port.
One of many approaches to your situation could be to have your Raspberry Pi obtain a certificate for files.example.com (not "files.example.com:2000", which doesn't make sense because port numbers are not included or specified in the certificate). This would use either port 80 or 443, whichever port your Raspberry pi used to obtain your original certificate for www.example.com. Since that port is still pointed at the Raspberry Pi, Let's Encrypt should be satisfied that the Raspberry Pi is entitled to ask for certificates for it.
Exception: If you used Certbot with --apache or --nginx (or allowed it to choose one of these plugins based on analyzing your system), this may not work and will at least require explicitly specifying -d files.example.com, since Certbot is unable to tell by analyzing your web server configuration that the Raspberry Pi can answer requests on behalf of https://files.example.com/, since that hostname wouldn't be mentioned in any configuration files present on the Raspberry Pi. If you used --webroot, you'll need to configure a virtual host on the Raspberry Pi that answers requests to http://files.example.com/ (with the default port 80); if you used --standalone, it should work pretty much as-is.
Once your Raspberry Pi receives the certificate for files.example.com, you can use something like rsync to copy the certificate, chain, and private key over to the file server, and the configure the file server to use them. You'll need to repeat that process whenever the certificate is renewed.
If these methods don't work for you or don't make sense to you, feel free to let me know and I can try to suggest other methods.
Thanks a lot for the quick and helpful response!
I am using nginx on my Raspberry Pi, but I should be able to just use --standalone and then specify that the cert should be valid for files.example.com by running this command, right?
This is the same command I ran before, except I used --webroot and did not include -d files.example.com.
Then I just copy over the cert to my file server and everything should work (need to do this every time the cert is renewed), correct?
Sorry to ask for even more help, but I am having another problem right now. The certbot command does not work. I am just getting:
sudo: /etc/letsencrypt/certbot-auto: command not found
It worked before when I set up my server. I can also see that the files are in my letsencrypt directory (cloned with git from github) so it should not be the path that's wrong.
Got any ideas why it says the command doesn't work?
Edit:
I "fixed" the issue by downloading the letsencrypt github page again to a different directory.
It's not very likely that --standalone and --webroot will both work easily on the same system. --webroot is meant for a case where you do have an existing web server (that you want to use as part of the authentication process), while --standalone is meant for the case where you don't have an existing web server, or prefer to temporarily shut it down.
Also, the -w option is only meaningful with --webroot (it's an abbreviation for --webroot-path).
One option might be to tell your Raspberry Pi's nginx that it should also respond for files.example.com (on port 80, which is indeed pointed to the Raspberry Pi, if I understood and remembered your description of your setup correctly). Then you can use --webroot.
Once again, thanks for the quick response.
I managed to get my Pi to respond to files.example.com so that part is fixed now.
My only problem right now is getting the cert into my file server. Maybe you can help with that too?
My file server is a ReadyNAS Ultra4. It is running Apache 2.2.6. It seems like its self-generated cert is saved in a file called apache.pem.
It's structure looks like this:
I've tried pasting privkey.pem, fullchain.pem and cert.pem in different combinations to the file but every time I do the entire web server goes down (on the file server).
Again, sorry if this is out of your scope in which case I will ask on the NetGear forum, but my current guesses are:
Apache is not configured to use the same encryption types as the letsencrypt one, and thus it fails.
The keys in the letsencrypt files are not the same format as what Apache expects on my file server.
To match exactly the way it looks now, it should presumably be privkey.pem plus cert.pem (which would be missing the intermediate certificate, which would cause certain clients to be unable to validate the certificate).
If that doesn’t work, I think you need to see if there’s a way you can get the device to explain what it didn’t like (for example, an error log somewhere on the file server), or else ask the manufacturer of the server.