Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Request Reaches Server But Not Jetty

You can verify if it's SSL/TLS related by turning on the JVM level debug for networking.

java /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 / joakim@xxxxxxxxxxx

On Fri, May 22, 2020 at 3:15 PM David C Fuhs <dfuhs@xxxxxxxxxxxx> wrote:
Good afternoon all:

Red Hat Enterprise Linux Server release 7.8 (Maipo)

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

jetty-users mailing list
To unsubscribe from this list, visit

Back to the top