Configuring SSL connector in Tomcat 9 throws NullPointerException - java-9

While I can see Tomcat's splash page on localhost:8080, I am having problems to get a JSSE Connector to work. I am using Tomcat 9.0.2 on JDK 9.0.1 on Ubuntu 16.04.
My connector is:
<Connector port="8443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
maxThreads="150"
SSLEnabled="true"
scheme="https"
secure="true" >
<SSLHostConfig>
<Certificate certificateKeystoreFile="../.keystore"
certificateKeystorePassword="changeit"
certificateKeyAlias="tomcat"
type="RSA" />
</SSLHostConfig>
</Connector>
However, when on the browser I go to localhost:8443, I see the following:
On Firefox:
"The connection was reset. The connection to the server was reset while the page was loading."
On Chromium:
"This page isn’t working. localhost didn’t send any data. ERR_EMPTY_RESPONSE"
I see that the keystore file is being correctly read. When I do:
openssl s_client -debug -connect localhost:8443
the output is the following:
CONNECTED(00000003)
write to 0xb9f0b0 [0xb9fdb0] (305 bytes => 305 (0x131))
...
depth=0 C = EC, ST = mystate, L = mycity, O = myorg, OU = myou, CN = my name
verify error:num=18:self signed certificate
verify return:1
depth=0 C = EC, ST = mystate, L = mycity, O = myorg, OU = myou, CN = my name
verify return:1
...
Certificate chain
0 s:/C=EC/ST=mystate/L=mycity/O=myorg/OU=myou/CN=my name
i:/C=EC/ST=mystate/L=mycity/O=myorg/OU=myou/CN=my name
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/C=EC/ST=mystate/L=mycity/O=myorg/OU=myou/CN=my name
issuer=/C=EC/ST=mystate/L=mycity/O=myorg/OU=myou/CN=my name
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1353 bytes and written 431 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: 65D77EF99F8E4E7D145ABC005CCBFAA283533280995D7203A0220A6C1D11B9D4
Session-ID-ctx:
Master-Key: 5B2734E8A9EC21DE0090F2AC288A3D6E872FB292455B6F9FF84963D77F745D2E2E627D2A4358AE4A65F89B8EA123571A
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1515167322
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
In the catalina.out log file, I find that whenever I try to access through the browser localhost:8443, NPEs occur:
05-Jan-2018 08:48:06.848 SEVERE [https-jsse-nio-8443-exec-1] org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
java.lang.NullPointerException
at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLEngine(AbstractJsseEndpoint.java:180)
at org.apache.tomcat.util.net.SecureNioChannel.processSNI(SecureNioChannel.java:325)
at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:175)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1353)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:844)
This exception repeats 10 times where the only difference across repeats is the substring "exec-<NUMBER>" in the first line, where NUMBER ranges from 1 to 10 (in the example above, it was 1).
Why the doRun method throws an NPE is a mystery for me. I have tried many config combinations, to no avail. What's wrong?

This issue was addressed by https://bz.apache.org/bugzilla/show_bug.cgi?id=61914 and will be resolved in Tomcat 9.0.3+.
A null check was added to o.a.t.util.net.AbstractJsseEndpoint.createSSLEngine(), line 180, to rectify a potential NPE when using Java 9.

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

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.

NGINX Ingress controller not updating affinity cookie

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>

Kerberos | Cloudera | KrbException: Encryption type AES256 CTS mode with HMAC SHA1-96

I have been trying to setup Kerberos for CDH 4.5 which was setup using the Cloudera Manager Installer.
The instructions are from the following link:
http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM4Ent/4.5.2/Configuring-Hadoop-Security-with-Cloudera-Manager/cmeechs_topic_4.html
After setting up and KDC I copied the JCE policy for Java 6 files to the following location:
/usr/java/jdk1.6.0_31/lib/security/
Following is my "/var/kerberos/krb5kdc/kdc.conf" file:
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88
[realms]
MYREALM.COM = {
master_key_type = aes256-cts
acl_file = /var/kerberos/krb5kdc/kadm5.acl
dict_file = /usr/share/dict/words
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
}
Following is my "/etc/krb5.conf" file:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MYREALM.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
MYREALM.COM = {
kdc = node1.hcluster
admin_server = node1.hcluster
}
[domain_realm]
.hcluster = MYREALM.COM
hcluster = MYREALM.COM
This file is present in all the nodes.
However after following all the steps from the instructions all services fail to communicate with each other.
Following is the exception from the namenode logs:
2014-02-05 11:42:35,072 INFO org.apache.hadoop.ipc.Server: IPC Server listener on 8022: readAndProcess threw exception javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)] from client 10.1.3.104. Count of bytes read: 0
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)]
at com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:159)
at org.apache.hadoop.ipc.Server$Connection.saslReadAndProcess(Server.java:1250)
at org.apache.hadoop.ipc.Server$Connection.readAndProcess(Server.java:1456)
at org.apache.hadoop.ipc.Server$Listener.doRead(Server.java:759)
at org.apache.hadoop.ipc.Server$Listener$Reader.doRunLoop(Server.java:557)
at org.apache.hadoop.ipc.Server$Listener$Reader.run(Server.java:532)
Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)
at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:741)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:137)
... 5 more
Caused by: KrbException: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled
at sun.security.krb5.EncryptionKey.findKey(EncryptionKey.java:481)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:260)
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:134)
at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:79)
at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:724)
... 8 more
Any help is really appreciated.
I was able to get some help from Cloudera and figured out that the mistake was in the location for the JCE policy jars.
The correct location is : /usr/java/jdk1.6.0_31/jre/lib/security/.

Resources