Bug 25505 - First HTTP sampling fails with "HTTPS hostname wrong: should be <localhost>"
Summary: First HTTP sampling fails with "HTTPS hostname wrong: should be <localhost>"
Status: RESOLVED FIXED
Alias: None
Product: JMeter - Now in Github
Classification: Unclassified
Component: Main (show other bugs)
Version: 1.9.1
Hardware: Other other
: P3 normal with 1 vote (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-14 00:27 UTC by Jordi Salvat i Alabart
Modified: 2007-04-10 06:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jordi Salvat i Alabart 2003-12-14 00:27:47 UTC
On (at least) JDK 1.4.0 and 1.4.2_02, both on current CVS and 1.9.1, the first
HTTPS sample run after starting JMeter always fails. Subsequent samples work
properly.

[Workaround: create a stupid sample at the very beginning of your test]

Errors thrown:

ERROR - jmeter.util: Couldn't load keystore java.lang.Exception: No key found
        at
org.apache.jmeter.util.keystore.DefaultKeyStore.load(DefaultKeyStore.java:109)
        at org.apache.jmeter.util.SSLManager.getKeyStore(SSLManager.java:210)
        at org.apache.jmeter.util.JsseSSLManager.getContext(JsseSSLManager.java:208)
        at org.apache.jmeter.util.JsseSSLManager.<init>(JsseSSLManager.java:136)
       at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
       at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
        at org.apache.jmeter.util.SSLManager.getInstance(SSLManager.java:318)
        at
org.apache.jmeter.protocol.http.sampler.HTTPSampler.setupConnection(HTTPSampler.java:584)
        at
org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:953)
        at
org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:445)
        at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:277)
        at java.lang.Thread.run(Thread.java:534)
                                                                                
and later:

WARN  - jmeter.protocol.http.sampler.HTTPSampler: HTTPS hostname wrong:  should
be <localhost> java.io.IOException: HTTPS hostname wrong:  should be <localhost>
        at sun.net.www.protocol.https.HttpsClient.b(DashoA6275)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(DashoA6275)
        at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(DashoA6275)
        at
com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl.connect(DashoA6275)
        at
org.apache.jmeter.protocol.http.sampler.HTTPSampler.connect(HTTPSampler.java:889)
        at
org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:961)
        at
org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:445)
        at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:277)
        at java.lang.Thread.run(Thread.java:534)
Comment 1 Sonam Chauhan 2003-12-17 23:46:10 UTC
I confirm this bug occurs in JMeter 1.9.1 and JMeter CVS (Version 
1.9.20031210.) I am using this Java version:
---
java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)
---


When this bug occurs, I see the following in the 'View Results Tree':

Request Data:
----------------
null
https://b2buat.ce.com.au:9999/invoke/CEShoppingSession.handler.au.OCI/entry
----------------
Response Data:
----------------
java.io.IOException: HTTPS hostname wrong:  should be <b2buat.ce.com.au>
----------------

This bug is only for the first HTTPS connection. 
In the very next HTTPS connection, the request is fine:
----------------
GET blah...
----------------
The response is normal too. 


I don't know how to obtain the stacktraces below... will ask on JMeter-users.
Comment 2 Sonam Chauhan 2004-03-25 07:25:35 UTC
This problem seem to occur due to expired digital certificates. i.e. A "proper" 
digital X.509 server certificate seems to fix the problem.

We normally use expired certs on our test servers (which are the only servers 
we use JMeter on). Today, we installed a "proper" digital certificate (the one 
we installed today is from Thawte) on one of our servers. Earlier, JMeter 
consistently got the first HTTPS connection malformed  against this server -- 
now this error suddenly went away. 

I then tested JMeter against two test servers with expired digital 
certificates -- the first HTTPS request stayed malformed. Next, I tested with 
two servers with valid certificates -- the first HTTPS request worked off.


Note, to replicate this problem, you need to restart JMeter between two HTTPS 
requests. 

I did not test with self-issued certificates. 
Comment 3 Sonam Chauhan 2006-04-07 10:37:00 UTC
JMeter 1.9.1 showed different (and anomalous) behavior dealing with the same 
expired certificates -- it gave out the misleading error "HTTPS hostname 
wrong: should be <localhost>" error, and only the first SSL connection would 
fail. 

The error message in JMeter 2.2.1 is now accurate, and all HTTPS connections 
(not just the first) fail consistently with the following exception below:

EXCEPTION MESSAGE 
==================
javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateExpiredException: NotAfter: Sat Nov 12
10:22:14 EST 2005
	at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
	at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275)
	at
sun.net.www.protocol.https.HttpsClient.afterConnect(DashoA6275)
	at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Da
shoA6275)
	at
com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl.co
nnect(DashoA6275)
	at
org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.j
ava:424)
	at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSampl
erBase.java:514)
	at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSampl
erBase.java:503)
	at
org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:247)
	at java.lang.Thread.run(Thread.java:534)
Caused by: java.security.cert.CertificateExpiredException: NotAfter: Sat
Nov 12 10:22:14 EST 2005
	at
sun.security.x509.CertificateValidity.valid(CertificateValidity.java:268
)
	at
sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:564)
	at
sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.ja
va:123)
	at sun.security.validator.Validator.validate(Validator.java:202)
	at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Das
hoA6275)
	at
com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(Das
hoA6275)
	... 14 more
Comment 4 Sebb 2006-04-07 13:53:18 UTC
(In reply to comment #3)

> The error message in JMeter 2.2.1 is now accurate, and all HTTPS connections 

I presume this means 2.1.1 ? 2.2.1 does not exist (yet)

Comment 5 Sebb 2006-04-08 01:42:05 UTC
Fixed in JMeter 2.1.1; won't fix in 1.9.1
Comment 6 Sonam Chauhan 2006-04-10 02:19:22 UTC
Seb: yes, it was 2.1.1 -- not 2.2.1 -- sorry. 
Comment 7 Sebb 2006-04-17 21:20:28 UTC
Discovered that the problem was not fully solved in 2.1.1 - the message would
still appear for certain valid certificates. The problem was that the SSLManager
was being initialised after creating the first connection. This has now been
fixed in the 2.1 branch.
Comment 8 Dan Keeley 2007-04-10 06:05:35 UTC
I can confirm that an example we saw of this problem in 2.1.1 is indeed fixed in
2.2.
Comment 9 The ASF infrastructure team 2022-09-24 20:37:32 UTC
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/1279