“Clients in that container won’t trust the cert”. Yeah, there’s the trick.
“service-a.lcl.host:443300“ so when inside the container, won’t that resolve to 127.0.0.1 which is the container internal loopback interface not the docker host’s interface? Hence trying to connect to itself not its sibling.
I’m skimming the docs looking for how “in containers” is handled and so far I can only see a one liner in the release notes. One problem in local environments I keep having and building tricks for is for services inside containers getting certs for other containers. From within the container, resolving to 127.0.0.1 isn’t helpful as that’s the internal loopback not the host.
My experience with visual scripting or coding is that it’s hard for more than one person to work on for anything other than a single screen of complexity. No git merge, so serial development. Hard to understand and tweak for anyone except the creator.
Looks helpful - have you chosen a license to release your parts under? So far it seems to build on BSD (GO) and some completely copyrighted extensions from (github.com/miekg/dns).
I have a work project this would help with, but at this point using it commercially feels a little shaky.
Burying the lede...
Unfortunately, at the time of this whitepaper being published - 86 days after Apache was notified of the vulnerability - 2.4.49 not yet come out, so although there's a patch on master, this is effectively a zero-day.
I also have to respect your chaotic neutral tactics by posting their trademark wording in its entirety, hence guaranteeing they're the first search hit for that phrase.