Bug 997108

Summary: SSLHandshakeException on custom https port
Product: OpenShift Online Reporter: matzew
Component: ContainersAssignee: Mrunal Patel <mpatel>
Status: CLOSED CURRENTRELEASE QA Contact: libra bugs <libra-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.xCC: bmeng, matzew, mpatel
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-29 12:51:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description matzew 2013-08-14 17:03:13 UTC
Description of problem:

SSLHandshakeException exception with self signed certificates on "custom" https ports (e.g. 8443).

Version-Release number of selected component (if applicable):


How reproducible:

This issue happens when a Java client, in our case the UnifiedPush Server, tries to use https against the SimplePush Server. The SimplePush server listens to port 8443 for https traffic and this issue does not occur when using port 443 thought that is not what the SimplePush Server listens to.

Actual results:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested targetmain, handling exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1836)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:276)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1337)
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:154)


Expected results:

no exception

Additional info:


There is a self signed certificate for the 8443 port, but a 'trusted' cert on 443.


Check here:
openssl s_client -connect tlsconf-dbevenius.rhcloud.com:8443


and the default port:
openssl s_client -connect tlsconf-dbevenius.rhcloud.com:443

In the last there are two entries in the Certificate chain (RedHat and GeoTrust)


It would be good if on 8443 we also have a signed certifcate, like on 443

Comment 1 Mrunal Patel 2013-08-14 22:57:11 UTC
I checked that we don't have SSLCertificateChainFile for node web proxy. We need to add it and add support for it in the code.

Comment 3 JBoss JIRA Server 2013-08-15 07:06:23 UTC
Matthias Wessendorf <matthias> made a comment on jira AGPUSH-224

Committed the suggested workaround.

The fix will be removed, once the fix for bugzilla 997108 has been verified

