Certificates for internal devices

Company I work for went through a security audit and and all of the devices with self signed certificates were flagged. Now I need to replace all the certificates with “valid ones”.

Of course my mind goes to let’s encrypt as a solution but I’m second-guessing that because I would use those certificates in devices like the Dell idrac system and the Lantronix spyder kvm. Replacing certificates in them every 90 days is a tedious manual process.

Assuming though for the moment that I can find a way to automate replacing certificates as they expire, I’m assuming that a wildcard certificate for *.lan.elucid.biz would be sufficient for internal use for all of these devices?

If using let’s encrypt is the wrong solution, as far as I understand, my alternatives are a wildcard multiyear certificate from some discount CA or our own private CA within our network. If the latter is a reasonable solution, any recommendations on private CA systems?

I really appreciate the assist. Thanks in advance!

The way I was thinking of solving this was using wildcard certificate for our device/internal domain (elucid.biz is the externally resolvable part. lan.elucid.biz is inside the network))

1 Like

At a previous job, we setup a webserver as a reverse proxy that sat on both the management network (iDRAC, IPMI, KVM) and also on the internet network. We gave that a Let’s Encrypt wildcard, and it was the only SSL endpoint we had to actively think about.

Most importantly, it gave us an SSL stack we had true control over. I don’t trust the SSL stack baked into the firmware of those management devices, and did not want to expose them to users.

The gateway->iDRAC leg of the proxy was admittedly not fully secured because we ignored SSL verification. but there’s no reason you couldn’t do yours properly. Use an internal PKI with long-duration certificates for each device, and get the reverse proxy to validate against that PKI’s CA certificate. Something like smallstep would serve you well there.

So I guess my recommendation is to use both Let’s Encrypt (for the people connecting in the browser) and an internal PKI (for the reverse proxy talking to the devices).

1 Like

What does this mean, exactly? They expect you to use publicly-trusted certs for internal-only hostnames and devices? I mean, it can be done… but why? Or do they want to see some properly-managed internal PKI instead?

1 Like

The core of the problem is this line from the report.

The server’s X.509 certificate does not have a signature from a known public certificate authority.

To me, it seems to clearly state that in order to pass the audit, every system needs to have a certificate from a public CA like let’s encrypt. A private CA would not pass the literal test in the security audit but it may be good enough for the client that that triggered the audit. I’ll verify that later.

Assuming I need to have certificates for public CA, I know I could use let’s encrypt certificates on these behind-the-firewall, not-exposed devices? The big questions is how do I renew them and single device certs or one wildcard cert? although pushing certs to an embedded device via javascript bloated UI may be the hardest part.

iDRAC seems like it would be very easy: https://www.itechlounge.net/2018/03/dell-how-to-install-a-custom-issued-ssl-certificate-on-idrac/ . Just add a deploy hook calling racadm to your ACME client of choice and you’re done.

The Lantronix KVM is a PITA though, I think you’d have to reverse-engineer the HTTP request to configure it and put that as a curl invocation in a deploy hook.

You could also just push back on the report and tell them you’re mitigating it by using an internal PKI …