Atlassian JIRA | Daniel Leng | 9 months ago
Do you know that we can give you better hits? Get more relevant results from Samebug’s stack trace search.
  1. 0

    h4. Problem Description Currently the REST API documentation has an example plugin called {{}} to demonstrate using OAuth to authenticate against JIRA's REST service. Link: However, this plugin has not been updated for a long time, and at the moment suffers from SNI errors when JIRA is running behind SSL NGinX with SNI: {code} java -jar requestToken https://my-jira-url Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( at sun.reflect.DelegatingMethodAccessorImpl.invoke( at java.lang.reflect.Method.invoke( at at com.simontuffs.onejar.Boot.main( Caused by: java.lang.RuntimeException: Failed to obtain request token at com.atlassian.oauth.client.example.AtlassianOAuthClient.getRequestToken( at com.atlassian.oauth.client.example.JIRAOAuthClient.main( ... 6 more Caused by: hostname in certificate didn't match: <my-jira-url> != <url1> OR <url2> OR <url3> at org.apache.http.conn.ssl.AbstractVerifier.verify( at org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify( at org.apache.http.conn.ssl.AbstractVerifier.verify( at org.apache.http.conn.ssl.AbstractVerifier.verify( at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket( {code} This is because the plugin is using an outdated version of the HTTPClient library, {{httpclient-4.0-beta2.jar}} SNI bug is fixed in httpclient 4.5.3: h4. Solution Update the plugin to use the newer version of the httpclient library, e.g. 4.5.3. h4. Workaround None.

    Atlassian JIRA | 9 months ago | Daniel Leng
  2. 0

    Dropbox bundle failing to start/authenticate in v1.3

    GitHub | 3 years ago | openhab-migration hostname in certificate didn't match: <> != <*>
  3. 0

    Indirect Apache HttpClient and hostname in certificate didn't match

    Stack Overflow | 4 years ago | Radek S hostname in certificate didn't match: &lt;> !=
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    SSLException when server cert uses SAN (Subject Alternative Name)

    Stack Overflow | 7 years ago | Alex Wise hostname in certificate didn't match: &lt;; != &lt;;
  6. 0

    Find or initialize the keystore needed to solve "hostname in certificate didn't match"

    Stack Overflow | 2 years ago | Atl LED hostname in certificate didn't match error. It's our hope to patch this temporarily while we write the replacement. I've read several SO questions on the mater (eg 1, 2, 3, 4) and it seemed like Will Sargent's solution was the best choice. Unfortunately I'm going into the server with utterly no documentation or returned email from the group that set it up (luckily none of the Java was obfuscated per policy). I looked for any keystore files (searching for "keystore" in the file name or .jks files), but I didn't find any. Which lead me think that I needed to make a new one and initialize it prior to calling the webClient.getPage. So far I have been able to make the .jks file just fine, it's just it doesn't change the hostname match error. Is there a way to see what keystore if any is being used by a servlet, and what its location happens to be? Alternatively, what is the proper way to make a new one and have it be used/initialized? Additional Details There are a few things about this that are odd to me. The main one is I don't understand why the hostname wouldn't be correct. The site being pulled is which if you navigate to it in a browser certainly pulls the correct certificate. I'm wondering if it's because the WebClient(BrowserVersion.FIREFOX_17) is set to the archaic FIREFOX_17. Should I just change that from 17 to 31? There are plenty of things that could be upgraded, but as we're going to start from scratch to have documentation, I want to change as little as possible on the old instance to hopefully keep it running for a few more months. The FIREFOX version installed on the server isn't close to current ether (not that it's used), but I was thinking changing the BrowserVersion just changed how the reply was formatted. Here is the code, ending on the line throwing the error: private Vector updateRDLpubs(Vector orderList, DataSource dataSource) throws Exception { Vector removeList = new Vector(); Vector historyList = new Vector(); try { SimpleDateFormat format = new SimpleDateFormat("MM/dd/yyyy"); Calendar cal = Calendar.getInstance(); cal.add(5, -5); Date days5Back = cal.getTime(); WebClient webClient = new WebClient(BrowserVersion.FIREFOX_17); webClient.setThrowExceptionOnFailingStatusCode(false); HtmlPage page = (HtmlPage)webClient.getPage(""); And here is the stack trace on the error: at org.apache.http.conn.ssl.AbstractVerifier.verify(

    1 unregistered visitors
    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis


      hostname in certificate didn't match: <my-jira-url> != <url1> OR <url2> OR <url3>

      at org.apache.http.conn.ssl.AbstractVerifier.verify()
    2. Apache HttpClient
      1. org.apache.http.conn.ssl.AbstractVerifier.verify(
      2. org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(
      3. org.apache.http.conn.ssl.AbstractVerifier.verify(
      4. org.apache.http.conn.ssl.AbstractVerifier.verify(
      5. org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(
      5 frames