Update: I just run the command inside the docker of the same Linux machine, and it worked. Therefore might be an issue related to Linux distro. I personally suspect something related to SSL certifications.
I set up a Kubernetes cluster in AWS EKS and a whole running environment by using MacBook. However, I found out myself cannot setup kubectl correctly in my Linux machine (ArchLinux).
I've tried to run the kubectl --v=1000 get svc (some cluster info was masked)
I1020 11:01:44.053581 3266 loader.go:359] Config loaded from file /home/realturner/.kube/config
I1020 11:01:44.054963 3266 round_trippers.go:419] curl -k -v -XGET -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.14.7 (linux/amd64) kubernetes/1861c59" 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s'
I1020 11:01:44.299305 3266 round_trippers.go:438] GET https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s in 244 milliseconds
I1020 11:01:44.299331 3266 round_trippers.go:444] Response Headers:
I1020 11:01:44.299367 3266 cached_discovery.go:121] skipped caching discovery info due to Get https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s: dial tcp: lookup XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com on [::1]:53: read udp [::1]:34122->[::1]:53: read: connection refused
When compared to another machine, the successful one replies headers and body
I1020 11:03:44.358266 1675 loader.go:359] Config loaded from file /Users/realturner/.kube/config-tv
I1020 11:03:44.359417 1675 round_trippers.go:419] curl -k -v -XGET -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.14.6 (darwin/amd64) kubernetes/96fac5c" 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s'
I1020 11:03:46.186432 1675 round_trippers.go:438] GET https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s 200 OK in 1826 milliseconds
I1020 11:03:46.186481 1675 round_trippers.go:444] Response Headers:
I1020 11:03:46.186498 1675 round_trippers.go:447] Content-Length: 149
I1020 11:03:46.186512 1675 round_trippers.go:447] Date: Sun, 20 Oct 2019 03:03:46 GMT
I1020 11:03:46.186525 1675 round_trippers.go:447] Audit-Id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
I1020 11:03:46.186538 1675 round_trippers.go:447] Content-Type: application/json
I1020 11:03:46.262841 1675 request.go:942] Response Body: {"kind":"APIVersions","versions":["v1"],"serverAddressByClientCIDRs":[{"clientCIDR":"0.0.0.0/0","serverAddress":"ip-10-xxx-xxx-xxx.ec2.internal:443"}]}
I'd suspect a network or firewall problem, but simply doing curl to that endpoint do have some response, though lack of permission:
$ curl -k -v -XGET -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.14.7 (linux/amd64) kubernetes/1861c59" 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com/api?timeout=32s'
Note: Unnecessary use of -X or --request, GET is already inferred.
* Trying x.xxx.xxx.xx:443...
* TCP_NODELAY set
* Connected to XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com (x.xxx.xxx.xx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=kube-apiserver
* start date: Oct 17 10:29:43 2019 GMT
* expire date: Oct 16 10:29:44 2020 GMT
* issuer: CN=kubernetes
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55cb670e87b0)
> GET /api?timeout=32s HTTP/2
> Host: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com
> Accept: application/json, */*
> User-Agent: kubectl/v1.14.7 (linux/amd64) kubernetes/1861c59
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 403
< audit-id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 188
< date: Sun, 20 Oct 2019 14:56:42 GMT
<
{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"forbidden: User \"system:anonymous\" cannot get path \"/api\"","reason":"Forbidden","details":{},"code":403}
* Connection #0 to host XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.eks.amazonaws.com left intact
Edit - here's my .kube/config, same as .kube/tv-config (some items masked). It's generated by aws eks update-kubeconfig --name <Cluster>
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <Same as the one in `Certificate authority
` of EKS>
server: https://<PREFIX>.<REGION>.eks.amazonaws.com
name: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
contexts:
- context:
cluster: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
user: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
name: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
current-context: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
kind: Config
preferences: {}
users:
- name: arn:aws:eks:<REGION>:<AccountId>:cluster/<Cluster>
user:
exec:
apiVersion: client.authentication.k8s.io/v1alpha1
args:
- --region
- <REGION>
- eks
- get-token
- --cluster-name
- <Cluster>
command: aws
Wow, it turns out to be the DNS resolution problem, despite that I used the newly install the system for several days without noticing it.
Previously I just tried getent hosts <DNS> for DNS resolution and use curl -v <PREFIX>.<REGION>.eks.amazonaws.com> for DNS resolution test. They both had replied correctly before I found my /etc/resolv.conf is actually empty.
I have missed configuring systemd's DNS resolution. As documented here:
Note that if you want to take advantage of automatic DNS configuration from DHCP, you need to enable systemd-resolved and symlink /run/systemd/resolve/resolv.conf to /etc/resolv.conf
After symbolic linking now it just works as expected!
I'm trying to connect to SSL server from linux but it does not work.
I need to auth by a client certificate from a Windows client http (C# httpwebrequest) but it does not work.
So I have tried using an internal reverse proxy with Linux/Apache (it does the client authentifcation) but it does not work. Here is the configuration :
<VirtualHost host:443>
ServerName host:443
# SRV SSL
SSLEngine On
SSLCertificateFile /cert.cer
SSLCertificateKeyFile /cert.key
# REVERSE PROXY
SSLProxyEngine On
ProxyPass / https://host:443/
ProxyPassReverse / https://host:443/
ProxyRequests Off
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
# AUTHENTIFICATION CERT CLIENT (concat crt et key SANS pwd)
SSLProxyMachineCertificateFile "/cert.crt.key"
# Log Dev
TransferLog logs/test.ssl_access_log
ErrorLog logs/test.ssl_error_log
# DEBUG
<IfModule mod_ssl.c>
ErrorLog logs/ssl_engine.log
LogLevel debug
</IfModule>
</VirtualHost>
And here is the ssl_engine.log :
[Sat Mar 03 18:23:06.813995 2018] [proxy:debug] [pid 5892] proxy_util.c(2798): AH02824: HTTPS: connection established with xxx.xxx.xxx.xxx:443 (host)
[Sat Mar 03 18:23:06.814011 2018] [proxy:debug] [pid 5892] proxy_util.c(2938): AH00962: HTTPS: connection complete to xxx.xxx.xxx.xxx:443 (host)
[Sat Mar 03 18:23:06.814015 2018] [ssl:info] [pid 5892] [remote xxx.xxx.xxx.xxx:443] AH01964: Connection to child 0 established (server localhost:443)
[Sat Mar 03 18:23:06.844164 2018] [ssl:info] [pid 5892] [remote xxx.xxx.xxx.xxx:443] AH02003: SSL Proxy connect failed
[Sat Mar 03 18:23:06.844212 2018] [ssl:info] [pid 5892] SSL Library Error: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
[Sat Mar 03 18:23:06.844219 2018] [ssl:info] [pid 5892] [remote xxx.xxx.xxx.xxx:443] AH01998: Connection closed to child 0 with abortive shutdown (server localhost:443)
[Sat Mar 03 18:23:06.844234 2018] [ssl:info] [pid 5892] [remote xxx.xxx.xxx.xxx:443] AH01997: SSL handshake failed: sending 502
[Sat Mar 03 18:23:06.844250 2018] [proxy_http:error] [pid 5892] (103)Software caused connection abort: [client 172.20.6.150:56860] AH01102: error reading status line from remote server host:443
[Sat Mar 03 18:23:06.844275 2018] [proxy_http:debug] [pid 5892] mod_proxy_http.c(1363): [client 172.20.6.150:56860] AH01105: NOT Closing connection to client although reading from backend server host:443 failed.
[Sat Mar 03 18:23:06.844280 2018] [proxy:error] [pid 5892] [client 172.20.6.150:56860] AH00898: Error reading from remote server returned by /recette/tib/depotGreffe/C0002A0121L091616D20180129H100031TDEDOCPCFEC.zip
[Sat Mar 03 18:23:06.844292 2018] [proxy:debug] [pid 5892] proxy_util.c(2218): AH00943: HTTPS: has released connection for (host)
[Sat Mar 03 18:23:06.844483 2018] [ssl:info] [pid 5892] [client 172.20.6.150:56860] AH01992: SSL library error 1 reading data
[Sat Mar 03 18:23:06.844497 2018] [ssl:info] [pid 5892] SSL Library Error: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
[Sat Mar 03 18:23:07.054533 2018] [proxy:debug] [pid 5893] proxy_util.c(1843): AH00925: initializing worker https://host/ shared
[Sat Mar 03 18:23:07.054583 2018] [proxy:debug] [pid 5893] proxy_util.c(1885): AH00927: initializing worker https://host/ local
[Sat Mar 03 18:23:07.054597 2018] [proxy:debug] [pid 5893] proxy_util.c(1936): AH00931: initialized single connection worker in child 5893 for (host)
[Sat Mar 03 18:23:11.849565 2018] [ssl:info] [pid 5892] (70007)The timeout specified has expired: [client 172.20.6.150:56860] AH01991: SSL input filter read failed.
[Sat Mar 03 18:23:11.849662 2018] [ssl:debug] [pid 5892] ssl_engine_io.c(993): [client 172.20.6.150:56860] AH02001: Connection closed to child 4 with standard shutdown (server localhost:443)
[Sat Mar 03 18:23:52.003050 2018] [ssl:info] [pid 5888] [client 172.20.7.77:53311] AH01964: Connection to child 0 established (server localhost:443)
[Sat Mar 03 18:23:52.019141 2018] [ssl:debug] [pid 5888] ssl_engine_kernel.c(1823): [client 172.20.7.77:53311] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Sat Mar 03 18:23:52.019411 2018] [ssl:debug] [pid 5888] ssl_engine_io.c(993): [client 172.20.7.77:53311] AH02001: Connection closed to child 0 with standard shutdown (server localhost:443)
[Sat Mar 03 18:24:52.001523 2018] [ssl:info] [pid 5889] [client 172.20.7.77:53884] AH01964: Connection to child 1 established (server localhost:443)
[Sat Mar 03 18:24:52.016324 2018] [ssl:debug] [pid 5889] ssl_engine_kernel.c(1823): [client 172.20.7.77:53884] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Sat Mar 03 18:24:52.018222 2018] [ssl:debug] [pid 5889] ssl_engine_io.c(993): [client 172.20.7.77:53884] AH02001: Connection closed to child 1 with standard shutdown (server localhost:443)
[Sat Mar 03 18:25:52.000848 2018] [ssl:info] [pid 5890] [client 172.20.7.77:54435] AH01964: Connection to child 2 established (server localhost:443)
[Sat Mar 03 18:25:52.018430 2018] [ssl:debug] [pid 5890] ssl_engine_kernel.c(1823): [client 172.20.7.77:54435] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Sat Mar 03 18:25:52.018656 2018] [ssl:debug] [pid 5890] ssl_engine_io.c(993): [client 172.20.7.77:54435] AH02001: Connection closed to child 2 with standard shutdown (server localhost:443)
I have tried many tests with curl but nothing (with client auth options) :
curl -v -k --cert /cert.crt.key https://host/path
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP)
* Cannot communicate securely with peer: no common encryption algorithm(s).
* Closing connection 0
curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s).
I have dump trafic using tcpdump and analyse it with ssldump and I have a handshake failure (only client hello but non server hello) :
ssldump -nr /trace.cap
New TCP connection #1: 172.20.7.85(44122) <-> xxx.xxx.111.106(443)
1 1 0.1201 (0.1201) C>S Handshake
ClientHello
Version 3.3
cipher suites
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Unknown value 0xcca9
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Unknown value 0xcca8
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Unknown value 0xccaa
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
compression methods
NULL
1 2 0.1507 (0.0305) S>C Alert
level fatal
value handshake_failure
1 0.1508 (0.0000) C>S TCP FIN
1 0.1803 (0.0294) S>C TCP FIN
It seems I have never the "server hello" from the server and so never have server cipher.
I'm trying with openssl client like this :
openssl s_client -connect host:443 -cert /mycert.pem -key /mycert.key -debug -state
SSL_connect:SSLv2/v3 write client hello A
read from 0xc48060 [0xc7dc00] (7 bytes => 7 (0x7))
0000 - 15 03 01 00 02 02 28 ......(
SSL3 alert read:fatal:handshake failure
SSL_connect:error in SSLv2/v3 read server hello A
140342855083936:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1520095823
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
I have also tried with wget :
wget -v -d --secure-protocol=TLSv1 --no-check-certificate --certificate=/cert.pem --private-key=/cert.key https://host
URI encoding = «UTF-8»
Created socket 3.
Releasing 0x0000000002538850 (new refcount 1).
Initiating SSL handshake.
SSL handshake failed.
OpenSSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
Closed fd 3
Incapable d'établir une connexion SSL.
Files are pem b64 format and not encryption password.
I have added CA autority certificate from both remote ssl server and client authentificate certificate (intranet CA) in ca-bundle (redhat).
It seems to work with Internet Explorer (using only tls1.0) !!
Anyone can help me ? Is certificate (ssl server or auth client) can be the problem or not (because it handshake stop after 'client hello') ?
I'm going to tried with fiddler like a proxy https server from Windows IE...
Thank you
We are facing an issue on the client side TLS. As you see below the handshake is done properly but then there is no more data sent from the SG client so the connection is closed.
To test I am using this link https://caplonsgprd-x.integration.ibmcloud.com:xxxx/PATH/ to initiate the request which reaches the client configured for TLS and then I see the below in the logs:
[Wed Sep 30 14:22:13 2015] [debug] ssl_engine_kernel.c(1907): OpenSSL: Handshake: done
[Wed Sep 30 14:22:13 2015] [info] Connection: Client IP: xx.xx.xx.xx, Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
[Wed Sep 30 14:22:13 2015] [debug] mod_monitoring.c(213): monitor: Update counters for event 'tls:handshake:done'
[Wed Sep 30 14:22:13 2015] [debug] MonitoringCounter.c(375): monitor: MonitoringCounter_updateCounter (null) TLS_HandshakeSucceed 1
[Wed Sep 30 14:22:13 2015] [debug] mod_monitoring.c(213): monitor: Update counters for event 'tls:handshake:exit'
[Wed Sep 30 14:22:13 2015] [debug] ssl_engine_io.c(1952): OpenSSL: I/O error, 5 bytes expected to read on BIO#7f5eb00011e0 [mem: 7f5ef0751de3] -> Here we expected the client to send the applicative data which is the HTTPS request with the PATH.
[Wed Sep 30 14:22:13 2015] [info] [client xx.xx.xx.xx] (70014)End of file found: SSL input filter read failed.
I've gone through the flow in Bluemix US of creating a TCP destination to mongodb with client side TLS enabled with a self signed cert.
If the cert is uploaded, it looks like the client needs to be restarted to pick up the cert and use it. Once the client is restarted, the cert should be recognized and I was able to connect to my SSL enabled mongodb.
Edit:
Secure Gateway does not currently support multiple client TLS CA files to be uploaded, so the client will fail to connect if the chain consists of more than one CA cert.
Whenever a request comes to apache server it is not able to fulfill it. I am getting following error in apache error logs
[Fri Nov 21 18:02:02 2014] [info] [client 10.246.86.135] Connection to child 75 established (server myserver.com:443)
[Fri Nov 21 18:02:02 2014] [info] Seeding PRNG with 1024 bytes of entropy
[Fri Nov 21 18:02:02 2014] [debug] ssl_engine_kernel.c(1871): OpenSSL: Handshake: start
[Fri Nov 21 18:02:02 2014] [debug] ssl_engine_kernel.c(1879): OpenSSL: Loop: before/accept initialization
[Fri Nov 21 18:02:02 2014] [debug] ssl_engine_io.c(1947): OpenSSL: I/O error, 11 bytes expected to read on BIO#7f94c4001360 [mem: 7f950c024bd0]
[Fri Nov 21 18:02:02 2014] [debug] ssl_engine_kernel.c(1908): OpenSSL: Exit: error in SSLv2/v3 read client hello A
[Fri Nov 21 18:02:02 2014] [info] [client 10.246.86.135] (70014)End of file found: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
[Fri Nov 21 18:02:02 2014] [info] [client 10.246.86.135] Connection closed to child 75 with abortive shutdown (server myserver.com:443)
Tried to establish connectivity to server, got following outputs
user#server: openssl s_client -connect 10.246.86.142:8444 -state -nbio
CONNECTED(00000003)
turning on non blocking io
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
write R BLOCK
SSL3 alert read:fatal:handshake failure
SSL_connect:error in SSLv2/v3 read server hello A
140342456735560:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 263 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Also
user#server: wget https://10.246.86.142:8444 --debug
DEBUG output created by Wget 1.12 on linux-gnu.
--2014-11-21 17:57:39-- https://10.246.86.142:8444/
Connecting to 10.246.86.142:8444... connected.
Created socket 3.
Releasing 0x0000000001b6a2a0 (new refcount 0).
Deleting unused 0x0000000001b6a2a0.
Initiating SSL handshake.
SSL handshake failed.
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Closed fd 3
Unable to establish SSL connection.
Any ideas, what might be going wrong? All the certificates are in place and are valid
It was the issue with certificate at the weblogic end. Certificate was missing key usage 'key encipherment'
When certificate with key encipherment usage was imported at weblogic end, the connection was successful.
I've ran into a problem using mod_proxy/mod_ssl. The Apache HTTP server on SLES 11 SP3 64 bit, OpenSSL 1.0.1.f acts as SSL proxy to the Weblogic 10.3 running on Redhat. The mod_ssl is configured correctly - it works when proxying to to non-ssl serves. Also, the certificate on the proxy was issued with extensions allowing it to be used as both SSL client and server.
Due the regulations servers in this organisation are not allowed insecure communication, so the proxy must use SSL communicating to the application serves.
The problem occurs with SSL handshake between Apache and Weblogic. Perhaps they can't agree on ciphers? What do those 7 bytes received indicate?
[Thu Sep 18 09:32:14 2014] [debug] mod_proxy.c(1036): Running scheme https handler (attempt 0)
[Thu Sep 18 09:32:14 2014] [debug] mod_proxy_http.c(1995): proxy: HTTP: serving URL https://appdev2.example.com:8102/auth/logon.jsp?aa_param=user
[Thu Sep 18 09:32:14 2014] [debug] proxy_util.c(2022): proxy: HTTPS: has acquired connection for (appdev2.example.com)
[Thu Sep 18 09:32:14 2014] [debug] proxy_util.c(2078): proxy: connecting https://appdev2.example.com:8102/auth/logon.jsp?aa_param=user to appdev2.example.com:8102
[Thu Sep 18 09:32:14 2014] [debug] proxy_util.c(2236): proxy: connected /auth/logon.jsp?aa_param=user to appdev2.example.com:8102
[Thu Sep 18 09:32:14 2014] [debug] proxy_util.c(2487): proxy: HTTPS: fam 2 socket created to connect to appdev2.example.com
[Thu Sep 18 09:32:14 2014] [debug] proxy_util.c(2619): proxy: HTTPS: connection complete to 10.40.0.224:8102 (appdev2.example.com)
[Thu Sep 18 09:32:14 2014] [info] [client 10.40.0.224] Connection to child 0 established (server aaproxiedel1:443)
[Thu Sep 18 09:32:14 2014] [info] Seeding PRNG with 144 bytes of entropy
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_io.c(1090): [client 10.40.0.224] SNI extension for SSL Proxy request set to 'appdev2.example.com'
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_kernel.c(1903): OpenSSL: Handshake: start
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_kernel.c(1911): OpenSSL: Loop: before/connect initialization
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_kernel.c(1911): OpenSSL: Loop: SSLv2/v3 write client hello A
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_io.c(1939): OpenSSL: read 7/7 bytes from BIO#994fe0 [mem: 9ea880] (BIO dump follows)
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_io.c(1872): +-------------------------------------------------------------------------+
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_io.c(1911): | 0000: 15 03 00 00 02 02 28 ......( |
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_io.c(1917): +-------------------------------------------------------------------------+
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_kernel.c(1916): OpenSSL: Read: SSLv2/v3 read server hello A
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_kernel.c(1940): OpenSSL: Exit: error in SSLv2/v3 read server hello A
[Thu Sep 18 09:32:14 2014] [info] [client 10.40.0.224] SSL Proxy connect failed
[Thu Sep 18 09:32:14 2014] [info] SSL Library Error: 336032784 error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
[Thu Sep 18 09:32:14 2014] [info] [client 10.40.0.224] Connection closed to child 0 with abortive shutdown (server aaproxiedel1:443)
[Thu Sep 18 09:32:14 2014] [error] (502)Unknown error 502: proxy: pass request body failed to 10.40.0.224:8102 (appdev2.example.com)
[Thu Sep 18 09:32:14 2014] [error] [client 141.1.3.134] proxy: Error during SSL Handshake with remote server returned by /auth/logon.jsp
[Thu Sep 18 09:32:14 2014] [error] proxy: pass request body failed to 10.40.0.224:8102 (appdev2.example.com) from 141.1.3.134 ()
[Thu Sep 18 09:32:14 2014] [debug] proxy_util.c(2040): proxy: HTTPS: has released connection for (appdev2.example.com)
[Thu Sep 18 09:32:14 2014] [debug] ssl_engine_kernel.c(1921): OpenSSL: Write: SSL negotiation finished successfully
[Thu Sep 18 09:32:14 2014] [info] [client 141.1.3.134] Connection closed to child 2 with standard shutdown (server aaproxiedel1:443)
Some of the things you can try is enabling "the WebLogic Plugin". This is in the Domain -> Configuration -> Web Applications and server -> General -> Advanced.. This enables all weblogic related plugins to work.
If this doesn't fix it, try to enable tunneling in protocols.
What do you see on the Weblogic logs? Both Access and the server log file?