Joe, Thank you for replying.
The two certificates are almost identical. Same servers in the extensions. CRL file is different but its actually smaller in the "slow" certificate. I peeked into the packets on the server side (pond side) and it seems that the delay occurs somewhere in the middle of the TLS hadshake. Somewhere around the Change Cipher Spec phase. But only from this .Net client of my customer. I tried to fiddle with the pound config (2.6). I set the Cipher to SSLv3 but that didn't help. Thank you, OpenDog On Jun 21, 2013, at 11:06 AM, Joe Gooch <[email protected]> wrote: > Sometimes the client can delay trying to download the CRL… Check the cert to > see what the distribution points are, and if the clients can actually get to > them. > > I find this a lot with certificates generated from an internal MS Certificate > authority – since by default, MS tends to publish the server’s FQDN (which > might be internal) or an LDAP url that only works if you’re on the domain. > > Joe > > From: OpenDog [mailto:[email protected]] > Sent: Thursday, June 20, 2013 9:19 PM > To: [email protected] > Subject: [Pound Mailing List] Client timeouts after server certificate change > > Howdy, > > We've been running a simple setup on 2 remote tomcats for 2 years. > The app is a simple web service. > > We needed to change the top domain so we purchased 2 new server certificates. > After plugging in the new server certificates and changing the DNS alias we > started > to experience client timeouts. The clients are .Net web service clients. > After bumping > up the Client parameter to 30 seconds the timeouts were gone but the delay is > still there. > > I know it's a long shot. But has anybody seen this before? > > Also is the client timeout a simple socket level read (poll) or the SSL > negotiation is part of it? > > Thank you in advance for pointing me to the right direction. > > OpenDog > > -- > OpenDog > [email protected] > -- OpenDog [email protected]
