Hi Randy,,
The CGI variables don't show an HTTPS connection because the request was proxied from NGINX to Tomcat over an unsecured HTTP connection rather than HTTPS. It is a local connection in most circumstances so it's not a security risk. So, the CGI variable is correct that the immediate connection that was used was a simple HTTP connection.
To adjust for this different environment you could either modify the application code to check the additional header in addition to the CGI value, or I believe Tomcat provides some valves that will inject additional HTTPS headers into the proxied request headers if you want to keep your code portable between environments.
Example Tomcat valve:
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/valves/SSLValve.html... however, I don't recall ever using those valves myself. Either way, you're not the first person to encounter this and solutions do exist.
You could install an SSL certificate on Tomcat and proxy over the HTTPS connection if you wanted to, but that'd kind of be a waste of CPU cycles IMO and you would also have the opposite issue of always getting a HTTPS connection in your CGI variables regardless of whether the original request was HTTP or HTTPS. So... personally I would just check for the extra headers if you want to verify SSL was used.
Headers are kind of an untamed beast in the HTTP world IMO. I have been working in the industry for decades now and I just recently learned that there's no official way (that I have found) for a server to communicate it's maximum request size to a client. I ended up using a custom response header in an OPTIONS request. The Internet is how old again? How is this still a thing?? lol
Anyway, hope this helps. =)
-Jordan