How to configure WSO2 ESB SSL access with HostnameVerifier AllowAll - ssl

I have been struggling with the configuration of WSO2 ESB for a few days now when trying to access an https web service. I have followed numerous pieces of advice and what I have done so far is to
import the web service client certificate into client-truststore.jks in repostory/resources/security
added proxy access parameters to repository/conf/axis2/axis2.xml (because the ESB is behind corporate firewall)
added AllowAll parameter to transportSender https in axis2.xml
restarted esb and still get the exception
http-nio-9443-exec-50, SEND TLSv1 ALERT: fatal, description = certificate_unknown
http-nio-9443-exec-50, WRITE: TLSv1 Alert, length = 2
http-nio-9443-exec-50, called closeSocket()
http-nio-9443-exec-50, handling exception: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching my.domain.com found
http-nio-9443-exec-50, WRITE: TLSv1 Application Data, length = 1
http-nio-9443-exec-50, WRITE: TLSv1 Application Data, length = 154
I am using jdk1.6_34 and tried with WSO2 ESB 4.5.1 and 4.6 with the same results.
The logging is showing the ssl handshake being started but then ends with the error above. All the googling suggests that the hostnameverifier parameter should do the trick but clearly doesn't. Is there somewhere else I should be configuring this or if this parameter is being overridden somewhere else? I have run out of options and places to look with this.
Edit:
I have had another attempt at this and by setting the host name in my hosts file to the CN specified in the client certificate I can now get a bit further but I am now getting another error which I can't seem to fathom out.
The specific error is "... no IV used for this cipher", but with the debug trace being
Found trusted certificate:
[
[
Version: V1
Subject: CN=mydomain.com, O=my o, ST=INTERFACES, C=GB
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 1024 bits
modulus:#### loads of numbers here ####
public exponent: 65537
Validity: [From: Mon Apr 22 14:26:25 BST 2013,
To: Tue Apr 22 14:26:25 BST 2014]
Issuer: CN=ath-st2-API-a, O=Northgate IS, ST=INTERFACES, C=GB
SerialNumber: [ a4cf31a6 9c0d920d]
]
Algorithm: [SHA1withRSA]
Signature:
### signature here ###
]
http-nio-9443-exec-13, READ: SSLv3 Handshake, length = 98
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:
<CN=mydomain.com, O=my o, ST=INTERFACES, C=GB>
*** ServerHelloDone
http-nio-9443-exec-13, SEND SSLv3 ALERT: warning, description = no_certificate
http-nio-9443-exec-13, WRITE: SSLv3 Alert, length = 2
*** ClientKeyExchange, RSA PreMasterSecret, SSLv3
http-nio-9443-exec-13, WRITE: SSLv3 Handshake, length = 132
SESSION KEYGEN:
PreMaster Secret:
###master secret here ####
CONNECTION KEYGEN:
Client Nonce:
0000: 52 45 86 22 10 B0 E2 EF 19 10 B1 04 ED C9 6F B0 RE."..........o.
0010: C3 8E BC D6 2C C9 5E D0 CA 8E 88 6B 22 53 1D B0 ....,.^....k"S..
Server Nonce:
0000: 52 45 86 23 B0 56 30 EC 84 F0 48 C1 F7 31 0C 5C RE.#.V0...H..1.\
0010: 43 B3 CB 25 DA 19 4C 0E B1 71 CB 17 8E 0C 62 04 C..%..L..q....b.
Master Secret:
0000: C3 F4 6B 9B EB 50 67 BD 6C A8 F0 63 88 A1 5A C7 ..k..Pg.l..c..Z.
0010: E5 CD A4 9A 46 95 3F B3 13 2D 4E BF 77 2C 64 86 ....F.?..-N.w,d.
0020: 44 D2 89 B5 09 EE 96 E5 8B 8D E2 30 04 09 F2 D3 D..........0....
Client MAC write Secret:
0000: F7 76 83 C9 16 F5 CB 33 E3 43 3F 7B 68 2E 8A 6F .v.....3.C?.h..o
Server MAC write Secret:
0000: CC FB 14 CE 21 AD C8 BC 20 C1 A5 2B 0B 2B 83 35 ....!... ..+.+.5
Client write key:
0000: 9C 9E FA A5 68 6E 27 2C E0 6E 80 9D ED C9 1C 01 ....hn',.n......
Server write key:
0000: B7 5A 24 DD 6F 65 5A 7E C8 AD 4A 29 E4 09 08 6D .Z$.oeZ...J)...m
... no IV used for this cipher
http-nio-9443-exec-13, WRITE: SSLv3 Change Cipher Spec, length = 1
*** Finished
verify_data: { 174, 247, 182, 190, 5, 104, 242, 127, 216, 79, 94, 15, 215, 236, 236, 211, 30, 51, 116, 56, 138, 144, 19, 125, 0, 54, 52, 114, 173, 138, 170, 166, 24, 67, 108, 102 }
***
http-nio-9443-exec-13, WRITE: SSLv3 Handshake, length = 56
http-nio-9443-exec-13, READ: SSLv3 Alert, length = 2
http-nio-9443-exec-13, RECV SSLv3 ALERT: fatal, handshake_failure
http-nio-9443-exec-13, called closeSocket()
http-nio-9443-exec-13, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert
: handshake_failure
http-nio-9443-exec-13, WRITE: TLSv1 Application Data, length = 1
http-nio-9443-exec-13, WRITE: TLSv1 Application Data, length = 154
http-nio-9443-ClientPoller-0, called closeOutbound()
http-nio-9443-ClientPoller-0, closeOutboundInternal()
http-nio-9443-ClientPoller-0, SEND TLSv1 ALERT: warning, description = close_notify
http-nio-9443-ClientPoller-0, WRITE: TLSv1 Alert, length = 32
Finalizer, called close()
Finalizer, called closeInternal(true)
I have tried passing https.protocols=SSLv3,SSLv2Hello or https.protocols=SSLv3 in the axis2 config file as a to the https sender transport but this doesn't help either.
Suggestions welcome.
thanks
Conrad

Related

Letsencrypt: alert certificate expired / alert SSL alert number 45 [closed]

Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 days ago.
Improve this question
I've got some trouble with one of my clients (docker container based on Alpine) connecting a mail server with a Letsencrypt SSL certificate:
Nov 2 14:39:50 mail postfix/smtpd[878799]: warning: TLS library problem: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired:../ssl/record/rec_layer_s3.c:1543:SSL alert number 45:
I know that Letsencrypt uses the new ISRG Root X1 since 1st Oct 2021. After Downloading the CA pem file from here https://letsencrypt.org/de/certificates/ I checked that the certificate is available.
Seems to be okay for me:
/etc/ssl/certs # grep -ri "emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=" .
./4042bcee.1:emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
./ca-certificates.crt:emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
./ca-certificates.crt:emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
./ca-cert-isrgrootx1.pem.pem:emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
./4042bcee.0:emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
./ca-cert-ISRG_Root_X1.pem:emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
Additionally I installed the Certificate by hand (snippet of the Dockerfile):
COPY etc/ssl/isrgrootx1.pem /usr/local/share/ca-certificates/
RUN apk update && apk add --no-cache ca-certificates && update-ca-certificates
No luck. The SSL chain seems to be strange (domain is masked with xxx):
/etc/ssl/certs # openssl s_client -starttls smtp -connect mail.xxx.de:587
CONNECTED(00000003)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
0 s:/CN=mail.xxx.de
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/CN=mail.xxx.de
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 4895 bytes and written 328 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: D0DA2252D5091779AA2CDF832A856F846A2AFD4C4C73CEDA24D64647FD998CB4
Session-ID-ctx:
Master-Key: BA703221FC54ADE822079229A36672AADFF4621EBEFDDA338D3E5F8025DC9668BBAFA152A1708C569B72AFF09F80AC5D
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 18 80 2d 38 6c e0 da 60-77 43 b1 62 d7 80 84 3f ..-8l..`wC.b...?
0010 - 1e 28 23 23 f7 34 ef 30-21 09 a2 34 92 b7 bf 10 .(##.4.0!..4....
0020 - ae c1 b7 50 ea 85 11 32-1c 28 f9 09 9f ff 20 7a ...P...2.(.... z
0030 - 7b e2 61 8d 8d 06 e3 66-6e 7c 93 31 95 29 e9 2d {.a....fn|.1.).-
0040 - 6a 93 bc 06 1d e2 26 58-00 32 48 67 aa f5 45 ed j.....&X.2Hg..E.
0050 - b8 5a 0d 93 84 7e c4 36-cf 06 39 4f d3 6a 45 e1 .Z...~.6..9O.jE.
0060 - a6 fc 49 31 3a 1c c4 32-d3 ae d2 2c 2e 34 e9 c2 ..I1:..2...,.4..
0070 - 8c 58 ee 98 08 48 56 d9-58 c3 3a 2c 21 6e a8 3b .X...HV.X.:,!n.;
0080 - 85 22 9b 90 6c 21 06 79-f2 e6 6c b0 dd c9 1e 2c ."..l!.y..l....,
0090 - c1 62 11 4b 7b 19 5d ac-d9 ba 69 6a 17 fb 7b ab .b.K{.]...ij..{.
Start Time: 1636139076
Timeout : 7200 (sec)
Verify return code: 10 (certificate has expired)
---
250 CHUNKING
Here one of my Alpine Containers with a successfully connection:
/var/www/html # openssl s_client -starttls smtp -connect mail.xxx.de:587
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = mail.xxx.de
verify return:1
---
Certificate chain
0 s:CN = mail.xxx.de
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=CN = mail.xxx.de
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4834 bytes and written 435 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 CHUNKING
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: A60E19C667530A8C575213D7ECCA704F55D32294779DDA198D182909ACF72EC9
Session-ID-ctx:
Resumption PSK: F341E73946627D59D9AEAEDDDF23D0F9B5BBFF8CE5603550A30E0A17BC884174A8883D2BBF1D4335D6835470A9DBED6D
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 4e 14 1b 3c 6f 76 8f da-4c 91 b0 71 f0 95 f8 f6 N..<ov..L..q....
0010 - a2 bd 18 a8 75 00 a3 0c-dc 18 7a 95 2c 74 a4 62 ....u.....z.,t.b
0020 - 4e aa 8e d4 dc 75 6a 1e-1b 3b c1 87 9d ca ff ce N....uj..;......
0030 - 24 a4 7b fb 35 e8 c1 8e-ff a0 a4 38 db 52 7d fd $.{.5......8.R}.
0040 - 95 42 0d 8f 0b ba c4 5b-27 d5 94 2b bc f3 92 34 .B.....['..+...4
0050 - 41 e4 12 6e f7 c4 f0 33-81 bc 9d 07 12 8f b2 8b A..n...3........
0060 - f1 8d 59 2f ee 49 e6 c8-17 e6 66 64 b6 b8 8f a0 ..Y/.I....fd....
0070 - d0 40 bc 28 71 96 d1 a7-b9 e3 00 db ba 5b 85 43 .#.(q........[.C
0080 - e2 dc d0 42 21 8a d1 57-21 01 5e b9 5f e2 ec 16 ...B!..W!.^._...
0090 - fb 00 d6 5b ae b6 2b d1-42 c8 2c ae f6 2d 21 48 ...[..+.B.,..-!H
00a0 - dc d2 a9 c3 5c 75 33 21-a8 c2 ca d3 7b 86 ec 65 ....\u3!....{..e
00b0 - d2 1b 1f e5 c7 b2 45 94-96 56 48 74 e5 d5 22 18 ......E..VHt..".
00c0 - bf c4 5d f4 9e 1c 37 e2-b7 9a cc 3a e1 0e 9b ee ..]...7....:....
Start Time: 1636139616
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
Any idea? Thank you very much!

NGINX Reverse Proxy: 20:unable to get local issuer certificate

I am running nginx and i want to proxy another https host and to verify it's certificate.
I've created a CA cert, created a cert for the proxied host and signed it with the CA. The CA cert was added to the server's root certificates.
My nginx config is the following:
proxy_ssl_verify_depth 1; # tried 0,1,2,3
proxy_ssl_trusted_certificate /etc/nginx/ca.pem;
proxy_ssl_verify on;
When a request is done, nginx log returns:
[error] 26578#26578: *2 upstream SSL certificate verify error: (20:unable to get local issuer certificate) while SSL handshaking to upstream
Running openssl s_client -connect 1.1.1.1:8000 returns:
CONNECTED(00000003)
depth=1 C = CY, ST = CY, L = CY, O = TEST.TEST, CN = TEST.TEST, emailAddress = admin#test.test
verify return:1
depth=0 C = CY, ST = CY, L = CY, O = TEST.TEST, OU = TEST.TEST, CN = 1.1.1.1
verify return:1
---
Certificate chain
0 s:/C=CY/ST=CY/L=CY/O=TEST.TEST/OU=test.test/CN=1.1.1.1
i:/C=CY/ST=CY/L=CY/O=TEST.TEST/CN=test.test/emailAddress=admin#test.test
---
Server certificate
-----BEGIN CERTIFICATE-----
.... cer
-----END CERTIFICATE-----
subject=/C=CY/ST=CY/L=CY/O=TEST.TEST/OU=test.test/CN=1.1.1.1
issuer=/C=CY/ST=CY/L=CY/O=TEST.TEST/CN=test.test/emailAddress=admin#test.test
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1491 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 94195986FED8C203B09C6A3870DC8B972A6FB3C98D69868CFAF9C4BFC2B7A714
Session-ID-ctx:
Master-Key: D804526744415E7E6C3E0AFBAF4F5BB3B6315BE8785C46FCF7AA232A31E6D7C780E7A8D4B8413BE8D1F1758CF8DD8FE8
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 0a 5f b9 15 a5 78 d0 6c-32 24 77 3b 16 7a 10 75 ._...x.l2$w;.z.u
0010 - 76 ed 08 18 8b 23 a8 15-24 3f eb 83 d8 6e 56 d6 v....#..$?...nV.
0020 - 98 13 c2 36 62 35 17 42-b4 f9 e9 f7 99 50 14 77 ...6b5.B.....P.w
0030 - 8b a3 e6 b5 2f ef ca af-7d 25 7c d8 7e b8 3a 96 ..../...}%|.~.:.
0040 - 11 87 b2 e2 0a d6 de b6-60 75 c5 4a 58 57 8b 1b ........`u.JXW..
0050 - 73 6d 36 c6 9f 6a ec 31-71 2d 02 ad 50 45 8a 14 sm6..j.1q-..PE..
0060 - 01 c1 6c 4a 2f 46 9b cb-e6 4c 09 97 17 fa 46 f4 ..lJ/F...L....F.
0070 - 29 e6 a5 cb a7 37 fb 31-b3 a0 d7 55 ac cb fd 59 )....7.1...U...Y
0080 - 42 a5 7b 45 9a 53 24 90-52 8c 8e 1c eb c4 db f9 B.{E.S$.R.......
0090 - 27 04 b9 7e ba 0a 2d 9e-3b 92 67 ec 42 d6 69 78 '..~..-.;.g.B.ix
Start Time: 1527255600
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
IP/cert names replaced by dummy versions in this result.
curl https://1.1.1.1 also works without problems.
I've been reading googling and checking all similar stackoverflow questions, but none of the proposed fixes seemed to resolve this.

What could cause forbidden 403 after successful SSL handshake?

I have a question about an TLS connection I am making inside my Java application to an external party.
The TLS handshake seems to finish without any issues. (See log below).
But I still get a 403 forbidden from the web server I am trying to hit.
Because the SSL handshake has finished does it means I can rule out certificates as being the problem? i.e. Is it more likely to be like a firewall blocking me on the other side?
Also can anyone think of anything else I can do on my side to get more information about why things might be going wrong? I ask this question because at the moment I feel like I have exhausted all avenues of investigation.
thanks
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), READ: TLSv1 Handshake, length = 2704
*** ServerHello, TLSv1
RandomCookie: GMT: 1489311495 bytes = { 24, 166, 5, 115, 96, 245, 87, 168, 201, 0, 140, 169, 246, 167, 17, 130, 35, 82, 180, 20, 78, 118, 197, 139, 115, 85, 149, 249 }
Session ID: {240, 31, 0, 0, 187, 150, 112, 197, 105, 66, 166, 30, 38, 101, 157, 77, 70, 251, 210, 109, 66, 5, 150, 39, 144, 252, 165, 154, 98, 139, 28, 247}
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: 24:d2:f9:be:4f:9b:34:9d:97:0a:87:7e:b3:00:a5:3b:9e:fd:13:83:1b:7c:57:f5
***
%% Initialized: [Session-5, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=myComppany.dns.com.au
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 20347157146520353095861639278208184247286986690713431491420841394784858170529375449223849853534354840929149706378303297947541892423057001636130580267149963843615721783983566141638311949114700827164868954418508313798333746643037746007234047993830271943749361746071066892915327273997666547176023092823087128341412638685856170738104070682226405621117015097115212087323270530842662099589771387988512876505892653094995664532977115190036204521785829075338794419227119436542735750611752914553559131212700916410969902308936242124816342527509957358809361641507658744635443218654637212447896897323865396709669621261450063512703
public exponent: 65537
Validity: [From: Tue May 16 10:07:21 AEST 2017,
To: Thu May 16 10:07:20 AEST 2019]
Issuer: CN=EDS_RootCA
SerialNumber: [ 3f6b1b9d 4e6a8491 479d4580 318d46b6]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.1 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 4F 30 4D 80 10 1F 88 3D 3B E3 7C 8A 45 C0 4C .O0M....=;...E.L
0010: 36 EF 64 C8 23 A5 A1 27 30 25 31 23 30 21 06 03 6.d.#..'0%1#0!..
0020: 55 04 03 1E 1A 00 45 00 44 00 53 00 5F 00 56 00 U.....E.D.S._.
0030: 52 00 5F 00 52 00 6F 00 6F 00 74 00 43 00 41 82 ._.R.o.o.t.C.A.
0040: 10 1F E5 AA 89 7F E6 11 82 4D FE D1 DB FA F4 7E .........M......
0050: 8D .
]
Algorithm: [SHA256withRSA]
Signature:
0000: 26 94 B7 78 21 EC 60 24 28 6E 7D C0 93 43 7A F8 &..x!.`$(n...Cz.
0010: 27 E8 BF 36 E1 B9 6E 41 4F 3B B7 7D 48 FB F4 77 '..6..nAO;..H..w
0020: 56 30 85 5E C1 5E 73 1A 79 7A B8 7F 48 DE 85 2F V0.^.^s.yz..H../
0030: 03 93 8F 78 15 28 65 4D 78 E1 DE 83 83 10 B0 97 ...x.(eMx.......
0040: 0C F2 8E D3 E7 E3 16 8E 1C C8 0D 6D 04 B9 64 81 ...........m..d.
0050: 59 B1 34 D7 2E 86 1C E0 CD D7 19 8E 7C 00 CA CD Y.4.............
0060: A5 3D 37 F0 31 24 E6 DC 01 66 9C D2 6A 25 FE 0A .=7.1$...f..j%..
0070: F9 02 B7 41 17 38 BA 74 05 34 EC 5D 3D DB 20 CB ...A.8.t.4.]=. .
]
***
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
<CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE>
<CN=DigiCert Assured ID Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US>
<CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US>
<OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US>
<CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE>
<CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE>
<CN=GeoTrust Global CA, O=GeoTrust Inc., C=US>
<CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US>
<CN=SercoTcsRootCA>
<CN=Microsoft Root Certificate Authority 2011, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US>
<CN=Microsoft Root Authority, OU=Microsoft Corporation, OU=Copyright (c) 1997 Microsoft Corp.>
<CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US>
<CN=Tenix IMES CA>
<CN=Microsoft Root Certificate Authority, DC=microsoft, DC=com>
<CN=SercoTcsRootCA, DC=, DC=ap, DC=ser, DC=com>
<CN=EDS__RootCA>
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain
<Empty>
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), WRITE: TLSv1 Handshake, length = 304
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 B3 1D 9D 31 6C 7D 0D D7 92 73 03 F0 6D 84 .....1l....s..m.
0010: 4D 6C BB 52 D7 26 C1 B0 58 82 90 23 29 DB AC 1C Ml.R.&..X..#)...
0020: DA 19 E1 6C A0 63 31 22 0D 39 05 FD 92 A6 43 A6 ...l.c1".9....C.
CONNECTION KEYGEN:
Client Nonce:
0000: 59 C5 17 07 63 E9 79 F6 63 5A 7A 43 66 8D 1C B2 Y...c.y.cZzCf...
0010: 60 6C 4A CF E4 86 9A 81 A2 2B C6 F0 5E 76 6A 93 `lJ......+..^vj.
Server Nonce:
0000: 59 C5 17 07 18 A6 05 73 60 F5 57 A8 C9 00 8C A9 Y......s`.W.....
0010: F6 A7 11 82 23 52 B4 14 4E 76 C5 8B 73 55 95 F9 ....#R..Nv..sU..
Master Secret:
0000: 74 FC 19 66 31 63 EB 6D 77 D0 90 35 89 AF 5E 2D t..f1c.mw..5..^-
0010: 92 07 CD 77 18 D4 8A B0 A4 ED D6 87 79 EC BA DC ...w........y...
0020: B5 85 EF BF 6E 44 60 08 93 10 18 89 42 37 58 45 ....nD`.....B7XE
Client MAC write Secret:
0000: C1 EA 83 8C DB D9 FC 4D BA B3 F0 CA 63 98 5F 3E .......M....c._>
0010: 5B E0 87 F0 [...
Server MAC write Secret:
0000: 8C 01 99 66 54 26 87 2A 16 96 6F 6B 96 8A F3 6B ...fT&.*..ok...k
0010: 84 8C 9E D9 ....
Client write key:
0000: 96 E6 14 E2 F6 85 B8 93 51 90 2C CA 86 05 0F FE ........Q.,.....
Server write key:
0000: 96 4C 43 E0 3A FB 05 72 3B 91 6B DB D8 1D 41 67 .LC.:..r;.k...Ag
Client write IV:
0000: BB AA 2B 91 63 10 62 EA B6 8E 2D 48 DD 8A 6C EE ..+.c.b...-H..l.
Server write IV:
0000: 25 30 3F 0A 96 D4 D9 1B F2 B1 92 29 62 CD 0D 4D %0?........)b..M
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), WRITE: TLSv1 Change Cipher Spec, length = 32
*** Finished
verify_data: { 232, 153, 163, 243, 22, 33, 213, 172, 119, 46, 247, 107 }
***
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), WRITE: TLSv1 Handshake, length = 48
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), READ: TLSv1 Change Cipher Spec, length = 32
[api-blah-v1-132].http.requester.apiHttpblahRequestConfig.worker(5), READ: TLSv1 Handshake, length = 48
*** Finished
verify_data: { 232, 126, 65, 13, 112, 166, 63, 121, 201, 0, 57, 110 }
***
%% Cached client session: [Session-5, TLS_RSA_WITH_AES_128_CBC_SHA]
WARN 2017-09-22 23:58:32,052 [[api-blah-v1-132].apiHttpListenerConfig.worker.02] org.apache.cxf.phase.PhaseInterceptorChain: Interceptor for {http://support.cxf.module.mule.org/}ProxyService#{http://support.cxf.module.mule.org/}invoke has thrown exception, unwinding now\norg.apache.cxf.interceptor.Fault: Response code 403 mapped as failure.\n
Because the SSL handshake has finished does it means I can rule out certificates as being the problem?
Yes.
i.e. Is it more likely to be like a firewall blocking me on the other side?
No.
It is the Web server denying you permission to access the requested resource. There is no reason why a successful TLS handshake alone should permit you that access. It is up to the Web server who can access what.
So I looked at this more. I discovered that you have to be very careful with reading the output posted.
Although the handshake reports as successful there is a message in the handshake as follows. This basically means that the handshake failed although the first packet may have been sent.
Warning: no suitable certificate found - continuing without client authentication
There was a problem with my keystore and that was that it did not have the certificate of the issuer in it.

routines:SSL23_GET_CLIENT_HELLO:unknown protocol (Redis Cluster + Stunnel)

I have a Redis cluster that I wish to setup stunnel on for the purpose of encrypting traffic to and from each master/slave, and to and from the HAproxy layer above redis. I have configured stunnel with the following configuration file:
pid=/var/stunnel-redis.pid
foreground = yes
debug = info
output = stunnel.log
sslVersion = all
#options = NO_SSLv2
fips = no
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
[redis-server]
cert = /etc/stunnel/cert.pem
key = /etc/stunnel/key.pem
TIMEOUTclose = 0
accept = 0.0.0.0:7001
connect = 127.0.0.1:7002
[redis-client]
client = yes
accept = 127.0.0.1:7002
connect = 127.0.0.1:6379
CAfile = /etc/stunnel/redis.pem
verify = 0
EDIT I should explain how each service is setup, network-wise.
redis-server binds 127.0.0.1:6379
stunnel redis-server binds 0.0.0.0:7001
stunnel redis-client binds 127.0.0.1:7002
A redis client connection will connect to stunnel's redis-server on 0.0.0.0:7001. Stunnel will then connect to the redis-client on 127.0.0.1:7002, and stunnel's redis-client will connect to the redis server on 127.0.0.1:6379.
When attempting to run redis-cli -h my_remote_stunnel_ip -p 7001 I receive the following error in the logs:
2017.01.31 09:45:11 LOG3[16062]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
2017.01.31 09:45:11 LOG5[16062]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
I have tried disabling the redis-client section in the config, I have tried changing sslVersion to sslVersion = TLSv1, sslVersion = TLSv1.2. When I change sslVersion to sslVersion = TLSv1 I receive the following error upon attempting connection:
2017.01.31 09:38:33 LOG3[15830]: SSL_accept: 1408F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Is this due to a version mismatch? And if so, how? Both daemons are running on the same host.
EDIT:
Output of openssl s_client -connect :7001 -tls1:
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2452 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 0A05C63AA7596D37B4D18B5CF377213A0B245B681E3E1CD28506E877311A862A
Session-ID-ctx:
Master-Key: 54EE658224A3BB08E25416F05CBCAB5D58EA075E7C157AEE31B94D2AA289CE694558CDF27B3EA0B8FB90738C3EEE4EE8
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 12 55 cd c7 bc ab e8 6c-c7 e7 ca 9c 05 bf 5b dd .U.....l......[.
0010 - bb 17 b9 d5 68 e0 be 54-a1 b6 06 00 0a fe db 17 ....h..T........
0020 - 4a 89 93 6b 95 18 1e be-45 f9 cb a8 6c 07 5b 45 J..k....E...l.[E
0030 - ef 47 60 b7 0d 7e 51 95-ca 68 48 5f 03 5b d9 0e .G`..~Q..hH_.[..
0040 - 62 0b f5 33 bb b6 ce 03-6d d7 d3 69 12 de 3a 63 b..3....m..i..:c
0050 - db 8d 98 ba ac e6 e1 f8-9a f1 b1 50 5e 63 1a 24 ...........P^c.$
0060 - 9c ad 1d a8 ef 85 9d 64-9a 00 d7 76 b3 77 73 05 .......d...v.ws.
0070 - dc 04 94 ae c3 c7 89 3e-26 c1 25 d7 a7 f2 45 97 .......>&.%...E.
0080 - f8 2d e9 21 cc 7c 44 e2-a8 3d 93 00 e5 09 d0 38 .-.!.|D..=.....8
0090 - 53 4f 22 fd 75 52 37 f8-3d c5 0e 22 5a 55 b4 8b SO".uR7.=.."ZU..
Start Time: 1485881728
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---
read:errno=104

How to solve RECV SSLv3 ALERT: fatal, bad_record_mac

Over the last few days I have tried to install a working CAS server (Jasig CAS) on Ubuntu 10.10. I installed Tomcat 6 and configured (server.xml) it for SSL port 8443:
<!-- Define a SSL HTTP/1.1 Connector on port 8443 -->
<Connector port="8443"
maxHttpHeaderSize="8192"
maxThreads="150"
minSpareThreads="25"
disableUploadTimeout="true"
acceptCount="100"
scheme="https"
secure="true"
clientAuth="false"
SSLEnabled="true"
SSLProtocol="SSLv3"
SSLCertificateFile="/etc/ssl/certs/server_cert.pem"
SSLCertificateKeyFile="/etc/ssl/private/server_key.pem"
SSLCACertificateFile="/etc/ssl/certs/ca_cert.pem"
SSLCACertificatePath="/etc/ssl/certs"
SSLPassword="password"
/>
server_cert.pem, server_key.pem are self-signed x509 certificates. Further, I created a x509v3 certificate for a windows test server (apache2 - xampp) (both servers are in the same LAN and have the IPs 10.0.0.*) . these certificate is installed in the java keystore (cacerts) which is located in the java directory. Since I had always problems with the "alternative subject name" in the client certificate I used an extended version of the openssl config file to create it.
The apache2 ssl config file looks as follows:
<IfModule ssl_module>
....
<VirtualHost 10.0.0.2:443>
SSLEngine on
ServerName 10.0.0.2:443
#ServerAlias 10.0.0.2
DocumentRoot c:/xampp/htdocs
SSLProtocol -all +SSLv3
SSLCertificateFile C:/xampp/ssl/certs/powercomputer_cert.pem
SSLCertificateKeyFile C:/xampp/ssl/private/powercomputer_key.pem
SSLCACertificateFile C:/xampp/ssl/certs/ca_cert.pem
</VirtualHost>
...
</IfModule>
SSL connections are working on both servers (tested by using IE and firefox).
Now comes the hard task. I used a module called phpCAS, programmed in php, on the windows machine to communicate with the CAS server. The module sends a callback url to the CAS server and the server sends a proxy ticket back etc. etc.
BUT I was not able to ensure a valid SSL handshake between both servers. openssl -s_client -connect... for both servers it did not show any errors so I debugged the complete SSL handshake (here is only the relevant part):
...
* ServerHelloDone
* ClientKeyExchange, RSA PreMasterSecret, SSLv3 http-apr-8443-exec-3, WRITE: SSLv3 Handshake, length = 132 SESSION
KEYGEN: PreMaster Secret: 0000: 03 00 78 96 8F EE D3 4A 2F A8 CC F8
F9 D7 2F CB ..x....J/...../. 0010: 9E 3A 58 66 43 0E D5 49 3C 8A B0
3D 3F 2C 89 A0 .:XfC..I<..=?,.. 0020: BC E2 B2 12 F8 D9 55 73 F2 2C
1F CC 81 80 94 22 ......Us.,....." CONNECTION KEYGEN: Client Nonce:
0000: 4E D1 94 ED 32 7F FA 72 40 3C 43 C8 05 E2 62 D0
N...2..r#
91 E2 D0 1C 90 3D 30 DD ..n;W6.......=0. Master Secret: 0000: EB 25
F0 A2 A3 FF 37 06 BB 79 41 C5 E5 07 1C 64 .%....7..yA....d 0010: 77
66 A3 37 71 97 63 AF DB A2 79 47 85 E2 9C 74 wf.7q.c...yG...t 0020:
5F 14 3D 26 57 E8 AD 9B A1 7C AC 33 00 04 4A E0 _.=&W......3..J.
Client MAC write Secret: 0000: C9 20 BF A5 A6 2B C1 DA A8 4E 93 E0
DE 76 06 53 . ...+...N...v.S Server MAC write Secret: 0000: 66 77 5A
3E BD E7 19 55 A4 80 1E E6 8A 9E 2A 5E fwZ>...U......*^ Client
write key: 0000: 58 D1 29 38 13 D8 83 EF 4F BD 7A 18 C8 35 D7 B4
X.)8....O.z..5.. Server write key: 0000: 3A 7B 6A 6E 66 E9 E1 42 A4
3C C3 19 D0 7F 21 FF :.jnf..B.<....!. ... no IV used for this cipher
http-apr-8443-exec-3, WRITE: SSLv3 Change Cipher Spec, length = 1
* Finished verify_data: { 71, 19, 125, 80, 118, 60, 64, 122, 243, 112, 45, 18, 254, 144, 12, 143, 221, 125, 10, 94, 15, 221, 122, 21,
90, 190, 76, 224, 224, 57, 67, 172, 228, 75, 181, 228 }
* http-apr-8443-exec-3, WRITE: SSLv3 Handshake, length = 56 http-apr-8443-exec-3,
READ: SSLv3 Alert, length = 2
http-apr-8443-exec-3, RECV SSLv3 ALERT: fatal, bad_record_mac
http-apr-8443-exec-3, called closeSocket() http-apr-8443-exec-3,
handling exception: javax.net.ssl.SSLException: Received fatal alert:
bad_record_mac 2011-11-27 02:39:57,315 ERROR
[org.jasig.cas.util.HttpClient] -
bad_record_mac> javax.net.ssl.SSLException: Received fatal alert:
bad_record_mac at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at
sun.security.ssl.Alerts.getSSLException(Alerts.java:154) at
....
I did not find any solution in the last few days and I really do not have a clue what is the problem. btw I forced the use of SSLv3.
Thank you very much for any suggestions.