Trusted Certs for Infrastructure Boxes

My domain is: not relevant
I ran this command: none
It produced this output: N/A
My web server is (include version): Various
The operating system my web server runs on is (include version): Various
My hosting provider, if applicable, is: N/A
I can login to a root shell on my machine (yes or no, or I don't know): Some of them
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): different per device
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): N/A

Is there a way to make internal-only certificates that include a trusted cert chain?

Background: more and more infrastructure boxes (managed switches, firewalls, etc) are (thankfully) requiring https for their management interface, but either create their own self-signed certs or, in some cases, allow one to upload a cert.

In this age of suspicious browsers, it's a PITA to jump thru the browser's hoops to access the boxes (when it's a self-signed cert), and I can't see a way of generating fully trusted cert chain (using LetsEncrypt or otherwise) without giving each box a FQDN in a publicly addressable domain. This would be a big headache and mean lots of extra firewall fiddling for cert renewals.

Is there a simpler way to create trusted certs for infrastructure devices?

Thinking about this a little, it occurs to me that the canonical solution to this is to create our own signing infrastructure, use it to generate certs for the switches, and have every host trust the authority root*.

Right?

*Is that what they mean by auto-enrollment?

1 Like

That's one way to do it, and what I've been moving toward recently. The other option (and what I've been doing until pretty recently) is to assign internal names on a public domain I own and use DNS validation to get certs for them. My domain's DNS is hosted with Cloudflare, and I use that for some; I use acme-dns (which I host myself) for others. Those items aren't accessible from the Internet and don't need to be, hence using DNS validation for them.

The only two solutions are:

  1. Give them public-DNS names, even if they don't have A/AAAA records in public DNS or only have records with internal IPs. That is, you validate the names using DNS-01 challenges to get the certificates, and install the certificates on the systems (hopefully all automatically as they renew every couple months), even if they only resolve to those names using your internal DNS.
  2. Use your own private CA that you install in your browsers. There are various tools to make this as simple as possible, but yes it can also a pain. If your web browser have some central administration (like Windows Group Policy though I think there are plenty of other solutions out there) you may be able to install the CA in them relatively easily. And then of course you need to a run a CA, which can have various levels of complexity depending how secure you're trying to make it.

I'd be inclined toward option 1 for my own stuff, and option 2 in a medium-to-large corporate environment, but you'd have to look at the pros and cons to make a decision for yourself.

1 Like

Okay, thanks guys.

Unless I misunderstand, the advantage of the private CA approach is that I can make the validity last many years and thus I don't have to update the certificates in the devices every couple of months (as even if I establish a scheme to auto-renew them, I still have to get them onto each diverse device).

You'd be limited to 1 year certificates, browser vendors have set that to be the maximum length they will accept. Though any other software that requires a TLS connection would probably work fine with any length.

I could be wrong on this, but I don't think the 398-day limit applies to CA that you add to browsers yourself, only to CAs that are preinstalled.

See, for instance, Apple's announcement of the change, saying "This change will not affect certificates issued from user-added or administrator-added Root CAs."

And Mozilla I believe handles it as a requirement to be in their trusted root program, but doesn't actually add requirements within the browser for it. (They just treat CAs issuing longer certificates as not being compliant with their policy and could remove them if they keep mis-issuing, but again it wouldn't impact CAs that you add to their trust store yourself.)

So I think you could issue your own longer-lived certificates for your own private CA, if you felt comfortable with doing so.

2 Likes

I have seen conflicted information on that. Some people have reported that their browser won't accept 2 year certificates, but the documentation says otherwise.

I don't have any firsthand experience with that since i haven't issued any certificates from my private PKI since the change took effect.

So your mileage may vary

I'd say the main advantage of the private CA approach is just that you have ownership of the entire process, including using private internal-only DNS names and such. If you can use public names, just using public certificates is probably easier for a lot of things.

1 Like

For what it's worth, I've been running a good portion of my internal lab infrastructure on 10 year certs from a private CA that were signed in 2017 without any issues from Chrome, Firefox, Edge, or Edgeium. I don't have a Mac to use Safari with, but mobile Safari doesn't have any problems either.

I'm pretty sure most of the browser vendors are only targeting enforcement of these rules for varying definitions of "publicly trusted" certs.

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