the-one-cert

Throw a host header at it and it will proxy to it! No need to hardcode domains and upstreams in the configuration. Dynamically builds balancers and connection pools from the incoming host header. Could be a workaround for HTTP clients that don't use or leverage keepalives effectively, don't retry and/or don't load balance across all IPs in a DNS record. * Implements retries, keepalives (idle/persistent connection pooling) and load balancing when your client can't! * Optimised nginx Openresty config for speed and high traffic. https://github.com/openresty/docker-openresty * Dynamic connection pooling to any domain using lookups performed by Kong lua-resty-dns-client https://github.com/Kong/lua-resty-dns-client * resolves A, AAAA, CNAME and SRV records, including port * parses /etc/hosts * parses /resolv.conf and applies LOCALDO

You say that, but: https://github.com/flotwig/the-one-cert/issues/2

Look at the certificate details: https://github.com/flotwig/the-one-cert/blob/master/openssl.... You have to have a separate alt name specified for every possible number of subdomains. * does *not* match *.*, or *.*.*, etc

I realize this is not an overly serious project, but still.. To use this, you have to install node, and use that to run generate.js[1]... and what does generate.js do? 1. It generates an openssl.conf-file, which could have been checked into the repo as static content. 2. It runs a bash-script[2] which calls the openssl CLI-tool, with this config-file as a parameter. I get it that we are programmers, but how many layers of indirection are we going to add to what could have been a simple README, and pre-supplied config-file? Less is more. Not everything needs to be NodeJS. [1] https://github.com/flotwig/the-one-cert/blob/master/generate... [2] https://github.com/flotwig/the-one-cert/blob/master/run-open...