this post was submitted on 16 Oct 2023
4 points (100.0% liked)

Self-Hosted Main

515 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

For Example

We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.

Useful Lists

founded 1 year ago
MODERATORS
communick@selfhosted.forum
4
SSL for hardware devices that can't run certbot. (alien.top)
submitted 1 year ago by eax0x0b@alien.top to c/main@selfhosted.forum
7 comments fedilink hide all child comments
 

I realize that this topic has been beaten to death, but I've yet to come across a solution that will work for me.

I'm familiar with Let's Encrypt, which obviously works super well for it's intended use, but what about for services where you can't run certbot? eg: iDRAC, routers, switches, etc.?

I currently have a LE wildcard for my domain, which I use only locally (for now), but having to manually update the certs every 90 days for devices that can't run cerbot is a hard pass.

Is my only solution to this scenario to set up my own CA and go about it that way? If so, is there anything out there that will help assist the management of certificates and deployment of root certificates to clients? I know that this can be done via GPO, but I don't have a Windows computer on my home network.

I suppose another option would be to use a reverse proxy, but I would prefer to not have to go that route in this specific case if there are other options available.

Anyway, interested in what others are doing to address this.

you are viewing a single comment's thread
view the rest of the comments
[–] eax0x0b@alien.top 1 points 1 year ago

the primary concern that I have with that model is that while traffic to the proxy is encrypted, ~everything behind the scenes is not (or, at least not in a trusted way).

this isn't so much an issue when it's in front of a docker network, but it is when it's connecting to actual devices/servers on the physical network, as a compromise of a user account on one machine could allow for mitm and lateral movement/PE/domain takeover.