Hacker News Reader

You could always switch to the Angie fork if you require the DNS challenge type with the wildcard domains:

https://en.angie.software/angie/docs/configuration/modules/h...

> allowing internally-signed certificates to be valid via said Intermediary

By design, nothing is allowed to delegate signing authority, because it would become an immediate compromise of everything that got delegated when your delegated authority got compromised. Since only CAs can issue certs, and CAs have to pass at least some basic security scrutiny, clients have assurance that the thing giving it a cert got said cert from a trustworthy authority. If you want a non-trustworthy authority... go with a custom CA. It's intentionally difficult to do so.

> If your load balancer, proxy server, web server, or router appliance can’t mint me a basic Acme certificate via DNS-01 challenges, then you officially suck and I will throw your product out for something like Caddy the first chance I get.

I mean, that's a valid ask. It will become more commonplace once some popular corporate offering includes it, and then all the competitors will adopt it so they don't leave money on the table. To get the first one to adopt it, be a whale of a customer and yell loudly that you want it, then wait 18 months.

> If you want a non-trustworthy authority... go with a custom CA. It's intentionally difficult to do so.

This is where I get rankled.

In IT land, everything needs a valid certificate. The printer, the server, the hypervisor, the load balancer, the WAP’s UI, everything. That said, most things don’t require a publicly valid certificate.

Perhaps Intermediate CA is the wrong phrase for what I’m looking for. Ideally it would be a device that does a public DNS-01 validation for a non-wildcard certificate, thus granting it legitimacy. It would then crank out certificates for internal devices only, which would be trusted via the Root CA but without requiring those devices to talk to the internet or use a wildcard certificate. In other words, some sort of marker or fingerprint that says “This is valid because I trust the root and I can validate the internal intermediary. If I cannot see the intermediary, it is not valid.”

The thinking goes is that this would allow more certificates to be issued internally and easily, but without the extra layer of management involved with a fully bespoke internal CA. Would it be as secure as that? No, but it would be SMB-friendly and help improve general security hygiene instead of letting everything use HTTPS with self-signed certificate warnings or letting every device communicate to the internet for an HTTP-01 challenge.

If I can get PKI to be as streamlined as the rest of my tech stack internally, and without forking over large sums for Microsoft Server licenses and CALs, I’d be a very happy dinosaur that’s a lot less worried about tracking the myriad of custom cert renewals and deployments.

Intermediates aren't a delegation mechanism as such. They're a way to navigate to the roots trust.

The trust is always in the root itself.

It's not an active directory / LDAP / tree type mechanism where you can say I trust things at this node level and below.

Appreciate the clarification! My grievance still stands, but at least I can articulate it better going forward.

But they could and IMO should be a delegation mechanism. The Name Constraints extension already exists.

The trouble is the constraint mechanism is outside of the inherent chain of trust logic and is checked using application level logic.

So you have to modify all potential clients for this constraint to be enforced. So it's effectively worthless as there is no way to roll it out in any meaningful sense.

Well you can use an admin box and a script to request like 1000 different certs of different names through DNS-01. Copy the certs to the devices that need them. The big problem now is, you have ~5 days to constantly re-copy new certs and reboot the devices, thanks to LE's decision to be super annoying. If you want less annoying... pay for certs.

Installing custom CA certs isn't that hard once you figure out how to do it for each application. I had to write all the docs on this for the IT team, specific to each application, because they were too lazy to do it. Painful at first, but easy after. To avoid more pain later, make the certs expire in 2036, retire before then.

The problem I continue to encounter is that delegating this to colleagues or other teams is that - inevitably - someone thinks they're clever bypassing part or all of the procedure to, say, generate a wildcard cert and share its private key component with whoever asks for a cert, instead of going through approved processes. At PriorBigCo, we had a dedicated team who just handled global internal PKI, and despite a 72hr turnaround we still had folks bypassing procedure. That results in revocations, which results in more time being spent dealing with "emergency" renewals, which just makes it a PITA.

Automation is the goal, and right now internal PKI is far from automated like public-facing certs are. With ACME I can set-and-forget on public stuff that's not processing sensitive data or requires a premium certificate for, but internally it still seems like the only solution is an ADCA.

Using CNAMEs with the _acme-challenge, plus API keys with fine-grained authorization, you can manage what each of those colleagues or teams can issue certs for. Disallowing wildcard certs for them, for example :)

> By design, nothing is allowed to delegate signing authority, because it would become an immediate compromise of everything that got delegated when your delegated authority got compromised.

Or because it would expose the web PKI for the farce it is. Some shady corporation in bumfuckistan having authority to sign certificates for .gov.uk or even just your personal website is absolutely bonkers. Certificate authority should have always been delegated just like nameserver authority is.

What company that has enough infrastructure to dictate an IT Department is also only using certificates on their web servers, and thus doesn't have a standard tool for issuing/renewing/deploying certificates for *all* services that need them?

DNS challenge is complicated by the fact that every registrar has their own API. HTTP is easier for nginx because it’s a single flow and it already does HTTP.

I’m sure nginx will get DNS but it’s still an open question when it will support your particular registrar or if at all.

> DNS challenge is complicated by the fact that every registrar has their own API

You can sidestep that by delegating the ACME keys to your own name server.