In default scenario when ever any HTTP request has to be forwarded by reverse proxy scenario to remote server it doesn't play any important role if the original request was made by http:// or by https:// protocol.
On the example, let's assume the gateway server was setup to forward http(s)://my-custom-gateway.com/~~remoteserver1 requests to internal server 192.168.55.77.
Usually secure SSL https:// protocol would be firstly decrypted on gateway side, then second TCP connection would be created and the traffic would be forwarded "as is", also in decrypted raw http request format. This is pretty CPU effective since there is no more reencryption done but on another side that is lesser secure since it allows network filters or any other third part programs to sniff the raw traffic forwarded to specified subserver. To avoid this potential man-in-the-middle attack scenario you can follow next steps.
The settings that are controlling reverse proxy behavior are contained inside *\Clients\webserver\balance.bin file
As per example above
/~~remoteserver1=192.168.55.77:443;
/~~remoteserver1=192.168.55.77:3389 RDPPORT;
First line says to forward http(s) traffic to target remote server on specified port, and second line says, when ever RDP protocol was detected with used RDP cookie /~~remoteserver1 then forward it to specified server with specified RDP port, in example default 3389. If this line was not given then RDP requests would be forwarded to same address as specified for http(s) protocol.
Adapting the line like in example with leading "SSL " tag would force usage of SSL reencryption.
SSL /~~remoteserver1=192.168.55.77:443;
/~~remoteserver1=192.168.55.77:3389 RDPPORT;
Remember, SSL tag makes no sense by "* RDPPORT;" since initial SSL tunnel would be rejected by RDP server usually.
Except "SSL " tag there are more settings like SSL_STRICT, SSL_JVM_TM and SSL_JVM_TM_STRICT
SSL /~~remoteserver1=192.168.55.77:443;
default, allow any certificate, different than initially on gateway server, or self signed, outdated etc. This scenario in fact doesn't increase security since man-in-the-middle could simulate any target certificate but adds anyway higher grad of security.
SSL_STRICT /~~remoteserver1=192.168.55.77:443;
same as SSL, but public keys must match, this will require to copy cert.jks from gateway to target subserver (in example 192.168.55.77) to make such connection to work. This is most preferable setting giving high security by any scenario however requires same cert.jks on subserver as on gateway. If cert.jks gets renewed the server will stop being able to create secured ssl tunnel.
SSL_JVM_TM /~~remoteserver1=192.168.55.77:443;
same as SSL, but public/private key must be signed by authority and certificate domain must match the request. No self signed certificates allowed, however the certificate doesn't need to match with original request on gateway.
SSL_JVM_TM_STRICT /~~remoteserver1=192.168.55.77:443;
highest security, signed public key and domain must match and be valid.