Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
Date: Mon, 27 Mar 2017 17:20:41 +0000 (UTC)
From: "Mark McKenna (JIRA)" <jira@apache.org>
To: dev@brooklyn.apache.org
Message-ID: <JIRA.13057687.1490043852000.133784.1490635241988@Atlassian.JIRA>
In-Reply-To: <JIRA.13057687.1490043852000@Atlassian.JIRA>
References: <JIRA.13057687.1490043852000@Atlassian.JIRA> <JIRA.13057687.1490043852501@jira-lw-us.apache.org>
Subject: [jira] [Commented] (BROOKLYN-456) "SSLException: internal_error"
 upon trying to connect to site requiring SNI
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 27 Mar 2017 17:20:52 -0000


    [ https://issues.apache.org/jira/browse/BROOKLYN-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15943671#comment-15943671 ] 

Mark McKenna commented on BROOKLYN-456:
---------------------------------------

[~geomacy] I just tried the below test code pointing at https://httpbin.org/get and it worked ... Although i believe there is something up with the ssl cert as i had to trust all certs 


{code}
public void testApacheHttpClent() throws IOException, KeyStoreException, NoSuchAlgorithmException, KeyManagementException {
    final CloseableHttpClient httpclient = HttpClients.custom()
            .setSSLContext(new SSLContextBuilder().loadTrustMaterial((chain, authType) -> true).build())
            .setSSLHostnameVerifier(NoopHostnameVerifier.INSTANCE).build();
    try {
        final HttpGet httpget = new HttpGet("https://httpbin.org/get");
        System.out.println("Executing request " + httpget.getRequestLine());
        // Create a custom response handler
        final ResponseHandler<String> responseHandler = response -> {
            int status = response.getStatusLine().getStatusCode();
            if (status >= 200 && status < 300) {
                final HttpEntity entity = response.getEntity();
                return entity != null ? EntityUtils.toString(entity) : null;
            } else {
                throw new ClientProtocolException("Unexpected response status: " + status);
            }
        };
        String responseBody = httpclient.execute(httpget, responseHandler);
        System.out.println("----------------------------------------");
        System.out.println(responseBody);
    } finally {
        httpclient.close();
    }
}
{code}

cc [~aled.sage@gmail.com]

> "SSLException: internal_error" upon trying to connect to site requiring SNI
> ---------------------------------------------------------------------------
>
>                 Key: BROOKLYN-456
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-456
>             Project: Brooklyn
>          Issue Type: Bug
>            Reporter: Geoff Macartney
>            Priority: Minor
>
> On 17th March brooklyn-server builds began failing, such as https://builds.apache.org/view/Brooklyn/job/brooklyn-server-master/492/. 
> The errors were failures in tests 
> {quote}
> org.apache.brooklyn.camp.brooklyn.HttpCommandEffectorYamlRebindTest.testRebindWhenHealthy
> org.apache.brooklyn.camp.brooklyn.HttpCommandEffectorYamlTest.testHttpCommandEffectorWithParameters
> org.apache.brooklyn.camp.brooklyn.CompositeEffectorYamlRebindTest.testRebindWhenHealthy
> org.apache.brooklyn.camp.brooklyn.CompositeEffectorYamlTest.testCompositeEffector
> {quote}
> all of which issued requests to "https://httpbin.org" for test purposes.
> There seems to have been a change in configuration on httpbin.org on the 16h of March, see [here|https://lists.apache.org/thread.html/2d7bfb556b5459590d266d079043861bc34c0b921a2b5346ae9fd8ae@%3Cdev.brooklyn.apache.org%3E].
> However the certificate changes appear not to be the problem, as far as I can tell, as the certificate chain from the site has root "Let's Encrypt Authority X3" (SHA1 Fingerprint=E6:A3:B4:5B:06:2D:50:9B:33:82:28:2D:19:6E:FE:97:D5:95:6C:CB), which is signed by CA "DST Root CA X3"  (Certificate fingerprint DA:C9:02:4F:54:D8:F6:DF:94:93:5F:B1:73:26:38:CA:6A:D7:7C:13), which is in the cacerts file of Java 8 by default.
> I believe the problem lies on the Java SSL client side, specifically that the client is not including the SNI (Server Naming Indicator) extension in the SSL handshake.  httpbin requires this, compare 
> {code}
> openssl s_client -showcerts -connect httpbin.org:443  </dev/null
> CONNECTED(00000003)
> 7944:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.60.1/src/ssl/s23_lib.c:185:
> {code}
> with the output from 
> {code}
> openssl s_client -servername httpbin.org  -showcerts -connect httpbin.org:443  </dev/null
> {code}
> The result is that the connection attempt fails with 
> {code}
> SSLException: Received fatal alert: internal_error
> {code}
> Searching around the web there seem to be a number of other people who have encountered this problem, e.g. https://forums.aws.amazon.com/message.jspa?messageID=669911.  The issue seems to be fixed only in Java 9, but there may be workarounds on 7 and 8. I haven't tried these out yet. 
> I will look at adding a test in Brooklyn to record this.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)