Re: HttpClient SSL Handshake and self-signed certificate
Thanks Steven. That's just what I was looking for. On 30 October 2016 at 23:21, Steven Swor 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 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 > > 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.bar...@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(
Re: HttpClient SSL Handshake and self-signed certificate
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 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 > 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.bar...@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.startH
Re: HttpClient SSL Handshake and self-signed certificate
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 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 >> 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.DefaultClientConnectionOperator. >>> 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 >>> a
Re: HttpClient SSL Handshake and self-signed certificate
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 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.DefaultClientConnectionOperator. 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
Re: HttpClient SSL Handshake and self-signed certificate
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 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.DefaultClientConnectionOperator. > 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 > htt
HttpClient SSL Handshake and self-signed certificate
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.thirdpartywebsite.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(SSLSocketImpl.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.createLayeredSocket(SSLSocketFactory.java:573) at org.apache.http.conn.ssl.SSLSocketFactory.createLayeredSocket(SSLSocketFactory.java:447) at org.apache.jmeter.protocol.http.sampler.LazySchemeSocketFactory.createLayeredSocket(LazySchemeSocketFactory.java:121) at org.apache.http.impl.conn.DefaultClientConnectionOperator.updateSecureConnection(DefaultClientConnectionOperator.java:219) at org.apache.http.impl.conn.ManagedClientConnectionImpl.layerProtocol(ManagedClientConnectionImpl.java:421) at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.layerProtocol(MeasuringConnectionManager.java:152) at org.apache.http.impl.client.DefaultRequestDirector.establishRoute(DefaultRequestDirector.java:815) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:616) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:447) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:884) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:619) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:379) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1146) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1135) at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:465) at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.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-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
