NGINX Ingress controller not updating affinity cookie - session

The nginx ingress controller in out Kubernetes cluster should route the traffic according to a optional session cookie (the SHA1 hash of the ip and port). However, when I send a random value as cookie, no real cookie is set instead. This also happens when the target server is not alive any more.
* Trying 148.251.XXX.XXX...
* TCP_NODELAY set
* Connected to **********.com (148.251.XXX.XXX) port 444 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (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, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.********.com
* start date: Oct 17 06:25:15 2018 GMT
* expire date: Jan 15 06:25:15 2019 GMT
* subjectAltName: host "********" matched cert's "*.********.com"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* 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 0x55d70debd8e0)
> GET /management/health HTTP/2
> Host: ***********.com:444
> User-Agent: curl/7.58.0
> Accept: */*
> Cookie: cv-sid=aa; Domain=**********.com; Path=/; HttpOnly
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< server: nginx/1.15.2
< date: Mon, 29 Oct 2018 12:18:34 GMT
< content-type: application/vnd.spring-boot.actuator.v1+json;charset=UTF-8
< x-application-context: ********:kubernetes:8443
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
< expires: 0
< strict-transport-security: max-age=15724800; includeSubDomains
I found a PDF of the authors that explains the flow that I expect.
Update: The output of kubectl describe ingress ... is:
Name: ingress
Namespace: default
Address:
Default backend: default-http-backend:80 (<none>)
TLS:
tls-certificate-tmp terminates
Rules:
Host Path Backends
---- ---- --------
***.com
/ ***-service:80 (<none>)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/session-cookie-name: sid
nginx.ingress.kubernetes.io/ssl-redirect: true
nginx.ingress.kubernetes.io/proxy-body-size: 50M
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/affinity: cookie
nginx.ingress.kubernetes.io/session-cookie-hash: sha1
kubectl.kubernetes.io/last-applied-configuration: ...
Events: <none>

Related

Cannot GET https API on Window Server 2008 R2

My application need to call some API with https TLS 1.2 endpoint. The application is located in Window Server 2008 R2.
It work fine with Postman but cannot work in Java Spring Boot (JDK 11 + RestTemplate) and also not work with SoapUI and cUrl.
With Java, it throw exeption
javax.net.ssl.SSLException: Connection reset
With curl
C:\Users\devadmin>curl -v -k https://api.visa.com/
* Trying 198.217.139.29:443...
* Connected to api.visa.com (198.217.139.29) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* 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):
* OpenSSL SSL_connect: Connection was reset in connection to api.visa.com:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection was reset in connection to api.visa.com:443
With SoapUI 5.7.0
Fri May 20 08:30:44 ICT 2022:DEBUG:Attempt 1 to execute request
Fri May 20 08:30:44 ICT 2022:DEBUG:Sending request: GET /vmorc/offers/v1/all HTTP/1.0
Fri May 20 08:30:44 ICT 2022:DEBUG:I/O error closing connection
javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection reset
at sun.security.ssl.SSLSocketImpl.checkEOF(Unknown Source)
at sun.security.ssl.SSLSocketImpl.checkWrite(Unknown Source)
at sun.security.ssl.AppOutputStream.write(Unknown Source)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:131)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:138)
at org.apache.http.impl.conn.LoggingSessionOutputBuffer.flush(LoggingSessionOutputBuffer.java:95)
at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:270)
at org.apache.http.impl.SocketHttpClientConnection.close(SocketHttpClientConnection.java:245)
at org.apache.http.impl.conn.DefaultClientConnection.close(DefaultClientConnection.java:164)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.close(AbstractPooledConnAdapter.java:152)
at org.apache.http.protocol.HttpRequestExecutor.closeConnection(HttpRequestExecutor.java:142)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:129)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:633)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:454)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$Helper.execute(HttpClientSupport.java:233)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport.execute(HttpClientSupport.java:323)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.submitRequest(HttpClientRequestTransport.java:297)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:227)
at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:119)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.net.ssl.SSLException: java.net.SocketException: Connection reset
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.SSLSocketImpl.handleException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.handleException(Unknown Source)
at sun.security.ssl.AppOutputStream.write(Unknown Source)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:131)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:138)
at org.apache.http.impl.conn.LoggingSessionOutputBuffer.flush(LoggingSessionOutputBuffer.java:95)
at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:270)
at org.apache.http.impl.AbstractHttpClientConnection.flush(AbstractHttpClientConnection.java:275)
at org.apache.http.impl.conn.AbstractClientConnAdapter.flush(AbstractClientConnAdapter.java:197)
at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:258)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$SoapUIHttpRequestExecutor.doSendRequest(HttpClientSupport.java:119)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
... 14 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
... 24 more
Fri May 20 08:30:44 ICT 2022:DEBUG:Closing the connection.
Fri May 20 08:30:44 ICT 2022:DEBUG:Connection closed
Fri May 20 08:30:44 ICT 2022:INFO:I/O exception (java.net.SocketException) caught when processing request: Connection reset
Fri May 20 08:30:44 ICT 2022:DEBUG:Connection reset
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
at sun.security.ssl.AppOutputStream.write(Unknown Source)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:131)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:138)
at org.apache.http.impl.conn.LoggingSessionOutputBuffer.flush(LoggingSessionOutputBuffer.java:95)
at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:270)
at org.apache.http.impl.AbstractHttpClientConnection.flush(AbstractHttpClientConnection.java:275)
at org.apache.http.impl.conn.AbstractClientConnAdapter.flush(AbstractClientConnAdapter.java:197)
at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:258)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$SoapUIHttpRequestExecutor.doSendRequest(HttpClientSupport.java:119)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:633)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:454)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$Helper.execute(HttpClientSupport.java:233)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport.execute(HttpClientSupport.java:323)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.submitRequest(HttpClientRequestTransport.java:297)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:227)
at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:119)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Fri May 20 08:30:44 ICT 2022:INFO:Retrying request
Fri May 20 08:30:44 ICT 2022:DEBUG:Reopening the direct connection.
Fri May 20 08:30:44 ICT 2022:DEBUG:Attempt 2 to execute request
.......................
Fri May 20 08:30:45 ICT 2022:INFO:Retrying request
Fri May 20 08:30:45 ICT 2022:DEBUG:Reopening the direct connection.
Fri May 20 08:30:45 ICT 2022:DEBUG:Attempt 4 to execute request
Fri May 20 08:30:45 ICT 2022:DEBUG:Sending request: GET /vmorc/offers/v1/all HTTP/1.0
Fri May 20 08:30:45 ICT 2022:DEBUG:I/O error closing connection
javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection reset
at sun.security.ssl.SSLSocketImpl.checkEOF(Unknown Source)
at sun.security.ssl.SSLSocketImpl.checkWrite(Unknown Source)
at sun.security.ssl.AppOutputStream.write(Unknown Source)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:131)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:138)
at org.apache.http.impl.conn.LoggingSessionOutputBuffer.flush(LoggingSessionOutputBuffer.java:95)
at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:270)
at org.apache.http.impl.SocketHttpClientConnection.close(SocketHttpClientConnection.java:245)
at org.apache.http.impl.conn.DefaultClientConnection.close(DefaultClientConnection.java:164)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.close(AbstractPooledConnAdapter.java:152)
at org.apache.http.protocol.HttpRequestExecutor.closeConnection(HttpRequestExecutor.java:142)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:129)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:633)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:454)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$Helper.execute(HttpClientSupport.java:233)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport.execute(HttpClientSupport.java:323)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.submitRequest(HttpClientRequestTransport.java:297)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:227)
at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:119)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.net.ssl.SSLException: java.net.SocketException: Connection reset
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.SSLSocketImpl.handleException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.handleException(Unknown Source)
at sun.security.ssl.AppOutputStream.write(Unknown Source)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:131)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:138)
at org.apache.http.impl.conn.LoggingSessionOutputBuffer.flush(LoggingSessionOutputBuffer.java:95)
at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:270)
at org.apache.http.impl.AbstractHttpClientConnection.flush(AbstractHttpClientConnection.java:275)
at org.apache.http.impl.conn.AbstractClientConnAdapter.flush(AbstractClientConnAdapter.java:197)
at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:258)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$SoapUIHttpRequestExecutor.doSendRequest(HttpClientSupport.java:119)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
... 14 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
... 24 more
Fri May 20 08:30:45 ICT 2022:DEBUG:Closing the connection.
Fri May 20 08:30:45 ICT 2022:DEBUG:Connection closed
Fri May 20 08:30:45 ICT 2022:DEBUG:Connection shut down
Fri May 20 08:30:45 ICT 2022:ERROR:Exception in request: java.net.SocketException: Connection reset
Fri May 20 08:30:45 ICT 2022:ERROR:An error occurred [Connection reset], see error log for details
Fri May 20 08:30:45 ICT 2022:INFO:Error getting response for [https://api.visa.com.All:Request 1]; java.net.SocketException: Connection reset
Openssl in same server
C:\openssl\bin>openssl s_client -state -connect api.visa.com:443
Loading 'screen' into random state - done
CONNECTED(0000017C)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL3 alert read:fatal:handshake failure
SSL_connect:error in SSLv2/v3 read server hello A
163092:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:./ssl/s23_clnt.c:580:
openssl in local machine
openssl s_client -state -connect api.visa.com:443
CONNECTED(00000084)
SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS read server hello
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
verify return:1
depth=0 C = US, ST = California, L = Foster City, O = Visa International Service Association, CN = api.visa.com
verify return:1
SSL_connect:SSLv3/TLS read server certificate
SSL_connect:SSLv3/TLS read server key exchange
SSL_connect:SSLv3/TLS read server certificate request
SSL_connect:SSLv3/TLS read server done
SSL_connect:SSLv3/TLS write client certificate
SSL_connect:SSLv3/TLS write client key exchange
SSL_connect:SSLv3/TLS write change cipher spec
SSL_connect:SSLv3/TLS write finished
SSL_connect:SSLv3/TLS write finished
SSL_connect:SSLv3/TLS read change cipher spec
SSL_connect:SSLv3/TLS read finished
---
Certificate chain
0 s:C = US, ST = California, L = Foster City, O = Visa International Service Association, CN = api.visa.com
i:C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
1 s:C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGxjCCBa6gAwIBAgIQAgYl0jd+Dh9K+623wLZioTANBgkqhkiG9w0BAQsFADBN
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E
aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMjIwMTI0MDAwMDAwWhcN
MjMwMjI0MjM1OTU5WjCBgDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju
aWExFDASBgNVBAcTC0Zvc3RlciBDaXR5MS8wLQYDVQQKEyZWaXNhIEludGVybmF0
aW9uYWwgU2VydmljZSBBc3NvY2lhdGlvbjEVMBMGA1UEAxMMYXBpLnZpc2EuY29t
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxhTk91X6oabj19sIcpKs
g3Dt8xbhtxX7hj/gWU2rbblkGSJtC+juFfVYvKI/MdVEuHXQWF/KO/j5Nrv7uFIa
GF1ij2whZ0VzzfVIwZ6AORnEvipQPqoJrqWeDUbWH7+TWYw/JuVtUVDLb4WTCuhy
AGpXmOOeAHkdFOECGPbGR7Vnvn/C51+daE1NVR1/gcuOSuZDzrKS2GxllC3nAnPj
67ITR7dR0paN01Bugo6BMEpZE7nTnBQb005YPO9mGYaXg8XeKgNI+eiF0QR+9D1T
64mZ6Qoq3m9f6eqyul9AtSzE90JDqh+fEmwSQXGaRpkNGBJR0g557En9coy5NIGV
2wIDAQABo4IDbDCCA2gwHwYDVR0jBBgwFoAUD4BhHIIxYdUvKOeNRji0LOHG2eIw
HQYDVR0OBBYEFLq61prBmN9tRW1yPNtHkOuXtdKgMBcGA1UdEQQQMA6CDGFwaS52
aXNhLmNvbTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMIGNBgNVHR8EgYUwgYIwP6A9oDuGOWh0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpY2VydFNIQTJTZWN1cmVTZXJ2ZXJDQS0xLmNybDA/oD2gO4Y5aHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2ljZXJ0U0hBMlNlY3VyZVNlcnZlckNB
LTEuY3JsMD4GA1UdIAQ3MDUwMwYGZ4EMAQICMCkwJwYIKwYBBQUHAgEWG2h0dHA6
Ly93d3cuZGlnaWNlcnQuY29tL0NQUzB+BggrBgEFBQcBAQRyMHAwJAYIKwYBBQUH
MAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBIBggrBgEFBQcwAoY8aHR0cDov
L2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMlNlY3VyZVNlcnZlckNB
LTIuY3J0MAwGA1UdEwEB/wQCMAAwggF+BgorBgEEAdZ5AgQCBIIBbgSCAWoBaAB1
AK33vvp8/xDIi509nB4+GGq0Zyldz7EMJMqFhjTr3IKKAAABfo0+i04AAAQDAEYw
RAIgL7FC2dC/vrFIkWRW1ubiOPN8DpIiDdm8MzrhQggcP+YCIDGMRhq3SHURSWTH
6zunFmvFA72AxGuIalGANmYLSeGmAHYANc8ZG7+xbFe/D61MbULLu7YnICZR6j/h
Ku+oA8M71kwAAAF+jT6LZAAABAMARzBFAiEAoFhcUK6ZY2BdDLQmBcA9/KL8xUcp
w4Wvvs+tw4ormO4CIHYgvG4W1Umx1ffnHCHJHaDYygpA+9ombLdg7SU9TmSRAHcA
s3N3B+GEUPhjhtYFqdwRCUp5LbFnDAuH3PADDnk2pZoAAAF+jT6LggAABAMASDBG
AiEAvQ9b50UFsZnj+9Tq2v5iujUH1JhPb1Rapet2K+EfvQcCIQCmx51NigGVAAtG
lYNrAK2d3pdh3BT01cBUsrkrMH78GTANBgkqhkiG9w0BAQsFAAOCAQEAIpNyqUXg
yIs3OuKeoAqurrlWJikJIikKrO8ajGvL9HlSoWhV5DEbo32k4h7FSiMOvcwCxqzP
UvO1K2zaAxRyMiB4E+9OVNSWpzuxFkXPMRoruQy+mfj1sn7dt30eLCsPN2fHLs79
RbO1Brgn2eGvTybg+xl0q+7++m2//dQp0ASifbvjuloCQ/VG6qlKBcsysQ2bawH5
VJpLlzZFy9AeqLJFpHEDJfyEpXyqqSpKDomeyu+kwRdKeMSDO87ic3DxdfAwHxV3
PEj2e+UL0az9B5Q2/EfHvXS/jsdEykULvJkNDvF3lMOPqXoIlpp/HjTBympmn+Qn
SmLg3JNmt1PEYA==
-----END CERTIFICATE-----
subject=C = US, ST = California, L = Foster City, O = Visa International Service Association, CN = api.visa.com
issuer=C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
---
Acceptable client certificate CA names
C = US, O = VISA, OU = Visa International Service Association, CN = VI CA1
C = US, O = VISA, OU = Visa International Service Association, CN = Visa Information Delivery External CA
C = US, O = VISA, OU = Visa International Service Association, CN = Visa Information Delivery Root CA
CN = VDPCA, O = VDPVISACA, C = US
CN = VDPCA, O = VDPVISACA, C = US
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4959 bytes and written 452 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.2, 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: 32E83402862CA8E61BB1A07BED75506A42D3AC94963734710F312B79BE05A07F
Session-ID-ctx:
Master-Key: 19EE1A9B6873D35D1FDEA404B4E9A830F0E7E1E6AD82CFC700F4C4EBA4238916DF708A8762958977A3FC54350850F61D
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1653039821
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
Extended master secret: yes
---
Add http trace: http trace
Why it still work with Postman and not work with other ways? And How can I resolve this?

JMeter with blazemeter recorder Request failed

I'm using Jmeter for the first time and I'm trying to run Jmeter script recorder by BlazeMeter recorder for chrome but I'm getting this error
Unfortunately the error you're showing to us doesn't contain sufficient amount of information in order to troubleshoot the issue.
Try re-running the request with SSL debug logging enabled, you will need to add the next line to system.properties:
javax.net.debug=ssl
Looking into curl command output, the protocol appears to be TLS so you will need to add the next line to jmeter.properties file as well:
https.default.protocol=TLS
Also as per the aforementioned curl command output you need to use TLSv1.3
curl -vvv https://menthar.joacademy.com/api/v1/users/login
* Trying 165.22.76.254:443...
* TCP_NODELAY set
* Connected to menthar.joacademy.com (165.22.76.254) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=menthar.joacademy.com
* start date: Jul 26 17:17:38 2020 GMT
* expire date: Oct 24 17:17:38 2020 GMT
* subjectAltName: host "menthar.joacademy.com" matched cert's "menthar.joacademy.com"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* 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 0x559d2c078db0)
> GET /api/v1/users/login HTTP/2
> Host: menthar.joacademy.com
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 404
< server: nginx/1.14.0 (Ubuntu)
< date: Tue, 04 Aug 2020 15:41:29 GMT
< content-type: application/json; charset=utf-8
< content-length: 21
< access-control-allow-origin: *
< x-dns-prefetch-control: off
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=15552000; includeSubDomains
< x-download-options: noopen
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< etag: W/"15-5KajTCx0AJD0xogoSeOjjV2M8K0"
< set-cookie: connect.sid=s%3A6x05ZbQfqYUNKn90zBnri0A9b0Hll7kX.xjRMo9p4qmHSMtRYdfxNJtlJCuRQ8ZdgQIKTt5ssbkw; Path=/; HttpOnly
<
* Connection #0 to host menthar.joacademy.com left intact
More information:
Diagnosing TLS, SSL, and HTTPS
Configuring JMeter
Apache JMeter Properties Customization Guide

The debugger does not pause at the next breakpoint and trace doesn't report anything

When I use curl to post a SOAP message into message flow, it takes 9 seconds to respond. Debug won't stop at breakpoints and User Trace doesn't report anything. Meanwhile when I do the same request from Postman or SoapUI (the first message takes the same amount of time, later all messages take around 70 - 200ms) debugger and user trace work as intended. What is cause of this behavior?
IBM App Connect Enterprise 11.0.0.8
curl --trace-time output:
03:29:07.484000 * Trying <host>...
03:29:07.484000 * TCP_NODELAY set
03:29:07.531000 * Connected to <host_name> (<host>) port 7800 (#0)
03:29:07.531000 > POST /service HTTP/1.1
03:29:07.531000 > Host: <host_name>:7800
03:29:07.531000 > User-Agent: curl/7.55.1
03:29:07.531000 > Accept: */*
03:29:07.531000 > Content-Length: 508
03:29:07.531000 > Content-Type: application/x-www-form-urlencoded
03:29:07.531000 >
03:29:07.546000 * upload completely sent off: 508 out of 508 bytes
03:29:16.671000 < HTTP/1.1 200 OK
03:29:16.671000 < Cache-Control: no-cache
03:29:16.671000 < Pragma: no-cache
03:29:16.687000 < Expires: -1
03:29:16.687000 < X-AspNet-Version: 4.0.30319
03:29:16.687000 < X-Powered-By: ASP.NET
03:29:16.687000 < Date: Fri, 22 May 2020 01:29:14 GMT
03:29:16.687000 < Content-Type: text/xml; charset=utf-8
03:29:16.703000 < Server: IBM App Connect Enterprise
03:29:16.703000 < Content-Length: 243
EDIT: I'm still trying to resolve the problem - this time with help of Wireshark and user trace:
curl:
02:56:37.781000 > POST /service HTTP/1.1
after few milliseconds Wireshark detects POST message from "curl machine" - that means there are no problems with the connection
after around 10s delay SoapInput receives data. Why it takes so long?
2020-05-23 02:56:37.257076 6220 UserTrace BIP11304I: The Parser of type 'MQROOT' has been deleted from address '0x131f1312190'. This thread now has '0' cached parsers.
2020-05-23 02:56:40.591580 3684 UserTrace BIP11303I: A Parser of type 'MQROOT' has been created at address '0x131f13144a0'. This thread now has '36' cached parsers.
2020-05-23 02:56:45.143380 3684 UserTrace BIP11501I: Received data from input node 'SOAP Input'.
The input node 'SOAP Input' has received data and has propagated it to the message flow 'link'.
2020-05-23 02:56:45.143880 3684 UserTrace BIP6060I: Node 'link.SOAP Input' used parser type 'Properties' to process a portion of the incoming message of length '0' bytes beginning at offset '0'.
Fixed by restarting the machine. Any clue what exactly caused this problem?

Spring Boot 2.2.x giving 301 through gateway facing internet after migration from 2.1.8

We have a Spring Boot application currently built with 2.1.8.RELEASE with cloud Greenwich.SR4 and this application can be accessible through both Internet and Intranet. To meet some of the compliance, we need to migrate to Spring Boot 2.2.x. As part of the same, migrated to SB 2.2.5 and Cloud Hoxton.SR3 also tried with Hoxton.RELEASE.
When migrated to SB 2.2.5, application can be accessible through Intranet, but not through internet. Below are the verbose logs captured through curl.
With Intranet
$ curl -v https://oauth2-authserver-dev.nonprod.abc.com/api/ie/oauthserver/actuator/health
* Trying 10.223.35.9...
* TCP_NODELAY set
* Connected to oauth2-authserver-dev.nonprod.abc.com (10.223.35.9) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (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, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=Minnesota; L=Plymouth; O=ABC Group Inc.; CN=oauth2-authserver.stg.svc
* start date: Jun 17 15:36:08 2019 GMT
* expire date: Jun 16 15:36:08 2020 GMT
* subjectAltName: host "oauth2-authserver-dev.nonprod.abc.com" matched cert's "oauth2-authserver-dev.nonprod.abc.com"
* issuer: C=US; ST=Minnesota; L=Minneapolis; O=ABC; CN=ABCInternalIssuingCA2
* SSL certificate verify ok.
> GET /api/ie/oauthserver/actuator/health HTTP/1.1
> Host: oauth2-authserver-dev.nonprod.abc.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200
< Cache-Control: private
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< X-Frame-Options: DENY
< Content-Type: application/vnd.spring-boot.actuator.v3+json
< Transfer-Encoding: chunked
< Date: Thu, 09 Apr 2020 17:14:50 GMT
<
* Connection #0 to host oauth2-authserver-dev.nonprod.abc.com left intact
{"status":"UP"}
With Internet (from External)
~ $ curl -v https://apigw-dev.abc.com/api/ie/oauthserver/actuator/health
* Trying 168.183.43.71...
* TCP_NODELAY set
* Connected to apigw-dev.abc.com (168.183.43.71) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; postalCode=55343; ST=Minnesota; L=Minnetonka; street=9900 Bren Road East; O=ABC Group Inc.; OU=ABC Tech ETP & Info Srvcs; CN=apigw-dev.abc.com
* start date: Feb 24 00:00:00 2020 GMT
* expire date: Feb 23 23:59:59 2021 GMT
* subjectAltName: host "apigw-dev.abc.com" matched cert's "apigw-dev.abc.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Organization Validation Secure Server CA
* SSL certificate verify ok.
> GET /api/ie/oauthserver/actuator/health HTTP/1.1
> Host: apigw-dev.abc.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302
< Content-Length: 0
< Cache-Control: private
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Location: https://apigw-dev.abc.com/api/ie/oauthserver/actuator/health
< Date: Thu, 09 Apr 2020 17:09:37 GMT
< X-Kong-Upstream-Latency: 29
< X-Kong-Proxy-Latency: 6
< Via: kong/1.1.2
< Set-Cookie: 086c31780e9921a51376a20749328373=2385c3080d735964e8e509811a8ad7d8; path=/; HttpOnly
< Set-Cookie: BIGipServerapps.nonprod.abc.com_80=327929610.20480.0000; path=/
<
* Connection #0 to host apigw-dev.abc.com left intact
Is there anything we can find from the above logs? Please let me know, if any other information required to identify the problem.
Not sure exactly what updated in Spring Boot 2.2.5 onwards. Initially we thought, these is some incompatibility with SB 2.2.5 and tried to upgrade to SB 2.3.0, still faced the same issue. So explored various options to set in bootstrap.yml file. The following combination worked perfectly.
server:
port: 8443
http:
port: 8080
http2:
enabled: true
ssl:
enabled: true
key-alias: <cert_alias_name>
key-store-type: JKS
key-store: file:certificate.jks
key-store-password: <key_store_password>
trust-store: ${server.ssl.key-store}
trust-store-password: ${server.ssl.key-store-password}
trust-store-type: JKS
forward-headers-strategy: framework
Here, we have added server.http2.enabled and server.forward-headers-strategy properties additionally. Then we started getting 2XX response.

Apache Camel https4 client not using the same tcp port for multiple requests with keepAlive=true

Hi I am using Apache camel http4 component to send a https request with keepAlive=true but when i see the netstat after sending multiple requests I see each request opens a new TCP port to the peer.
I feel this should not be the usual behavior of keepAlive transactions, why the same TCP port is not being reused for communicating with the server and how can that be achieved if at all it can be.
Turns out this is not a keep alive problem; connections are in fact kept alive properly. The problem is that the connections as part of the pool managed by default PoolingHttpClientConnectionManager were not being reused. Both things could've been easily seen by enabling the logging for Apache's HttpClient (that's used under the hood):
Keep-Alive is being used:
2018/12/19 07:59:17:470 CET [DEBUG] wire - http-outgoing-7 << "HTTP/1.1 200 OK[\r][\n]"
2018/12/19 07:59:17:470 CET [DEBUG] wire - http-outgoing-7 << "Keep-Alive: timeout=5, max=300[\r][\n]"
2018/12/19 07:59:17:470 CET [DEBUG] wire - http-outgoing-7 << "Server: Apache-Coyote/1.1[\r][\n]"
2018/12/19 07:59:17:470 CET [DEBUG] wire - http-outgoing-7 << "Content-Encoding: gzip[\r][\n]"
2018/12/19 07:59:17:470 CET [DEBUG] wire - http-outgoing-7 << "Vary: Accept-Encoding[\r][\n]"
2018/12/19 07:59:17:470 CET [DEBUG] wire - http-outgoing-7 << "Cluster-Id: A[\r][\n]"
2018/12/19 07:59:17:470 CET [DEBUG] wire - http-outgoing-7 << "Date: Wed, 19 Dec 2018 06:59:17 GMT[\r][\n]"
2018/12/19 07:59:17:470 CET [DEBUG] wire - http-outgoing-7 << "Content-Type: text/xml[\r][\n]"
2018/12/19 07:59:17:471 CET [DEBUG] wire - http-outgoing-7 << "Content-Length: 239[\r][\n]"
2018/12/19 07:59:17:471 CET [DEBUG] wire - http-outgoing-7 << "[\r][\n]"
Connections not being reused:
2018/12/19 08:00:08:240 CET [DEBUG] PoolingHttpClientConnectionManager - Connection request: [route: {s}->https://someurl.com:443][total kept alive: 1; route allocated: 1 of 1; total allocated: 1 of 1]
2018/12/19 08:00:08:240 CET [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-7: Close connection
2018/12/19 08:00:08:242 CET [DEBUG] PoolingHttpClientConnectionManager - Connection leased: [id: 8][route: {s}->https://someurl.com:443][total kept alive: 0; route allocated: 1 of 1; total allocated: 1 of 1]
Note that one can easily enable logging for HttpClient by passing some arguments to JVM at startup.
So, why are connections not being reused then? This is due to the fact that SSL is being used and the PoolingHttpClientConnectionManager used by Apache's HttpClient not allowing reuse of a connection in case the user principal from the existing connection differs from the requested connection (facilitated by DefaultUserTokenHandler). See also e.g. this Stackoverflow post. Solution is to implement a custom UserTokenHandler (or use the NullTokenHandler if that's sufficient) and configure the HttpClientBuilder accordingly.
Did you already analyze the HTTP response headers in order to check whether KeepAlive is being taken into account and with which timeout value.
Example of expected response:
HTTP/1.1 200 OK
Connection: Keep-Alive
Keep-Alive: timeout=10, max=20
Content-Type: text/html; charset=UTF-8
Date: ...
Content-Length: ...

Resources