Mailing-List: contact user-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JMeter Users List" <user@jmeter.apache.org>
MIME-Version: 1.0
In-Reply-To: <CACTiXJr3_H9SHU+9BheVzBLAphAqRhzB2-qA_mKR9rOmO2nDeA@mail.gmail.com>
References: <8737357ae3017c4c11eddaf0adefad13@gmail.com> <CALbgBj_6CMUO1CUnbw=GovHTgBP57bObd3nfdOKvWxogFr9Wcg@mail.gmail.com>
 <8c434c93183b6716b467449026a4e2bb@gmail.com> <CAKUYAYdoWZVKcObqq1XBpo5fF96gffPHSi_W0gt8gB2sgtFZGQ@mail.gmail.com>
 <CACTiXJr3_H9SHU+9BheVzBLAphAqRhzB2-qA_mKR9rOmO2nDeA@mail.gmail.com>
From: Stuart Barlow <stuart.barlow@gmail.com>
Date: Fri, 4 Nov 2016 20:00:09 +0000
Message-ID: <CAAf-dGf5L3UJtWXAJ8Z5gM7PnVrr348cnPWOa+o=sjS6PxbY=A@mail.gmail.com>
Subject: Re: HttpClient SSL Handshake and self-signed certificate
To: JMeter Users List <user@jmeter.apache.org>
Content-Type: multipart/alternative; boundary=047d7b8748184abb8405407f2035
archived-at: Fri, 04 Nov 2016 20:00:49 -0000

--047d7b8748184abb8405407f2035
Content-Type: text/plain; charset=UTF-8

Thanks Steven. That's just what I was looking for.

On 30 October 2016 at 23:21, Steven Swor <sworisbreathing@gmail.com> wrote:

> Hi Stuart,
>
> The options you're looking for are at
> http://jmeter.apache.org/usermanual/get-started.html#proxy_server
>
> Note that, for whatever reason, Sun decided it was a good idea to separate
> non-proxy hosts by a pipe character instead of a comma, so if you're
> running on a non-Windows system, you'll need to surround the non-proxy
> hosts list with single-quote characters (e.g. -N 'server1|server2'),
> otherwise the shell is likely to interpret the pipe character as a shell
> pipe.
>
> Cheers,
> Steve
>
> On Sat, Oct 29, 2016 at 5:26 AM, Deepak Shetty <shettyd@gmail.com> wrote:
>
> > Hi
> > can you clarify what you mean.
> > The JMeter Proxy is used for recording a script - as such the browser
> needs
> > to be configured to send all requests to JMeter for it to record it - you
> > typically dont want to exclude things here (if you did , you'd configure
> > the browser to bypass the JMeter proxy for some hosts)
> >
> > This is different from how JMeter/java itself needing a proxy to make its
> > request successful (and Im guessing thats what you are referring to)
> > http://jmeter.apache.org/usermanual/get-started.html#proxy_server see -N
> > to
> > ignore (not a 100% sure that this works with httpclient but you can test
> > and see with different implementations)
> >
> >
> > On Fri, Oct 28, 2016 at 3:35 AM, Stuart Barlow <stuart.barlow@gmail.com>
> > wrote:
> >
> > > Hi Ivan,
> > >
> > > Thanks for your reply and the suggestions. I did give them all a try
> but
> > > none worked. I eventually figured out what the problem is but might
> still
> > > need some advice on how to handle it.
> > >
> > > There's an HTTP proxy in place in the intranet I work on and the
> website
> > > I'm testing goes through the proxy for most things but for some pages
> > (and
> > > for some nested resources like images) there is a direct connection.
> > >
> > > In JMeter I don't see a way to tell it to ignore the proxy for
> particular
> > > HTTP URL patterns. Does anyone know of a way to do this? Otherwise I'll
> > > install my own local proxy instance and configure it to redirect the
> > > requests as necessary.
> > >
> > > Stuart
> > >
> > >
> > > On 14.10.2016 15:13, Ivan Rancati wrote:
> > >
> > >> hi,
> > >> No idea whether JMeter validates the hostname. I thought not, as I
> have
> > >> some tests that access the server by IP address, and the server
> > >> certificate
> > >> has a hostname.
> > >> A couple of ideas to try to narrow down the problem
> > >>
> > >> - check jmeter.log
> > >> You should see some INFO entries from jmeter.util.SSLManager, see if
> > your
> > >> keystore and aliases are loaded as expected.
> > >> - java keytool problems
> > >> I once could not get the keytool to work (it might have been a OpenJDK
> > on
> > >> Linux issue, I did not get around to try with Oracle JDK); I exported
> > >> certificate/key to a .p12 file instead and it worked.
> > >>
> > >> Btw, for quicker troubleshooting, you can also pass all the SSL
> options
> > >> directly from the command line, as opposite to editing
> > jmeter.properties,
> > >> i.e.
> > >> -Djavax.net.ssl.keyStoreType=PKCS12
> > >>
> > >> hope this helps
> > >> Ivan
> > >>
> > >> On Fri, Oct 14, 2016 at 12:35 PM, Stuart Barlow <
> > stuart.barlow@gmail.com>
> > >> wrote:
> > >>
> > >> Hi
> > >>>
> > >>> In test environments self-signed certificates are common and they're
> > not
> > >>> always created in the right way. I'm trying to connect via HTTPS
> > Request
> > >>> to
> > >>> a website that uses a self-signed cert where the hostname is not
> > >>> correctly
> > >>> set inside the cert. The CN field has a value like "test-web-cert"
> and
> > >>> that
> > >>> cert is also used by two different domains. It's deployed for both
> > >>> https://www.test1.thirdpartywebsite.com and
> > >>> https://www.test2.thirdpartywe
> > >>> bsite.com
> > >>>
> > >>> I can access these websites from a browser and can view the
> certificate
> > >>> this way. The browser is more forgiving than JMeter. I tried
> exporting
> > it
> > >>> from the browser and importing into the truststore used by JMeter (I
> > set
> > >>> javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword in
> > >>> system.properties) and also into the cacerts in my JRE lib/security
> > >>> folder.
> > >>> Both of these didn't work.
> > >>>
> > >>> I always see this in the Response Tab of a Results Tree:
> > >>>
> > >>> java.net.SocketTimeoutException: Read timed out
> > >>>         at java.net.SocketInputStream.socketRead0(Native Method)
> > >>>         at java.net.SocketInputStream.socketRead(SocketInputStream.
> > java
> > >>> :116)
> > >>>         at java.net.SocketInputStream.read(SocketInputStream.java:
> 170)
> > >>>         at java.net.SocketInputStream.read(SocketInputStream.java:
> 141)
> > >>>         at sun.security.ssl.InputRecord.readFully(InputRecord.java:
> > 465)
> > >>>         at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> > >>>         at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.
> > >>> java:973)
> > >>>         at sun.security.ssl.SSLSocketImpl.
> > performInitialHandshake(SSLSo
> > >>> cketImpl.java:1375)
> > >>>         at sun.security.ssl.SSLSocketImpl.startHandshake(
> > SSLSocketImpl.
> > >>> java:1403)
> > >>>         at sun.security.ssl.SSLSocketImpl.startHandshake(
> > SSLSocketImpl.
> > >>> java:1387)
> > >>>         at org.apache.http.conn.ssl.SSLSocketFactory.
> > createLayeredSocke
> > >>> t(SSLSocketFactory.java:573)
> > >>>         at org.apache.http.conn.ssl.SSLSocketFactory.
> > createLayeredSocke
> > >>> t(SSLSocketFactory.java:447)
> > >>>         at org.apache.jmeter.protocol.http.sampler.
> > LazySchemeSocketFact
> > >>> ory.createLayeredSocket(LazySchemeSocketFactory.java:121)
> > >>>         at org.apache.http.impl.conn.DefaultClientConnectionOperato
> r.
> > >>> updateSecureConnection(DefaultClientConnectionOperator.java:219)
> > >>>         at org.apache.http.impl.conn.ManagedClientConnectionImpl.
> > layerP
> > >>> rotocol(ManagedClientConnectionImpl.java:421)
> > >>>         at org.apache.jmeter.protocol.http.sampler.
> > MeasuringConnectionM
> > >>> anager$MeasuredConnection.layerProtocol(MeasuringConnectionM
> > >>> anager.java:152)
> > >>>         at org.apache.http.impl.client.DefaultRequestDirector.
> > establish
> > >>> Route(DefaultRequestDirector.java:815)
> > >>>         at org.apache.http.impl.client.DefaultRequestDirector.
> > tryConnec
> > >>> t(DefaultRequestDirector.java:616)
> > >>>         at org.apache.http.impl.client.DefaultRequestDirector.
> > execute(D
> > >>> efaultRequestDirector.java:447)
> > >>>         at org.apache.http.impl.client.AbstractHttpClient.doExecute(
> > Abs
> > >>> tractHttpClient.java:884)
> > >>>         at org.apache.http.impl.client.CloseableHttpClient.execute(
> > Clos
> > >>> eableHttpClient.java:82)
> > >>>         at org.apache.http.impl.client.CloseableHttpClient.execute(
> > Clos
> > >>> eableHttpClient.java:55)
> > >>>         at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.
> > executeR
> > >>> equest(HTTPHC4Impl.java:619)
> > >>>         at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.
> sample(
> > >>> HTTPHC4Impl.java:379)
> > >>>         at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.
> > sam
> > >>> ple(HTTPSamplerProxy.java:74)
> > >>>         at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.
> > samp
> > >>> le(HTTPSamplerBase.java:1146)
> > >>>         at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.
> > samp
> > >>> le(HTTPSamplerBase.java:1135)
> > >>>         at org.apache.jmeter.threads.JMeterThread.
> > executeSamplePackage(
> > >>> JMeterThread.java:465)
> > >>>         at org.apache.jmeter.threads.JMeterThread.processSampler(
> > JMeter
> > >>> Thread.java:410)
> > >>>         at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.
> > java
> > >>> :241)
> > >>>         at java.lang.Thread.run(Thread.java:745)
> > >>>
> > >>> My theory at the moment is that the SSL handshake is dropped because
> of
> > >>> hostname validation. I'm trying to connect to
> > >>> https://www.test1.thirdpartywebsite.com but the certificate contains
> > >>> value test-web-cert. They don't match so the connection is dropped.
> I'm
> > >>> able to use curl with the -k option to retrieve the content if that's
> > >>> relevant.
> > >>>
> > >>> Can anyone tell me if there is a way in JMeter to disable hostname
> > >>> validation during SSL Handshake?
> > >>>
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Stuart
> > >>>
> > >>>
> > >>> ------------------------------------------------------------
> ---------
> > >>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > >>> For additional commands, e-mail: user-help@jmeter.apache.org
> > >>>
> > >>>
> > >>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > > For additional commands, e-mail: user-help@jmeter.apache.org
> > >
> > >
> >
>

--047d7b8748184abb8405407f2035--