The CHT Core Framework makes it faster to build responsive, offline-first digital health apps that equip health workers to provide better care in their communities. It is a central resource of the Community Health Toolkit.
When proxying to HTTPS from HTTP (for example where an ingress does TLS termination), not including a 'servername' for a request to the HTTPS server (eg, def.org) the request produces the following error (where abc.com is the calling server):
'ERR_TLS_CERT_ALTNAME_INVALID'
"RequestError: Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames:
Host: abc.com. is not in the cert's altnames: DNS:def.org"
The addition of servername as an option passed to the HTTP agent resolves this error.
See docs for tls.connect(options[, callback]) (https://nodejs.org/api/tls.html): "Server name for the SNI (Server Name Indication) TLS extension. It is the name of the host being connected to, and must be a host name, and not an IP address.".
As of writing, I need to figure out why the e2e tests are failing.
Note: Have not changed the use of request-promise-native outside of calls to Couch.
For us this resolves the breakdown between node and haproxy. The Azure equivalent of ELB which medic uses is not an option for termination for a few reasons:
We're going to be offboarding our data through a Databricks instance so HTTPS to the haproxy instance is critical.
Deploying into a much larger network with a lot of access via VPN, so HTTPS as much as possible is useful as defense in depth strategy -- I'm more worried about attacks from inside the network than at my ingress.
Deploying sentinel, the api, an nginx (+modsec) proxy and a config container for cht-conf (using container jobs for being able to run the conf in network on changes) into an Azure Container App (managed kubernetes) environment. It has a lot of really nice benefits, but it does (as is a good idea, tbh) wrap each container in an HTTPS ingress termination. So while the haproxy instance isn't running in this env, eventually if we want to add sidecars this will be an issue.
When proxying to HTTPS from HTTP (for example where an ingress does TLS termination), not including a 'servername' for a request to the HTTPS server (eg, def.org) the request produces the following error (where abc.com is the calling server):
See docs for tls.connect(options[, callback]) (https://nodejs.org/api/tls.html): "Server name for the SNI (Server Name Indication) TLS extension. It is the name of the host being connected to, and must be a host name, and not an IP address.".
This pull request represents the current state of the work: https://github.com/medic/cht-core/pull/8579
As of writing, I need to figure out why the e2e tests are failing.
Note: Have not changed the use of request-promise-native outside of calls to Couch.
For us this resolves the breakdown between node and haproxy. The Azure equivalent of ELB which medic uses is not an option for termination for a few reasons: