Bug 997108
| Summary: | SSLHandshakeException on custom https port | ||
|---|---|---|---|
| Product: | OpenShift Online | Reporter: | matzew |
| Component: | Containers | Assignee: | Mrunal Patel <mpatel> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | libra bugs <libra-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2.x | CC: | 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: | |||
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. 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 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. Matthias Wessendorf <matthias> updated the status of jira AGPUSH-224 to Closed Matthias, Do you know why aerogear cartridge refuses connection over 8443? Thanks, Mrunal 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} 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. 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. 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. 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. 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.... 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"
Matthias Wessendorf <matthias> updated the status of jira AGPUSH-287 to Coding In Progress |
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