I am using axis client to invoke a SOAP service.
_call.invoke(new java.lang.Object[] {orderInfo_MT});
I am getting exception in the execution of the above code..
at org.apache.axis.transport.http.HTTPSender.readFromSocket(HTTPSender.java:744)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
This piece of code used to work fine earlier, not sure why it breaks now.
We had an expired certificate and so replaced the expired certificate with a valid one. But I am not sure whether is any connection between the new certificate and this issue.
Can someone provide some inputs on this issue ?
Updating the additonal logs from the catalina logs..
Padded plaintext after DECRYPTION: len = 32 0000: 01 00 B2 B9 73 FE
93 14 A5 3F DD 37 99 C6 40 74 ....s....?.7..#t 0010: DE E9 77 AB F2
E5 09 09 09 09 09 09 09 09 09 09 ..w............. http-9080-1, RECV
TLSv1 ALERT: warning, close_notify http-9080-1, called
closeInternal(false) http-9080-1, SEND TLSv1 ALERT: warning,
description = close_notify Padded plaintext before ENCRYPTION: len =
32 0000: 01 00 DA F5 38 5F 4D A5 ED 1B FF 8A 59 8C 6B F3
....8_M.....Y.k. 0010: 68 14 8B D4 09 61 09 09 09 09 09 09 09 09 09
09 h....a.......... http-9080-1, WRITE: TLSv1 Alert, length = 32 [Raw
write]: length = 37 0000: 15 03 01 00 20 8C B0 D8 D3 B9 56 50 76 8E
C0 FB .... .....VPv... 0010: 4E D7 37 86 69 BB 8C 72 11 AF 3E A7 1F
CE 71 58 N.7.i..r..>...qX 0020: AE 14 8A 9C 9B
..... http-9080-1, called closeSocket(selfInitiated) http-9080-1,
called close() http-9080-1, called closeInternal(true)
AxisFault faultCode: {http://xml.apache.org/axis/}HTTP faultSubcode:
faultString: (401)Unauthorized faultActor: faultNode:
faultDetail: {}:return code: 401
{http://xml.apache.org/axis/}HttpErrorCode:401
(401)Unauthorized
at org.apache.axis.transport.http.HTTPSender.readFromSocket(HTTPSender.java:744)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at org.worldbank.eservices.internal_order_processing.OrderInformation_MIBindingStub.orderInformation_MI(OrderInformation_MIBindingStub.java:182)
at org.worldbank.ecommerce.service.backend.PIIntegration.invokePIWebservice(PIIntegration.java:75)
at org.worldbank.ecommerce.service.backend.PIIntegration.invokePIWebservice(PIIntegration.java:97)
at org.worldbank.eservicesadaptors.webservices.services.OrderXiPostingService.OrderXiPostingServiceSoapBindingImpl.eServicesOrderXiPosting(OrderXiPostingServiceSoapBindingImpl.java:45)
at org.worldbank.eservicesadaptors.webservices.services.OrderXiPostingService.OrderXiPostingServiceSoapBindingSkeleton.eServicesOrderXiPosting(OrderXiPostingServiceSoapBindingSkeleton.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:397)
at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:186)
at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:454)
at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:745)
Related
I am trying to secure the Akka Management port of a Scala microservice with TLS by starting Akka Management programatically on port 8558 via AkkaManagement:withHttpsConnectionContext().
When the Scala service is run, it reads from the configuration and starts Akka Management fine, but does not appear to be operating with TLS encryption enabled.
~$ telnet localhost 8558
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /cluster/members HTTP/1.0
Host: 127.0.0.1
HTTP/1.1 200 OK
Server: akka-http/10.4.0
Date: Fri, 27 Jan 2023 20:26:00 GMT
Connection: close
Content-Type: application/json
Content-Length: 439
From what I can tell, Akka Management is serving HTTP from what should be the HTTPS port, and not encrypting the response.
:~$ openssl s_client -connect localhost:8558 -state -debug
CONNECTED(00000003)
SSL_connect:before SSL initialization
write to 0x56097b12c740 [0x56097b13ee80] (283 bytes => 283 (0x11B))
0000 - 16 03 01 01 16 01 00 01-12 03 03 05 27 1c 50 1b ............'.P.
0010 - e6 b6 23 5a e5 da d5 48-29 33 51 08 13 fb b6 aa ..#Z...H)3Q.....
0020 - 23 f4 2e 44 93 75 95 97-59 9a 1c 20 99 b0 36 06 #..D.u..Y.. ..6.
0030 - 1f 3d 79 d0 d8 e8 36 7e-41 5e 2e ff 70 f7 ce a5 .=y...6~A^..p...
0040 - 0a 5a 56 e4 a9 fc 15 09-d0 3c a7 9b 00 3e 13 02 .ZV......<...>..
0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa .....,.0........
0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27 .+./...$.(.k.#.'
0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d .g.....9.....3..
0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 8b ...=.<.5./......
0090 - 00 0b 00 04 03 00 01 02-00 0a 00 0c 00 0a 00 1d ................
00a0 - 00 17 00 1e 00 19 00 18-00 23 00 00 00 16 00 00 .........#......
00b0 - 00 17 00 00 00 0d 00 2a-00 28 04 03 05 03 06 03 .......*.(......
00c0 - 08 07 08 08 08 09 08 0a-08 0b 08 04 08 05 08 06 ................
00d0 - 04 01 05 01 06 01 03 03-03 01 03 02 04 02 05 02 ................
00e0 - 06 02 00 2b 00 05 04 03-04 03 03 00 2d 00 02 01 ...+........-...
00f0 - 01 00 33 00 26 00 24 00-1d 00 20 4e 63 c8 62 95 ..3.&.$... Nc.b.
0100 - f3 8e a4 b2 04 44 1a 83-6e 53 99 4b ef d0 f7 51 .....D..nS.K...Q
0110 - eb 95 b5 8c 1d 3c f7 f7-fa c1 1b .....<.....
SSL_connect:SSLv3/TLS write client hello
read from 0x56097b12c740 [0x56097b135c63] (5 bytes => 5 (0x5))
0000 - 48 54 54 50 2f HTTP/
SSL_connect:error in error
139911147234624:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 283 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
read from 0x56097b12c740 [0x56097b123f00] (8192 bytes => 189 (0xBD))
0000 - 31 2e 31 20 34 30 30 20-42 61 64 20 52 65 71 75 1.1 400 Bad Requ
0010 - 65 73 74 0d 0a 53 65 72-76 65 72 3a 20 61 6b 6b est..Server: akk
0020 - 61 2d 68 74 74 70 2f 31-30 2e 34 2e 30 0d 0a 44 a-http/10.4.0..D
0030 - 61 74 65 3a 20 46 72 69-2c 20 32 37 20 4a 61 6e ate: Fri, 27 Jan
0040 - 20 32 30 32 33 20 32 30-3a 33 36 3a 30 32 20 47 2023 20:36:02 G
0050 - 4d 54 0d 0a 43 6f 6e 6e-65 63 74 69 6f 6e 3a 20 MT..Connection:
0060 - 63 6c 6f 73 65 0d 0a 43-6f 6e 74 65 6e 74 2d 54 close..Content-T
0070 - 79 70 65 3a 20 74 65 78-74 2f 70 6c 61 69 6e 3b ype: text/plain;
0080 - 20 63 68 61 72 73 65 74-3d 55 54 46 2d 38 0d 0a charset=UTF-8..
0090 - 43 6f 6e 74 65 6e 74 2d-4c 65 6e 67 74 68 3a 20 Content-Length:
00a0 - 32 33 0d 0a 0d 0a 55 6e-73 75 70 70 6f 72 74 65 23....Unsupporte
00b0 - 64 20 48 54 54 50 20 6d-65 74 68 6f 64 d HTTP method
read from 0x56097b12c740 [0x56097b123f00] (8192 bytes => 0 (0x0))
It also looks like attempting to access Akka Management with TLS is also failing completely.
I'm seeing the following log message on the microservice when using the openssl command:
[WARN] [akka.actor.ActorSystemImpl] [] [inbound-transaction-akka.actor.default-dispatcher-65] [] [] [] [] - Illegal request, responding with status '400 Bad Request': Unsupported HTTP method: The HTTP method started with 0x16 rather than any known HTTP method from 192.168.96.1:39184. Perhaps this was an HTTPS request sent to an HTTP endpoint?
I tried starting Akka Management programatically with TLS encryption, and got unencrypted HTTP instead.
Here is the code used to setup HTTPS and start Akka Management:
def getHttpsConnectionContext(config: HttpsConfig): SSLContext = {
val keystore: KeyStore = KeyStore.getInstance("PKCS12")
val keystoreFile: InputStream =
getClass.getClassLoader.getResourceAsStream(config.keystoreFile)
val keystorePassword = config.keystorePassword.toCharArray
keystore.load(keystoreFile, keystorePassword)
val keyManagerFactory: KeyManagerFactory =
KeyManagerFactory.getInstance("SunX509")
keyManagerFactory.init(keystore, keystorePassword)
val trustManagerFactory: TrustManagerFactory =
TrustManagerFactory.getInstance("SunX509")
trustManagerFactory.init(keystore)
val sslContext: SSLContext = SSLContext.getInstance("TLS")
sslContext.init(
keyManagerFactory.getKeyManagers,
trustManagerFactory.getTrustManagers,
new SecureRandom
)
sslContext
}
val httpsConfig: HttpsConfig =
HttpsConfig(
actorSystem.settings.config,
"akka.moo.https"
) match {
case Some(value) => value
case None => throw new ConfigurationException("Bad HTTPS config")
}
val sslContext: SSLContext =
HttpsContext.getHttpsConnectionContext(httpsConfig)
val httpsServer: HttpsConnectionContext =
ConnectionContext.httpsServer(sslContext)
val management = AkkaManagement(actorSystem)
management.start(_.withHttpsConnectionContext(httpsServer))
I'm not sure what the problem here is.
Thank you ahead of time for your help.
All values are in hexadecimal number system. On Pentium in protected mode, registers have the following value: LDTR = 06000000, GDTR = 08000000, CR3 = 10000000, DS = 14, CS = 0034 CR0 = 00000001.
If the instruction (e.g. MOV AL, [2A66] accesses the logical address 2A66, what physical address does it access? At what address is the segment descriptor located? Current memory status, looking at absolute addresses is:
........
06000000 CD 20 FF 9F 00 9A EE FE 1D F0 4F 03 22 05 8A 03
06000010 22 05 17 03 22 93 0D 04 01 01 01 00 02 FF FF FF
.........
08000000 CA 20 FF 9F 00 9A E3 FE 1D F2 4F 08 23 05 8A 07
08000010 26 05 19 03 22 05 0D 04 01 02 01 00 02 FF FA FF
.........
10000020 3A 56 21 40 2A 38 42 18 2A 56 42 40 8E 48 42 18
10000030 2A 36 42 40 9A 48 42 18 7A 56 42 20 8E 48 42 18
10000040 23 60 42 40 4E A8 42 18 5A 56 42 40 8E 48 42 18
.........
40426860 C6 06 23 99 00 80 3E 1D 96 00 74 03 E9 99 00 E8
40426870 A6 01 E8 FF 03 75 19 80 3E C4 98 00 34 00 AD 0A
40426880 13 96 00 BA E9 89 75 03 E9 17 01 C6 06 1F 99 01
40426890 B8 00 6C BE 08 98 BB 21
.........
C6011D70 C6 06 23 99 00 80 3E 1D 96 00 74 03 E9 99 00 E8
C6011D80 A6 01 E8 FF 03 75 19 80 3E C4 98 00 34 00 AD 0A
C6011D90 13 96 00 BA E9 89 75 03 E9 17 01 C6 06 1F 99 01
Could you give me some guidelines what is the problem here and what I need to know to solve it? Operating systems and registry is new to me, so I don't know what I'm supposed to do here. I don't know even where should I start.
I have Keycloak hooked up to openldap via TLS. A customer requires that it work with StartTLS. I can connect to openldap and click on Test Authentication and received a success dialog. I can also import and view the users that are there.
But when I go to login as a user, I receive a bad credential error when using startTLS. When using just regular TLS, everything works as expected. I have logs below, but I'm not sure what is going wrong. This is very preplexing.
OpenLDAP log
5f163089 conn=1002 op=3 ENTRY dn="mail=1b.fa#omns.gumu,ou=omns users,dc=omns,dc=gumu"
ber_flush2: 260 bytes to sd 12
0000: 30 82 01 00 02 01 04 64 81 fa 04 32 6d 61 69 6c 0......d...2mail
0010: 3d 61 66 2e 62 31 40 6e 6f 6d 73 2e 6d 75 67 75 =1b.fa#omns.gumu
0020: 2c 6f 75 3d 4e 4f 4d 53 20 55 73 65 72 73 2c 64 ,ou=OMNS Users,d
0030: 63 3d 6e 6f 6d 73 2c 64 63 3d 6d 75 67 75 30 81 c=omns,dc=gumu0.
0040: c3 30 0d 04 02 63 6e 31 07 04 05 41 46 20 42 31 .0...cn1...1B FA
0050: 30 19 04 04 6d 61 69 6c 31 11 04 0f 61 66 2e 62 0...mail1...1b.f
0060: 31 40 6e 6f 6d 73 2e 6d 75 67 75 30 3c 04 0b 6f a#omns.gumu0<..o
0070: 62 6a 65 63 74 43 6c 61 73 73 31 2d 04 0d 69 6e bjectClass1-..in
0080: 65 74 4f 72 67 50 65 72 73 6f 6e 04 14 6f 72 67 etOrgPerson..org
0090: 61 6e 69 7a 61 74 69 6f 6e 61 6c 50 65 72 73 6f anizationalPerso
00a0: 6e 04 06 70 65 72 73 6f 6e 30 0d 04 02 73 6e 31 n..person0...sn1
00b0: 07 04 05 41 46 20 42 31 30 24 04 0f 63 72 65 61 ...FA 1B0$..crea
00c0: 74 65 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 teTimestamp1...2
00d0: 30 32 30 30 37 32 30 32 33 35 37 32 34 5a 30 24 0200720235724Z0$
00e0: 04 0f 6d 6f 64 69 66 79 54 69 6d 65 73 74 61 6d ..modifyTimestam
00f0: 70 31 11 04 0f 32 30 32 30 30 37 32 30 32 33 35 p1...20200720235
0100: 37 32 34 5a 724Z
tls_write: want=289, written=289
0000: 17 03 03 01 1c 00 00 00 00 00 00 00 04 e1 87 08 ................
0010: 6b 4a 7c 4c 18 16 e4 9d b5 84 95 36 ef c5 60 80 kJ|L.......6..`.
0020: e5 8a d2 73 7e 68 25 d7 ba 57 34 8f 5c ae 9f 7b ...s~h%..W4.\..{
0030: da 6f 46 b3 ef b8 e9 e2 21 3c 2a 48 21 27 4c f8 .oF.....!<*H!'L.
0040: 3b be 14 47 d8 5a 57 d3 ee 2f 9b 9c 38 6a 97 5b ;..G.ZW../..8j.[
0050: 5c 05 08 b6 47 06 7a 22 ce b9 e8 a7 45 f2 8c 82 \...G.z"....E...
0060: 8f 3e 6f 02 b7 15 9d 04 ac f1 85 4f e0 f6 3c 69 .>o........O..<i
0070: 09 91 55 bc ff 9f 24 4a 84 8d 0e 83 f1 6c 39 eb ..U...$J.....l9.
0080: b2 b9 d5 2f c8 91 65 f2 cc b9 7e ab 9f 19 f7 f6 .../..e...~.....
0090: 33 2c ca 77 60 54 66 7b 67 d7 43 e9 ee 14 15 0c 3,.w`Tf{g.C.....
00a0: 54 ff 03 84 15 57 e7 30 74 c0 6f 4f 73 47 41 31 T....W.0t.oOsGA1
00b0: 13 cb f4 1a bd 0c c9 0e f6 19 9a b4 eb 20 cd 2d ............. .-
00c0: 84 c0 fc 6d 29 60 0b f4 aa 72 d8 2a bb 4b 26 c4 ...m)`...r.*.K&.
00d0: b8 f9 93 f8 d3 61 87 b6 fd 0b fd bc fd 98 b6 ed .....a..........
00e0: 9d 49 aa 01 08 86 bc f0 75 52 be 17 89 9b 5f 24 .I......uR...._$
00f0: ec a8 bd 49 b7 73 3c 62 c3 01 9b 35 6e 75 57 3b ...I.s<b...5nuW;
0100: 97 a3 f8 76 27 cf e7 9c 8d 03 a3 31 46 3b be 17 ...v'......1F;..
0110: 42 d5 6c 49 12 76 c3 ab a6 d6 ad e7 41 11 80 29 B.lI.v......A..)
0120: ca .
ldap_write: want=260, written=260
0000: 30 82 01 00 02 01 04 64 81 fa 04 32 6d 61 69 6c 0......d...2mail
0010: 3d 61 66 2e 62 31 40 6e 6f 6d 73 2e 6d 75 67 75 =1b.fa#omns.gumu
0020: 2c 6f 75 3d 4e 4f 4d 53 20 55 73 65 72 73 2c 64 ,ou=OMNS Users,d
0030: 63 3d 6e 6f 6d 73 2c 64 63 3d 6d 75 67 75 30 81 c=omns,dc=gumu0.
0040: c3 30 0d 04 02 63 6e 31 07 04 05 41 46 20 42 31 .0...cn1...1B FA
0050: 30 19 04 04 6d 61 69 6c 31 11 04 0f 61 66 2e 62 0...mail1...b1.f
0060: 31 40 6e 6f 6d 73 2e 6d 75 67 75 30 3c 04 0b 6f a#omns.gumu0<..o
0070: 62 6a 65 63 74 43 6c 61 73 73 31 2d 04 0d 69 6e bjectClass1-..in
0080: 65 74 4f 72 67 50 65 72 73 6f 6e 04 14 6f 72 67 etOrgPerson..org
0090: 61 6e 69 7a 61 74 69 6f 6e 61 6c 50 65 72 73 6f anizationalPerso
00a0: 6e 04 06 70 65 72 73 6f 6e 30 0d 04 02 73 6e 31 n..person0...sn1
00b0: 07 04 05 41 46 20 42 31 30 24 04 0f 63 72 65 61 ...1B FA0$..crea
00c0: 74 65 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 teTimestamp1...2
00d0: 30 32 30 30 37 32 30 32 33 35 37 32 34 5a 30 24 0200720235724Z0$
00e0: 04 0f 6d 6f 64 69 66 79 54 69 6d 65 73 74 61 6d ..modifyTimestam
00f0: 70 31 11 04 0f 32 30 32 30 30 37 32 30 32 33 35 p1...20200720235
0100: 37 32 34 5a 724Z
5f163089 <= send_search_entry: conn 1002 exit.
5f163089 send_ldap_result: conn=1002 op=3 p=3
5f163089 send_ldap_result: err=0 matched="" text=""
5f163089 send_ldap_response: msgid=4 tag=101 err=0
ber_flush2: 14 bytes to sd 12
0000: 30 0c 02 01 04 65 07 0a 01 00 04 00 04 00 0....e........
tls_write: want=43, written=43
0000: 17 03 03 00 26 00 00 00 00 00 00 00 05 80 a5 80 ....&...........
0010: 56 b4 40 a4 54 16 4c 6e e3 55 a9 a3 69 3b 10 a4 V.#.T.Ln.U..i;..
0020: 3e a0 d0 31 cd 18 50 57 07 e0 3e >..1..PW..>
ldap_write: want=14, written=14
0000: 30 0c 02 01 04 65 07 0a 01 00 04 00 04 00 0....e........
5f163089 conn=1002 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
5f163089 daemon: activity on 1 descriptor
5f163089 daemon: activity on:
5f163089 daemon: epoll: listen=6 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=7 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=8 active_threads=0 tvp=zero
5f163089 daemon: activity on 1 descriptor
5f163089 daemon: activity on: 12r
5f163089 daemon: read active on 12
5f163089 daemon: epoll: listen=6 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=7 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=8 active_threads=0 tvp=zero
5f163089 connection_get(12)
5f163089 connection_get(12): got connid=1002
5f163089 connection_read(12): checking for input on id=1002
ber_get_next
tls_read: want=5, got=5
0000: 15 03 03 00 1a .....
tls_read: want=26, got=26
0000: 00 00 00 00 00 00 00 04 8a 81 33 a7 14 58 00 e3 ..........3..X..
0010: 45 1e 2d 95 02 ce fe ae bd 2a E.-......*
ldap_read: want=8, got=0
5f163089 ber_get_next on fd 12 failed errno=0 (Success)
5f163089 connection_read(12): input error=-2 id=1002, closing.
5f163089 connection_closing: readying conn=1002 sd=12 for close
5f163089 connection_close: conn=1002 sd=12
5f163089 daemon: removing 12
tls_write: want=31, written=31
0000: 15 03 03 00 1a 00 00 00 00 00 00 00 06 a0 33 b9 ..............3.
0010: 00 19 05 d4 1d 2a 2b 06 ed f8 8b 7e 84 9d 25 .....*+....~..%
5f163089 conn=1002 fd=12 closed (connection lost)
5f163089 daemon: activity on 1 descriptor
5f163089 daemon: activity on:
5f163089 daemon: epoll: listen=6 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=7 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=8 active_threads=0 tvp=zero
5f163089 daemon: activity on 1 descriptor
5f163089 daemon: activity on:
5f163089 slap_listener_activate(6):
5f163089 daemon: epoll: listen=6 busy
5f163089 daemon: epoll: listen=7 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=8 active_threads=0 tvp=zero
5f163089 >>> slap_listener(ldap://openldap.omns.gumu)
5f163089 daemon: listen=6, new connection on 12
5f163089 daemon: added 12r (active) listener=(nil)
5f163089 conn=1003 fd=12 ACCEPT from IP=10.225.0.20:50666 (IP=0.0.0.0:389)
5f163089 daemon: activity on 1 descriptor
5f163089 daemon: activity on:
5f163089 daemon: epoll: listen=6 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=7 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=8 active_threads=0 tvp=zero
5f163089 daemon: activity on 1 descriptor
5f163089 daemon: activity on: 12r
5f163089 daemon: read active on 12
5f163089 daemon: epoll: listen=6 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=7 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=8 active_threads=0 tvp=zero
5f163089 connection_get(12)
5f163089 connection_get(12): got connid=1003
5f163089 connection_read(12): checking for input on id=1003
ber_get_next
ldap_read: want=8, got=8
0000: 16 03 03 01 ae 01 00 01 ........
5f163089 ber_get_next on fd 12 failed errno=34 (Numerical result out of range)
5f163089 connection_read(12): input error=-2 id=1003, closing.
5f163089 connection_closing: readying conn=1003 sd=12 for close
5f163089 connection_close: conn=1003 sd=12
5f163089 daemon: removing 12
5f163089 conn=1003 fd=12 closed (connection lost)
5f163089 daemon: activity on 1 descriptor
5f163089 daemon: activity on:
5f163089 daemon: epoll: listen=6 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=7 active_threads=0 tvp=zero
5f163089 daemon: epoll: listen=8 active_threads=0 tvp=zero
Keycloak Log
23:09:59,522 INFO [org.keycloak.storage.ldap.LDAPIdentityStoreRegistry] (default task-28) Creating new LDAP Store for the LDAP storage provider: 'omns-ldap', LDAP Configuration: {pagination=[true], fullSyncPeriod=[-1], startTls=[true], usersDn=[ou=OMNS Users,dc=omns,dc=gumu], connectionPooling=[true], cachePolicy=[DEFAULT], useKerberosForPasswordAuthentication=[false], importEnabled=[true], enabled=[true], bindDn=[cn=OMNS Manager,dc=omns,dc=gumu], usernameLDAPAttribute=[mail], changedSyncPeriod=[-1], lastSync=[1595285046], vendor=[other], uuidLDAPAttribute=[mail], connectionUrl=[ldap://openldap.omns.gumu:389], allowKerberosAuthentication=[false], syncRegistrations=[false], authType=[simple], debug=[false], searchScope=[1], useTruststoreSpi=[always], usePasswordModifyExtendedOp=[false], priority=[0], trustEmail=[false], userObjectClasses=[person, inetOrgPerson, organizationalPerson], rdnLDAPAttribute=[destinationindicator], editMode=[WRITABLE], validatePasswordPolicy=[false], batchSizeForSync=[1000]}, binaryAttributes: []
23:10:44,082 ERROR [org.keycloak.storage.ldap.idm.store.ldap.LDAPContextManager] (default task-29) Could not negotiate TLS: javax.naming.CommunicationException: Remote host terminated the handshake [Root exception is javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake]
at java.naming/com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3330)
at java.naming/javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at java.naming/javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at org.keycloak.keycloak-ldap-federation#11.0.0-SNAPSHOT//org.keycloak.storage.ldap.idm.store.ldap.LDAPContextManager.startTLS(LDAPContextManager.java:120)
at org.keycloak.keycloak-ldap-federation#11.0.0-SNAPSHOT//org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager.authenticate(LDAPOperationManager.java:526)
at org.keycloak.keycloak-ldap-federation#11.0.0-SNAPSHOT//org.keycloak.storage.ldap.idm.store.ldap.LDAPIdentityStore.validatePassword(LDAPIdentityStore.java:355)
at org.keycloak.keycloak-ldap-federation#11.0.0-SNAPSHOT//org.keycloak.storage.ldap.LDAPStorageProvider.validPassword(LDAPStorageProvider.java:607)
at org.keycloak.keycloak-ldap-federation#11.0.0-SNAPSHOT//org.keycloak.storage.ldap.LDAPStorageProvider.isValid(LDAPStorageProvider.java:693)
at org.keycloak.keycloak-services#11.0.0-SNAPSHOT//org.keycloak.credential.UserCredentialStoreManager.validate(UserCredentialStoreManager.java:187)
at org.keycloak.keycloak-services#11.0.0-SNAPSHOT//org.keycloak.credential.UserCredentialStoreManager.isValid(UserCredentialStoreManager.java:168)
at org.keycloak.keycloak-services#11.0.0-SNAPSHOT//org.keycloak.credential.UserCredentialStoreManager.isValid(UserCredentialStoreManager.java:112)
at org.keycloak.keycloak-services#11.0.0-SNAPSHOT//org.keycloak.authentication.authenticators.directgrant.ValidatePassword.authenticate(ValidatePassword.java:47)
at org.keycloak.keycloak-services#11.0.0-SNAPSHOT//org.keycloak.authentication.DefaultAuthenticationFlow.processSingleFlowExecutionModel(DefaultAuthenticationFlow.java:443)
at org.keycloak.keycloak-services#11.0.0-SNAPSHOT//org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:252)
at org.keycloak.keycloak-services#11.0.0-SNAPSHOT//org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:978)
at org.keycloak.keycloak-services#11.0.0-SNAPSHOT//org.keycloak.protocol.oidc.endpoints.TokenEndpoint.resourceOwnerPasswordCredentialsGrant(TokenEndpoint.java:617)
at org.keycloak.keycloak-services#11.0.0-SNAPSHOT//org.keycloak.protocol.oidc.endpoints.TokenEndpoint.processGrantRequest(TokenEndpoint.java:216)
at jdk.internal.reflect.GeneratedMethodAccessor753.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:138)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:535)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:424)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:385)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:356)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:387)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:356)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:150)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:110)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:141)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:104)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:440)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:356)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.resteasy-jaxrs#3.11.2.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.api#2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.keycloak.keycloak-wildfly-extensions#11.0.0-SNAPSHOT//org.keycloak.provider.wildfly.WildFlyRequestFilter.lambda$doFilter$0(WildFlyRequestFilter.java:41)
at org.keycloak.keycloak-services#11.0.0-SNAPSHOT//org.keycloak.services.filters.AbstractRequestFilter.filter(AbstractRequestFilter.java:43)
at org.keycloak.keycloak-wildfly-extensions#11.0.0-SNAPSHOT//org.keycloak.provider.wildfly.WildFlyRequestFilter.doFilter(WildFlyRequestFilter.java:39)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow#19.1.0.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.core#2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.core#2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.core#2.1.0.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.core#2.1.0.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.core#2.1.0.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.core#2.1.0.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.core#2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#19.1.0.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.core#2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#19.1.0.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.core#2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow#19.1.0.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow#19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow#19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow#19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow#19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet#2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.core#2.1.0.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
at io.undertow.core#2.1.0.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
at java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1313)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1055)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:395)
at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:709)
at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:962)
at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:398)
at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:371)
at java.naming/com.sun.jndi.ldap.LdapClient.extendedOp(LdapClient.java:1198)
at java.naming/com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3278)
... 89 more
Suppressed: java.net.SocketException: Broken pipe (Write failed)
at java.base/java.net.SocketOutputStream.socketWrite0(Native Method)
at java.base/java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110)
at java.base/java.net.SocketOutputStream.write(SocketOutputStream.java:150)
at java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:81)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:357)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:398)
... 97 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1144)
... 99 more
23:10:44,085 WARN [org.keycloak.events] (default task-29) type=LOGIN_ERROR, realmId=omns, clientId=login-client, userId=887955e9-991f-4c8c-8c6f-60a406d93e58, ipAddress=10.0.2.15, error=invalid_user_credentials, auth_method=openid-connect, grant_type=password, client_auth_method=client-secret, username=1b.fa#omns.gumu, authSessionParentId=adc2d85f-0169-4663-987c-f4568eedbba8, authSessionTabId=WvWoCKvESsc
I have a digital signature (RSA - PKCS#1). After decrypting it with the RSA public key I get the following 128 bytes
00 01 ff ff ff .. ff 00 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 77 51 1b f4 d7 17 d7 ad 8c 2d e5 89 2a ca e0 6d a3 c0 7d 13 4d d7 b8 01 14 87 03 00 69 e4 9b b3
PKCS#1 padding removed, 51 bytes left:
30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 77 51 1b f4 d7 17 d7 ad 8c 2d e5 89 2a ca e0 6d a3 c0 7d 13 4d d7 b8 01 14 87 03 00 69 e4 9b b3
I would like two things about this:
Is it possible to determine the hash function used? Encoded algorithm ID should be prepended to the actual body of the digest, is it possible to tell what algorithm it is from the raw bytes?
Where does the actual digest start (how long the head / digest is)?
This appears to be EMSA-PKCS1-v1_5 as described in RFC 3447, which means that after removing the header and padding, you have a DER encoding of an AlgorithmIdentifier followed by the hash value itself.
From the RFC:
For the six hash functions mentioned in Appendix B.1, the DER
encoding T of the DigestInfo value is equal to the following:
[...]
SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 || H.
So in your example, the hash value is the SHA-256 hash starting 77511bf4d7....
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I've encountered a serious bug in OpenSSL 1.0.1 on Ubuntu 12.04:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665452
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666051 <- dated Oct 3 2012!
The gist of it is that I'm able to connect to some servers but not others. Connecting to google works:
openssl s_client -connect mail.google.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
...
Protocol : TLSv1.1
Cipher : ECDHE-RSA-RC4-SHA
Session-ID: 94DB1AC8531115C501434B16A5E9B735722768581778E4FEA4D9B19988551397
Session-ID-ctx:
Master-Key: 8694BF510CD7568CBAB39ECFD32D115C511529871F3030B67A4F7AEAF957D714D3E94E4CE6117F686C975EFF21FB8708
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - fb 52 d6 d3 3c a8 75 e1-1f 1d f6 23 ab ce 55 44 .R..<.u....#..UD
0010 - 27 bf ad c4 7a 0d 83 c8-48 59 48 4b 39 bb 3c c7 '...z...HYHK9.<.
0020 - 01 1e ad b3 13 de 65 d4-e8 ea e4 35 89 83 55 8e ......e....5..U.
0030 - e4 d5 9f 60 58 51 33 9b-83 34 b9 35 3d 46 cb a3 ...`XQ3..4.5=F..
0040 - 35 7b 48 5d 7b 86 5c d5-a1 14 9d 8c 3e 93 eb fb 5{H]{.\.....>...
0050 - ac 78 75 72 9b d2 bc 67-f2 fa 5b 75 80 a6 31 d8 .xur...g..[u..1.
0060 - 71 15 85 7f 55 4d dc fb-b0 b5 33 db 6d 36 8c c6 q...UM....3.m6..
0070 - e8 f9 54 7a 29 69 87 2c-dd f3 c5 cf 26 55 6f 6e ..Tz)i.,....&Uon
0080 - 45 73 7a 1d e4 b3 be b2-92 3f 0b ed c4 1c a5 24 Esz......?.....$
0090 - 3c f0 ca a5 <...
Start Time: 1354063165
Timeout : 300 (sec)
Verify return code: 0 (ok)
But connecting to facebook doesn't:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt -cipher SRP-AES-256-CBC-SHA
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0xddd2c0 [0xddd340] (64 bytes => 64 (0x40))
0000 - 16 03 01 00 3b 01 00 00-37 03 02 50 b5 5d 75 42 ....;...7..P.]uB
0010 - c2 78 55 49 b5 2e de 4f-00 a6 a8 d5 cf 10 92 44 .xUI...O.......D
0020 - 28 62 34 d6 61 5e 88 c3-68 8b 96 00 00 04 c0 20 (b4.a^..h......
0030 - 00 ff 02 01 00 00 09 00-23 00 00 00 0f 00 01 01 ........#.......
>>> TLS 1.1 [length 003b]
01 00 00 37 03 02 50 b5 5d 75 42 c2 78 55 49 b5
2e de 4f 00 a6 a8 d5 cf 10 92 44 28 62 34 d6 61
5e 88 c3 68 8b 96 00 00 04 c0 20 00 ff 02 01 00
00 09 00 23 00 00 00 0f 00 01 01
SSL_connect:unknown state
read from 0xddd2c0 [0xde28a0] (7 bytes => 7 (0x7))
0000 - 15 03 02 00 02 02 28 ......(
SSL3 alert read:fatal:handshake failure
<<< TLS 1.1 [length 0002]
02 28
SSL_connect:error in unknown state
140581179446944:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 64 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
The facebook connection either hangs after the client sends its hello buffer and never receives the server hello response, or returns with an error code if I pass in a cipher it recognizes. This happens with both -tls1 and -ssl3. I've tried every parameter to openssl I can think of.
apt-cache showpkg openssl
...
Provides:
1.0.1-4ubuntu5.5 -
1.0.1-4ubuntu5.3 -
1.0.1-4ubuntu3 -
I've also tried every parameter I can think of to curl but with no success, because it uses openssl under the hood.
I'm concerned that Ubuntu can't establish secure connections (an astounding statement, I realize). After two solid days of beating my head against this problem, I'm basically praying at this point that someone knows a workaround. I'm considering a downgrade to OpenSSL 1.0.0 or using libcurl4-dev with gnutls-dev instead. Both solutions leave a rotten taste in my mouth. Thanks in advance for any help you can provide.
P.S. all of this work is so that my server can interface with external https REST APIs. I consider this a fundamental requirement in any webserver today, no excuses.
UPDATE: Here is my output without passing a cipher. It doesn't matter if I pass -CAfile or not either:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x14ed1a0 [0x1515bf0] (226 bytes => 226 (0xE2))
0000 - 16 03 01 00 dd 01 00 00-d9 03 02 50 b6 39 78 6a ...........P.9xj
0010 - 24 95 8e dc 62 19 37 4b-ab 77 b8 66 cd 48 ba a2 $...b.7K.w.f.H..
0020 - a1 2a f8 1d f8 c9 5d fb-9d db 84 00 00 66 c0 14 .*....]......f..
0030 - c0 0a c0 22 c0 21 00 39-00 38 00 88 00 87 c0 0f ...".!.9.8......
0040 - c0 05 00 35 00 84 c0 12-c0 08 c0 1c c0 1b 00 16 ...5............
0050 - 00 13 c0 0d c0 03 00 0a-c0 13 c0 09 c0 1f c0 1e ................
0060 - 00 33 00 32 00 9a 00 99-00 45 00 44 c0 0e c0 04 .3.2.....E.D....
0070 - 00 2f 00 96 00 41 c0 11-c0 07 c0 0c c0 02 00 05 ./...A..........
0080 - 00 04 00 15 00 12 00 09-00 14 00 11 00 08 00 06 ................
0090 - 00 03 00 ff 02 01 00 00-49 00 0b 00 04 03 00 01 ........I.......
00a0 - 02 00 0a 00 34 00 32 00-0e 00 0d 00 19 00 0b 00 ....4.2.........
00b0 - 0c 00 18 00 09 00 0a 00-16 00 17 00 08 00 06 00 ................
00c0 - 07 00 14 00 15 00 04 00-05 00 12 00 13 00 01 00 ................
00d0 - 02 00 03 00 0f 00 10 00-11 00 23 00 00 00 0f 00 ..........#.....
00e0 - 01 01 ..
>>> TLS 1.1 [length 00dd]
01 00 00 d9 03 02 50 b6 39 78 6a 24 95 8e dc 62
19 37 4b ab 77 b8 66 cd 48 ba a2 a1 2a f8 1d f8
c9 5d fb 9d db 84 00 00 66 c0 14 c0 0a c0 22 c0
21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00
84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0
03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00
9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00
41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00
12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02
01 00 00 49 00 0b 00 04 03 00 01 02 00 0a 00 34
00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09
00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15
00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f
00 10 00 11 00 23 00 00 00 0f 00 01 01
SSL_connect:unknown state
Why are you passing -cipher SRP-AES-256-CBC-SHA when connecting to graph.facebook.com? Facebook certainly doesn't support SRP: http://srp.stanford.edu/.
Does it work if you don't pass that?
Also, can you give the IP address that you're getting? With 69.171.229.17, I can reproduce that exact ClientHello (modulo the nonce and with RC4-SHA are the only cipher save the SCSV) and I get a successful handshake.
Lastly, have you tried doing over an SSH tunnel to somewhere else? Sadly, when deploying TLS features in Chrome we have repeatedly found networking hardware that breaks TLS connections. (Although I can't think of a case where -ssl3 wouldn't fix it unless the hardware was actively trying to censor connections.)
Setting the MTU on my Ubuntu box from 1500 to 1496 (due to one of our firewalls being set too low) allows me to receive a response from the server without having to reboot (be sure to call ifconfig first and write down your original MTU which should be 1500):
sudo ifconfig eth0 mtu 1496
I discovered my MTU by pinging with successively larger buffers (add 28 bytes for UDP header):
Fails for 1472 + 28 = 1500:
ping -s 1472 facebook.com
PING facebook.com (66.220.158.16) 1472(1500) bytes of data.
...
Works for 1468 + 28 = 1496:
ping -s 1468 facebook.com
PING facebook.com (69.171.229.16) 1468(1496) bytes of data.
1476 bytes from www-slb-ecmp-06-prn1.facebook.com (69.171.229.16): icmp_req=1 ttl=242 time=30.0 ms
...
With 1496 I'm now able to curl to facebook.com:
curl -v https://facebook.com
* About to connect() to facebook.com port 443 (#0)
* Trying 66.220.152.16... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
* subject: C=US; ST=California; L=Palo Alto; O=Facebook, Inc.; CN=www.facebook.com
* start date: 2012-06-21 00:00:00 GMT
* expire date: 2013-12-31 23:59:59 GMT
* subjectAltName: facebook.com matched
* issuer: O=VeriSign Trust Network; OU=VeriSign, Inc.; OU=VeriSign International Server CA - Class 3; OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: facebook.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: https://www.facebook.com/
< Content-Type: text/html; charset=utf-8
< X-FB-Debug: 3vAg1O5OG9hB/EWC+gk1Kl3WLJRGmlQDaEodirWb+i0=
< Date: Wed, 28 Nov 2012 19:52:25 GMT
< Connection: keep-alive
< Content-Length: 0
<
* Connection #0 to host facebook.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
I personally think that MTU should have absolutely nothing to do with what the user sees at the stream level with TCP so I hope the OpenSSL folks fix this. I also wish that someone would invent an automagic bug submitter for bugs that are profoundly widespread and time-sucking.