Currently, SSL for HTTP endpoints on warpgate only works in these two cases with externally mapped domains:
The externally mapped domain (eg. git.domain.com) is on the same domain as warpgate (eg. warpgate.domain.com) and warpgate uses a wildcard certificate. Or in case where warpgate runs on a domain wg.domain.com and the services are git.wg.domain.com with a wildcard for *.wg.domain.com.
Warpgate is running behind a load balancer, which handles SSL termination with multiple certificates.
We have a use case where we'd like to have multiple such SSL certificates handled by warpgate itself, instead of the load balancer for simpler deployments. This would allow us to run services on multiple domains (.net, .com, .io, etc) and put them behind warpgate. This is particularly useful in cases where there's multiple organizational domains, each for a particular group of users.
Currently, SSL for HTTP endpoints on warpgate only works in these two cases with externally mapped domains:
git.domain.com) is on the same domain as warpgate (eg.warpgate.domain.com) and warpgate uses a wildcard certificate. Or in case where warpgate runs on a domainwg.domain.comand the services aregit.wg.domain.comwith a wildcard for*.wg.domain.com.We have a use case where we'd like to have multiple such SSL certificates handled by warpgate itself, instead of the load balancer for simpler deployments. This would allow us to run services on multiple domains (
.net,.com,.io, etc) and put them behind warpgate. This is particularly useful in cases where there's multiple organizational domains, each for a particular group of users.Let me know what you think of this.