Comment 4 Meng Bo 2013-08-19 07:53:04 UTC
Checked this issue on latest INT env, (since the don't have SSL settings on devenv)

The 8443 return refused when testing with openssl 

# rhc create-app tlspush "https://cartreflect-claytondev.rhcloud.com/reflect?github=danbev/openshift-origin-cartridge-ag-unified-push&commit=b0004493ad8366a3eadf230e3baa83e32fddd80c" mysql-5.1

# openssl s_client -connect tlspush-bmengdev.int.rhcloud.com:8443
connect: Connection refused
connect:errno=111



For a normal app, both the 8443 and 443 can connect successfully.

Assign the bug back.

Comment 5 JBoss JIRA Server 2013-08-19 13:57:27 UTC
Matthias Wessendorf <matthias> updated the status of jira AGPUSH-224 to Closed

Comment 6 Mrunal Patel 2013-08-19 22:42:50 UTC
Matthias,
Do you know why aerogear cartridge refuses connection over 8443?



Thanks,
Mrunal

Comment 7 JBoss JIRA Server 2013-08-20 05:50:18 UTC
Daniel Bevenius <daniel.bevenius> made a comment on jira AGPUSH-287

@Mrunal Could you try recreating the application using the instructions provided here:
https://community.jboss.org/people/fjuma/blog/2013/08/19/downloadable-openshift-aerogear-push-server-cartridge-080

I've tried this and can then run the following command successfully:
{noformat}
openssl s_client -connect release-dbevenius.rhcloud.com:8443 
{noformat}

Comment 8 Meng Bo 2013-08-20 07:37:20 UTC
I have tried create new app with cartridge in comment#7 on INT.

Still get the same result.

# openssl s_client -connect tls-bmengdev.int.rhcloud.com:8443
connect: Connection refused
connect:errno=111


# rhc app show tls
tls @ http://tls-bmengdev.int.rhcloud.com/ (uuid: 52130e206cec0e079100095d)
---------------------------------------------------------------------------
  Domain:  bmengdev
  Created: 2:35 AM
  Gears:   1 (defaults to small)
  Git URL: ssh://52130e206cec0e079100095d.rhcloud.com/~/git/tls.git/
  SSH:     52130e206cec0e079100095d.rhcloud.com

  aerogear-aerogear-push-0.8.0 (AeroGear Push Server 0.8.0)
  ---------------------------------------------------------
    From:  https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push
    Gears: Located with mysql-5.1

  mysql-5.1 (MySQL Database 5.1)
  ------------------------------
    Gears:          Located with aerogear-aerogear-push-0.8.0
    Connection URL: mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT/
    Database Name:  tls
    Password:       <Hidden>
    Username:       <Hidden>


And when I creating same app on stage, the 8443 port can be connected.

Comment 9 JBoss JIRA Server 2013-08-20 10:21:44 UTC
Daniel Bevenius <daniel.bevenius> made a comment on jira AGPUSH-224

Can you take a look, or attach, server.log from the instance that does not work correctly? 
Perhaps there is an error upon startup. The log can be found in aerogear-push/logs/server.log.

Comment 10 Mrunal Patel 2013-08-20 19:43:01 UTC
There was a configuration issue on INT resulting in that error. It has been fixed now. Also, note that INT is using the same CA and SSL cert however, it will be different on prod once the release goes out.

Comment 11 Meng Bo 2013-08-21 03:28:04 UTC
Checked on latest INT(devenv_3680), the 8443 port can be connected via ssl client.

And according the commnet#10, the CA and SSL are the same on INT, And it will be different on PROD.

Move the bug to verified.

Comment 12 matzew 2013-09-13 06:57:27 UTC
This issue seems still be open:

openssl s_client -connect delete-pushee.rhcloud.com:8443


==>>  Only one cert in the "Certificate chain" (the self-signed cert)


Testing against the 'standard' port:
openssl s_client -connect delete-pushee.rhcloud.com:443


Two certs (as expected) certs in the chain....

Comment 13 matzew 2013-09-17 09:23:37 UTC
Running 'openssl s_client -connect delete-pushee.rhcloud.com:8443'

I am getting this:

Certificate chain
 0 s:/serialNumber=LnhzJHxcX0bIdlH2ITnDgaewey8ce5g3/C=US/ST=North Carolina/L=Raleigh/O=Red Hat Inc/OU=RHC Cloud Opoerations/CN=*.rhcloud.com
   i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFFzCCA/+gAwIBAgIDAf0eMA0GCSqGSIb3DQEBBQUAMEAxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEYMBYGA1UEAxMPR2VvVHJ1c3QgU1NM
IENBMB4XDTEzMDIwMjE5MTUzN1oXDTE1MDUwODAxNDkxM1owgbExKTAnBgNVBAUT
IExuaHpKSHhjWDBiSWRsSDJJVG5EZ2Fld2V5OGNlNWczMQswCQYDVQQGEwJVUzEX
MBUGA1UECBMOTm9ydGggQ2Fyb2xpbmExEDAOBgNVBAcTB1JhbGVpZ2gxFDASBgNV
BAoTC1JlZCBIYXQgSW5jMR4wHAYDVQQLExVSSEMgQ2xvdWQgT3BvZXJhdGlvbnMx
FjAUBgNVBAMMDSoucmhjbG91ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQCxAEY922gAMY6nxfwDS2gVLqePypw/jboknS274rnuppSmW1dQziCJ
fnL18kGLROsp+HoU/rdnvBQG/LhNhYWfD5w+sdB6ciUUM4/3u1CE1/gG5XcA/CD6
8u9cDg1Swyc0isex269x4IRmJX0bdPvH5BEIDaDpkeF+XjpMRWO88IvPsTljkm4N
PbiGWs57gNUzQV6i/NFH8opRW6IoJ8A78wwzfT3lylx4W2IzGHcbG/J4ydsTVYIr
hbC3qMA3uf8kSOYt1EIVFVbWQyAgCR3usn515HLjlkbMAFUsnTUb9h39NqtehuBL
Jv4ojClYtj+YzGDKlaLewxxVhh7LDIm9AgMBAAGjggGmMIIBojAfBgNVHSMEGDAW
gBRCeVQbYc1VKz5j1TxIV/Wf+0XOSjAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMCUGA1UdEQQeMByCDSoucmhjbG91ZC5jb22C
C3JoY2xvdWQuY29tMD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6Ly9ndHNzbC1jcmwu
Z2VvdHJ1c3QuY29tL2NybHMvZ3Rzc2wuY3JsMB0GA1UdDgQWBBS0VOLUqvJ1EhfN
8iFK2cswdQCuOzAMBgNVHRMBAf8EAjAAMG8GCCsGAQUFBwEBBGMwYTAqBggrBgEF
BQcwAYYeaHR0cDovL2d0c3NsLW9jc3AuZ2VvdHJ1c3QuY29tMDMGCCsGAQUFBzAC
hidodHRwOi8vZ3Rzc2wtYWlhLmdlb3RydXN0LmNvbS9ndHNzbC5jcnQwTAYDVR0g
BEUwQzBBBgpghkgBhvhFAQc2MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuZ2Vv
dHJ1c3QuY29tL3Jlc291cmNlcy9jcHMwDQYJKoZIhvcNAQEFBQADggEBAF6q7m65
Mf/fyL+J6s1Q2PHP886+6DWorFyMPMsXBXA/Ap4Hw3XyZD9GEB3J9nWJXazVbFeT
X9aowyeaGMzTjwS7EQDEW/WNm5kthJ0giTIl5WU5SigFZFddx1r7Tv8EiyouxeDE
kX+nX7SaikTGTKl5W46mwuLbAk3ujF7aNRt8ufrNE76RU5SoYGMKM2bFC2zXOW6z
Xh7Mv51bShWhCUA3H9US66PCAfLVd5ubiXWoha14aHHCFz20Tnpk0dPc4qwBj71i
5VXUR0y40gQ2BctAuyqRXC3MSnrAtCzpXlBlrZ151HufimLZI4IBbtrAd2mhBxq+
1szz2FmHB4SIzq8=
-----END CERTIFICATE-----
subject=/serialNumber=LnhzJHxcX0bIdlH2ITnDgaewey8ce5g3/C=US/ST=North Carolina/L=Raleigh/O=Red Hat Inc/OU=RHC Cloud Opoerations/CN=*.rhcloud.com
issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
---
No client certificate CA names sent
---
SSL handshake has read 1476 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: D4B1B77D961933AAD362EDB3424F0594554B6FF2CBA68FEA4F4C65DFCBF571CE
    Session-ID-ctx: 
    Master-Key: 8989A172015FF2ED19B0458D643DAB7C412909BBF5B94542B8DADE82D85EB00AEB81606792FB0ED2CC0793751806C00B
    Key-Arg   : None
    Start Time: 1379409734
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---



Note in the last line "unable to verify the first certificate"

Comment 14 JBoss JIRA Server 2013-09-20 06:47:46 UTC
Matthias Wessendorf <matthias> updated the status of jira AGPUSH-287 to Coding In Progress