Use the generated SSL certs with Shellinabox

I have created several Lets’Encrypt SSL certs for regular Apache sites that I manage. I now have to use an existing cert for an existing host name that I own, but to be used to better secure a “shellinabox” application, which runs on top of Apache. However, as I am not an expert in certificates, SSL and other SSL-related topics, I do not know what I should do in my shellinabox config files to properly point to the real SSL certs I created.

Hi @jfmessier,

If shellinabox “runs on top of Apache”, Apache should take care of the HTTPS termination for it. Did you install the certificates in Apache already? If so, what behavior are you seeing when accessing the sites in a browser?

When accessing the test page of the site (info.php) everything is just fine. However, when accessing the port for ShellInABox, I still get the warning about the self-signed cert, instead of the signed one. This is running on a Raspberry PI, behind a router at home. I basically want to get access to my Linux boxes over the web, as port 22/TCP is closed, and using another port like 443 will not work. Deep packet inspection…

Thanks :slight_smile:

Also to note that the Shellinabox config files seem to point to the self-signed cert, but when changing the config file to point to other .PEM files, nothing works at all.

Oh, so ShellInABox has its own network listener? When you said it ran under Apache, I was thinking that it was configured as a web application.

Can you give an example of a hostname and port where your ShellInABox is currently listening using the Let’s Encrypt PEM files?

At this point, using Shellinabox or anything else does not matter so much as getting the cert created from a Raspberry Pi which is behind a router.

All I first want to have is a plain page, protected under HTTPS, that will get displayed once the certs are properly installed. My issue is that since my RPi is behind a router, the TLS validation is not possible, although the DNS entry of my web server is properly setup. I have control of the domain name/DNS, as well as the router and the RPI itself. I easily created such Apache-only servers with certs on servers that are directly facing the outside network, but it never worked for the ones behind a firewall/router.

So, I either need to be able to get the cert first issued on the RPI that will use the cert, or get it issued on another Linux box that will be authenticated, then re-point the DNS entry to the router/RPI and import the files there. What do I need to import/export from my Linux server to my RPi in order to get the renew properly working ?

To answer your question first: The most vital thing that is needed to use the certificate is the associated private key. The Certbot software stores this in files named privkey.pem but other software might use different names. The private key is, as its name suggests, something private, nobody else has a copy and you mustn’t give it to anybody. Let’s Encrypt doesn’t know what it is either.

The other files are public, but it will usually be easiest to copy them around within your own machines, depending on the exact software you’re using, you may want what Certbot calls “fullchain.pem” which is your certificate plus all “intermediate” certificates needed to prove that certificate is trustworthy, or “cert.pem” and “chain.pem” which are the same things but as two separate files. Unlike the private key you can show these to anybody (that’s how your server works in fact) and there are copies of them archived on the Internet if you ever lose them.

Other files are created during the operation of Certbot or similar software but you don’t need them at the end, including a CSR (Certificate Signing Request) produced to request the certificate.

Since you control DNS, you might (if your DNS can be controlled automatically by a computer not just by manually typing stuff into a web form or whatever) want to look at the dns-01 challenge method of ACME. This would let a computer prove control over the name without fiddling with how people actually connect to machines.

I am diagreeing with your interpration of how this work

from the github manual https://github.com/shellinabox/shellinabox/wiki/shellinaboxd_man

A) it’s a standalone process which runs it’s own webserver
B) If you want to use Apache in front of it are you proxying to the backend?
C) Also can you give us how you set up -c | --cert=certdir parameter

There are a few notes about specific use cases.

Andrei

review this guide: https://www.tecmint.com/shell-in-a-box-a-web-based-ssh-terminal-to-access-remote-linux-servers/

–cert-fd=fd
Instead of providing a --cert directory, it is also possible to provide a filedescriptor fd where the certificate and key can be retrieved. While this option disables SNI support, it does offer an alternative solution for securely providing the private key data to the daemon.

is also another option

Andrei

Thanks for the feedback. I was trying the dns-01 challenge, however, it is not “compatible” with the --apache option of the certbot command. It can be used with the --manual option, if I remember correctly. I did some tests of this parameter, assuming that I would then move the certs around, and it did not seem to work properly. There was also this other challenge (I can’t remember the param) that is defaulted when the site cannot be reached from external connection (or behind a home router) where you place a specific file with specific content on the server, however, it is not retrievable in time. Last times I tried it, the process was timing out. I did not have time to create the file for the validation to happen.

My other option is to create the site externally, create the certbot on this site and transfer the certs (and config files) so let’s encrypt will renew the files from this new location. I understand that the renewal does not need the same challenge every time the certs are renewed.

Yes, this is something to consider, if I can get the cert created on my internal server (behind a router) and then get it renewed. I will then point to the certs directly.

Thanks :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.