Sudden increase in handshake duration

#1

I am a bit at a loss right now.

I’ve had a setup for quite some time now where I have configured an LE wildcard certificate in a custom Java application. So far, so good. That worked great for about the past six months until about yesterday or two days ago (cant pinpoint it precisely I am afraid), when the establishing of the TLS connection suddenly started to take “ages”, about 15 seconds. This appears to affect exclusively browsers (Firefox and Chrome) and there was no apparent change or upgrade to either configuration (neither browsers nor server side nor the certificate). From my perspective it started out of the blue.

One thing I noticed during my debug attempts so far is that I hadnt configured the intermediate certificate but only sent the actual site certificate. Adding the former one hasnt changed anything however.

Assuming, for the time being, that it is not a local issue my immediate thought would have been that there might be some problem with the live revocation check, however that does not seem to be the case.

As I said, I am a bit at a loss right now, would anybody have a possible explanation why that might suddenly start without any apparent local changes?

Thank you!

#2

Hi @dave.higgins

to check that, we need your domain name.

#3

I am afraid the machine is on a closed network.

I was merely wondering what could be a possible reason for that behaviour. Typically my first guess would have been a delay certificate revocation check, but that does not seem to be the case here. Could there be anything else?

#4

There are thousand reasons possible that a connection is slow. So it’s mindless to speculate.

PS: There is a list of Third-party-tools to check a domain:

But that requires incoming connections.

A closed network to debug from outside - that’s not really possible.

#5

No explanation, but have you considered debugging with Wireshark?

#6

The connection itself is okay, it specifically is the handshake.

I am aware of that :neutral_face:

I was hoping to be able to avoid that :smile:, but I guess I will have to go that route.

#7

There’s nothing more fun than tracking and debugging the packages of a network connection! :smiley:

1 Like
#8

Maybe you can try change it with some self signed cert so it’s letsencrypt problem

1 Like
#9

This was actually an excellent idea. Same issue with a self-signed certificate, so I can definitely rule out LE. Thanks @orangepizza

1 Like
#10

Sudden MTU changes somewhere along the network path (sometimes in combination with certain types of network filtering) can look like this.

Lowering MTU to something like 1300 is a decent way to exclude it.

3 Likes
#11

That would have been a lovely idea, unfortunately it does not seem to fix it either.

Reduced it to 1300, 1000, 800, and 500 and the issue remained.

Well, out of LE’s scope :slight_smile:

#12

Possibly the software at your end is doing some kind of lookup in connection with each incoming connection before allowing the connection to complete (for example, a reverse DNS lookup).

4 Likes
#13

You appear to have hit the nail on the head.

I am actually a bit embarrassed and disappointed I havent thought of that earlier, as I had a similar issue years ago but in this case I completely ignored that possibility. It seems to be the exact issue as the one at https://coderanch.com/t/656284/java/HttpsServer-SSL-extremely-slow-times

Now I just need to find out how to convince Java to refrain from the lookup :slight_smile:

Thanks a million @schoen

2 Likes
closed #14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.