You can verify if it's SSL/TLS related by turning on the JVM level debug for networking.
java -Djavax.net.debug=all /path/to/jetty-home/start.jar Also of note, Jetty will output debug logging for SSL/TLS related efforts within Jetty as well. No debug logs means no traffic, not even an attempted connection (let alone the SSL/TLS negotiation step). Might want to check the jetty logging setup you have chosen to make sure that it logs. Hit Jetty directly (not via the frontend servers), it should spew out tons of log entries, even for a bad request (like attempting to use netcat to send plain HTTP on the SSL port) Joakim Erdfelt / [email protected] On Fri, May 22, 2020 at 3:15 PM David C Fuhs <[email protected]> wrote: > Good afternoon all: > > Red Hat Enterprise Linux Server release 7.8 (Maipo) > jetty-distribution-9.4.28.v20200408 > java-11-openjdk-11.0.7.10-4.el7_8.x86_64 > jetty.ssl.port=8443 > jetty.http.port=8080 > > We are configuring a Shibboleth IdP V4 server on a combination of Red Hat > Linux, the OpenJDK bundled with RHEL, and Jetty 9.4.28. > > We have an existing Shibboleth IdP V3.3.3 running in production on older > versions of RHEL, Java, and Jetty with no problems. > > Jetty on the new server is starting with no errors. The IdP running on > Jetty is also starting with no errors. > > Our network team has confirmed that ports 80, 8080, 443, and 8443 are all > open to the new server. > > Our system administrator says the same for host-based firewalls, also that > traffic coming in on port 443 on the new server is getting redirected to > port 8443. > > However, no port 443/8443 traffic is making to Jetty. I have Jetty > logging set to debug. There are no entries at all in $JETTY_BASE/jetty.log > or access.log for any requests. > > Jetty is protected by a PKCS12 keystore which contains a brand-new > certificate with the correct hostnames, plus intermediate/CA certificates. > > Running openssl or keytool indicates that the new keystore is structured > exactly the same way as the keystore on the current production IdP servers, > only the certificates themselves are different. > > Essentially what is going on is that our network team and system > administrators believe that nothing is wrong with network or host-based > firewalls and that there is an SSL handshake problem with Jetty. > > However, the Jetty logs are empty and indicate that no traffic of any kind > is hitting Jetty. > > I can provide redacted configuration, host firewall rules, etc., as needed. > > What are we missing? How can we track down the error? > > Thanks in advance. > > David Fuhs > Information Security Office > California State University, Chico > [email protected] > 530-898-4852 > > _______________________________________________ > jetty-users mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
