I have some issues with my Webmin when i try to bind it to the User and Group DB to allow LDAP users enter on webmin i have this issue
Failed to login to LDAP server as admin : invalid DN
So i when i check my logs on openldap this is what i have
ber_dump: buf=0x7f33f4002400 ptr=0x7f33f4002400 end=0x7f33f4002419 len=25
0000: 02 01 01 60 14 02 01 03 04 05 61 64 6d 69 6e 80 ...`......admin.
0010: 08 4e 44 67 35 47 36 44 46 .password
ber_dump: buf=0x7f33f4002400 ptr=0x7f33f4002403 end=0x7f33f4002419 len=22
0000: 60 14 02 01 03 04 05 61 64 6d 69 6e 80 08 4e 44 `......admin....
0010: 67 35 47 36 44 46 password
ber_dump: buf=0x7f33f4002400 ptr=0x7f33f400240f end=0x7f33f4002419 len=10
0000: 00 08 4e 44 67 35 47 36 44 46 ..password
5ebde922 conn=1001 op=0 do_bind: invalid dn (admin)
0000: 30 16 02 01 01 61 11 0a 01 22 04 00 04 0a 69 6e 0....a..."....in
0010: 76 61 6c 69 64 20 44 4e valid DN
Btw, with phpadmin it works great no issues,
so i will post the log here in debug 256
5ebdea13 conn=1000 op=0 do_bind: invalid dn (admin)
5ebdea13 conn=1000 op=0 RESULT tag=97 err=34 text=invalid DN
5ebdea14 conn=1000 fd=12 closed (connection lost)
Thanks,
Info
OS:Ubuntu 18.04
Openldap under docker.
Webmin under docker
I found out, what was wrong. I was trying to bind with:
dc=blackdragon, dc=tv
Instead of:
cn=Administrator, dc=balckdragon, dc=tv
Related
I am trying to find out if it is possible to confirm or check that a client certificate is being sent (from the client-side) when a 2-way SSL connection is being established, using tcpdump (and if so, how?). I am trying to do this because we need to validate that a 2-way SSL connection (vs. just a 1-way SSL connection) is actually being established.
In our configuration, the "client side" is an Oracle OAM Apache webgate, and the "server side" is an OAM server.
Connection is from the webgate ==> OAM server, listening on (for example) port 5575.
The connection is established when the webgate processes a request the 1st time, and the connection stays up for awhile after that, so the way I have been testing this is:
Start up the Apache (the webgate is an Apache module). At this point there is no connection to the OAM server port 5575.
Send a request (using a browser) to the Apache. This causes the webgate to establish a (supposedly 2-way SSL) connection to the OAM server port 5575.
I have been trying various tcpdump command lines (run on the client/webgate machine) to try to show/capture the webgate's client cert, but so far, I have not been able to see any indication that the webgate is sending a client cert.
I am not very familiar with tcpdump, so I was hoping that someone could suggest how to do this.
Thanks!
Jim
EDIT: I hope that this is ok to add on here. FYI, I have been unable to directly confirm whether 2-way SSL is occurring. However, I was able to do the following:
I did some tcpdump captures and read that into ssldump:
New TCP connection #2: 192.168.aa.bb(37256) <-> 172.31.xx.yy(5575)
0.0011 (0.0011) C>S
---------------------------------------------------------------
4e 4d 50 04 01 NMP..
---------------------------------------------------------------
0.0034 (0.0022) S>C
---------------------------------------------------------------
4e 4d 50 05 01 NMP..
---------------------------------------------------------------
0.0035 (0.0001) C>S
---------------------------------------------------------------
00 00 00 34 00 00 00 00 00 0d 70 72 6f 74 6f 63 ...4......protoc
6f 6c 3d 4e 41 50 20 76 65 72 73 69 6f 6e 3d 34 ol=NAP version=4
20 6f 6c 64 65 73 74 3d 31 20 63 6d 3d 6a 6c 74 oldest=1 cm=jlt
65 73 74 31 est1
---------------------------------------------------------------
0.0052 (0.0017) S>C
---------------------------------------------------------------
00 00 00 3e 00 00 00 00 00 0d 70 72 6f 74 6f 63 ...>......protoc
6f 6c 3d 4e 41 50 20 76 65 72 73 69 6f 6e 3d 35 ol=NAP version=5
20 6f 6c 64 65 73 74 3d 31 20 63 6c 69 65 6e 74 oldest=1 client
5f 6e 61 70 5f 76 65 72 73 69 6f 6e 3d 34 _nap_version=4
---------------------------------------------------------------
0.0054 (0.0001) C>S
---------------------------------------------------------------
00 00 00 12 00 00 00 00 01 00 73 74 73 3d 63 65 ..........sts=ce
72 74 rt
---------------------------------------------------------------
0.0097 (0.0043) S>C
---------------------------------------------------------------
00 00 00 12 00 00 00 00 01 00 73 74 73 3d 63 65 ..........sts=ce
72 74 rt
---------------------------------------------------------------
2 1 0.0106 (0.0008) C>S V3.3(81) Handshake
ClientHello
Version 3.3
random[32]=
61 08 bc db 2a 3d e1 ac 7e fc e4 c8 cb 34 8b d4
65 f5 35 bc 31 89 d4 4b 99 5f 3b 22 f5 5a 67 bf
cipher suites
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
compression methods
NULL
extensions
signature_algorithms
ja3 string: 771,53-10-255,13,,
ja3 fingerprint: 9331064077bda87e0c2780d544d22b00
2 2 0.0128 (0.0022) S>C V3.3(2041) Handshake
ServerHello
Version 3.3
random[32]=
13 c8 0a 1c 90 28 eb 39 55 b0 2f 55 ba 33 b1 9b
7b 45 f6 be 20 33 13 fa 44 4f 57 4e 47 52 44 01
session_id[32]=
0d 07 2d cf c8 a3 90 27 22 70 6b 5c cf e0 1d 36
f1 6c af 88 59 5f 74 1a 9b 35 df e8 e6 f8 da 78
cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA
compressionMethod NULL
extensions
renegotiation_info
ja3s string: 771,53,65281
ja3s fingerprint: 7b6819ed58e8d8415604b7dfcef92d55
Certificate
ServerHelloDone
2 3 0.0136 (0.0007) C>S V3.3(262) Handshake
ClientKeyExchange
EncryptedPreMasterSecret[256]=
31 aa 1d a9 63 5c ff f8 29 0b 24 5d 7e ee 98 ff
cf 25 94 2f 55 5d 48 91 c1 67 c4 ea 39 71 7e ce
3c a6 a7 18 2c 3d f5 a4 07 1f 54 1e 01 82 b3 7b
46 fe 46 90 25 79 b2 46 5e 03 c3 4f df 81 89 d7
.
.
.
b5 e8 44 d5 cd 92 02 82 f3 42 27 56 5d 23 5b c1
9a e8 8e ec 4b 35 e8 4e 57 01 cb bc 61 09 66 c0
5c 8d 20 47 b4 da ef 2d 25 71 c8 7f 73 3b 47 7a
43 04 0b 6d 27 b3 c3 af 17 89 af d9 04 c1 66 a1
2 4 0.0136 (0.0000) C>S V3.3(1) ChangeCipherSpec
2 5 0.0136 (0.0000) C>S V3.3(64) Handshake
2 6 0.0165 (0.0029) S>C V3.3(1) ChangeCipherSpec
2 7 0.0565 (0.0400) S>C V3.3(64) Handshake
2 8 0.0567 (0.0002) C>S V3.3(96) application_data
2 9 0.0589 (0.0021) S>C V3.3(160) application_data
2 10 0.0591 (0.0002) C>S V3.3(96) application_data
2 11 0.0615 (0.0023) S>C V3.3(144) application_data
2 12 0.0617 (0.0001) C>S V3.3(528) application_data
2 13 0.1017 (0.0400) C>S V3.3(80) application_data
2 14 0.1042 (0.0025) S>C V3.3(1296) application_data
2 15 0.1116 (0.0074) C>S V3.3(288) application_data
2 16 0.1145 (0.0028) S>C V3.3(352) application_data
2 17 0.1179 (0.0034) C>S V3.3(64) application_data
2 18 0.1205 (0.0026) S>C V3.3(336) application_data
2 19 4.6999 (4.5793) C>S V3.3(1664) application_data
2 20 4.7183 (0.0184) S>C V3.3(1296) application_data
Cleaned 5 remaining connection(s) from connection pool
Notice in the above that there is no CertificateRequest, etc.
I did some additional "openssl s_client" connection tests, and it appears that there is no "list of acceptable CAs" sent by the server-side during the SSL handshake.
So I was wondering if: Would the above 2 pieces of information seem to imply that there was no 2-way SSL connection being established?
I'm running M-TIP MP92 Test 01 Scenario 01. The objective of the test is:
"To ensure that the terminal terminates the transaction when the card indicates that it does not support Contactless - M/Chip".
What I don't understand, is how a card indicates this. My terminal as it is right now is processing beyond the Get Processing Options step, which results in a failure from my testing tool. I've looked through the data being exchanged between the card and the tool up to that point, but I don't understand where this is.
Select (2PAY.SYS.DDF01)
Request : 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
Class :00
Ins :A4
P1 :04
P2 :00
Lc :0E
Data :32 50 41 59 2E 53 59 53 2E 44 44 46 30 31
Application: 2PAY.SYS.DDF01
Le :00
Response: 6F 23 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 11 BF 0C 0E 61 0C 4F 07 A0 00 00 00 04 30 60 87 01 01 90 00
Data : 6F 23 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 11 BF 0C 0E 61 0C 4F 07 A0 00 00 00 04 30 60 87 01 01
Tag 6F : File Control Information (FCI) Template
Tag 84 : Dedicated File (DF) Name : 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31
PPSE Directory File Name = 2PAY.SYS.DDF01
Tag A5 : File Control Information (FCI) Proprietary Template
Tag BF 0C: File Control Information (FCI) Issuer Discretionary Template
Tag 61 : Application Template
Tag 4F : Application Identifier (AID) : A0 00 00 00 04 30 60
Tag 87 : Application Priority Indicator : 01
Byte 1 bit 8 = 0 Application may be selected without confirmation of cardholder
bit 7-5= 000 RFU
bit 4-1= 0001 Order number in which the application is to be listed: 1
SW1 SW2 : 90 00 (SW_OK)
Select (Maestro)
Request : 00 A4 04 00 07 A0 00 00 00 04 30 60 00
Class :00
Ins :A4
P1 :04
P2 :00
Lc :07
Data :A0 00 00 00 04 30 60
Application: Maestro
Le :00
Response: 6F 2F 84 07 A0 00 00 00 04 30 60 A5 24 50 09 4D 50 39 32 20 76 32 20 32 BF 0C 16 5F 50 13 43 4F 4C 4C 49 53 5C 2A 2F 4D 50 39 32 5C 2A 2F 32 2E 32 90 00
Data : 6F 2F 84 07 A0 00 00 00 04 30 60 A5 24 50 09 4D 50 39 32 20 76 32 20 32 BF 0C 16 5F 50 13 43 4F 4C 4C 49 53 5C 2A 2F 4D 50 39 32 5C 2A 2F 32 2E 32
Tag 6F : File Control Information (FCI) Template
Tag 84 : Dedicated File (DF) Name : A0 00 00 00 04 30 60
Tag A5 : File Control Information (FCI) Proprietary Template
Tag 50 : Application Label : 4D 50 39 32 20 76 32 20 32
Text value = MP92 v2 2
Tag BF 0C: File Control Information (FCI) Issuer Discretionary Template
Tag 5F 50: Issuer URL : 43 4F 4C 4C 49 53 5C 2A 2F 4D 50 39 32 5C 2A 2F 32 2E 32
Text value = COLLIS\*/MP92\*/2.2
SW1 SW2 : 90 00 (SW_OK)
Get Processing Options
Request : 80 A8 00 00 02 83 00 00
Class :80
Ins :A8
P1 :00
P2 :00
Lc :02
Data :83 00
Le :00
MCHIP Card Unique Key Derivation Results
PAN: 67 99 99 89 00 00 00 60 92 7F
PAN Sequence Number: 01
Cryptogram Version No.: 10
ICC Master Key AC: 9E 15 20 43 13 F7 31 8A CB 79 B9 0B D9 86 AD 29
Derived Card Unique Key: 9D A1 13 AD 92 46 DC 04 85 92 3B 86 94 08 DC DF
ICC Master Key SMC: CE 29 3B 8C C1 2A 97 73 79 EF 25 6D 76 10 94 92
Derived Card Unique Key: 68 62 A7 40 F8 3E FE 97 E5 04 0D FB 10 85 46 CE
ICC Master Key SMI: 46 64 94 2F E6 15 FB 02 E5 D5 7F 29 2A A2 B3 B6
Derived Card Unique Key: 10 C4 F7 DF 68 75 B0 E5 EF 80 C7 AB 3B 80 9B F8
ICC Master Key IDN: 94 C5 3B 6B 15 07 7F CB E5 40 7F 43 B5 AB FB 80
Derived Card Unique Key: AB 51 29 16 AE 08 1A 25 DF 76 D0 3E EC 9E 6B 40
Response: 77 16 82 02 19 00 94 10 08 01 01 00 10 01 01 01 18 01 02 00 20 01 02 00 90 00
Data : 77 16 82 02 19 00 94 10 08 01 01 00 10 01 01 01 18 01 02 00 20 01 02 00
Tag 77 : Response Message Template Format 2
Tag 82 : Application Interchange Profile [M/Chip, PayPass] : 19 00
Byte 1 bit 8 = 0 RFU
bit 7 = 0 Offline static data authentication is NOT supported
bit 6 = 0 Offline dynamic data authentication is NOT supported
bit 5 = 1 Cardholder verification is supported
bit 4 = 1 Terminal risk management is to be performed
bit 3 = 0 Issuer authentication is supported using GENERATE AC command
bit 2 = 0 On device cardholder verification is NOT supported
bit 1 = 1 Combined DDA / GENERATE AC supported
Byte 2 bit 8 = 0 Only Mag Stripe profile supported [PayPass]
bit 7 = 0 RFU
bit 6 = 0 RFU
bit 5 = 0 RFU
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Tag 94 : Application File Locator (AFL) : 08 01 01 00 10 01 01 01 18 01 02 00 20 01 02 00
AFL (1) = 08 01 01 00
SFI (decimal) = 1
Start record = 1
End record = 1
Number of records needed
for offline data authentication = 0
AFL (2) = 10 01 01 01
SFI (decimal) = 2
Start record = 1
End record = 1
Number of records needed
for offline data authentication = 1
AFL (3) = 18 01 02 00
SFI (decimal) = 3
Start record = 1
End record = 2
Number of records needed
for offline data authentication = 0
AFL (4) = 20 01 02 00
SFI (decimal) = 4
Start record = 1
End record = 2
Number of records needed
for offline data authentication = 0
SW1 SW2 : 90 00 (SW_OK)
This Card Profile MP 92 due to AIP tag 0x82 Byte 2 Bit 8 - EMV Contactless NOT supported (i.e. Only Mag Stripe profile supported [PayPass] in your traces).
According to MasterCard rules, M/Chip Contactless-Magstripe should not be supported for Maestro cards in Europe.
This restriction should be indicated for Maestro Contactless RID/AID profile in Tag 0x9F1D Byte 3 Bit 8. Tag 0x9F1D Byte 3 should be 0x80 i.e Contactless-Mastripe not supported.
When you fix your Maestro terminal profile the Terminal Kernel should reject this Contactless card and ask to use Chip as expected by this test scenario.
I'm implementing RFC 5246(TLS 1.2), and I'm stuck at the certificate message.I'm debugging the server with a combination of Openssl s_client and Browsers.The server hello message is received and interpreted fine, and with -msg option in openssl I can see the message has been interpreted properly as Client_hello, without any errors.
When the certificate message is sent, the browser doesn't respond, and openssl s_client with -msg doesn't respond either. Openssl s_client with -debug reads the message but doesn't respond after the server_hello_done message. No errors are logged.
I suspect the problem is with the structure of my certificate message, because anything I send after the Record layer length gets received without any errors, even if it's just random text or binary data.
Modifying the structure of the record layer to incorrect/inappropriate values throws an error with the appropriate error message, for example setting the version to 9.3 throws the error
5256:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
as expected.
This is the structure I am currently using:
/Record layer/
One byte for the message type, two bytes for the protocol version(major and minor), and two bytes for the message length.
/Handshake message data/
Two bytes for the length, two bytes for the certificate(s) length.Finally the certificate(s).
I'm currently working with a self-signed certificate, and neither the browser nor openssl s_client include a signature_algorithms extension in the Client_hello, so I send the certificate as it is, in .PEM format, and in plain text.Below is openssl's hex dump of the handshake thus far:
CONNECTED(00000164)
write to 0x14ad698 [0x13f1ffb] (210 bytes => 210 (0xD2))
0000 - 16 03 01 00 cd 01 00 00-c9 03 01 53 5e 5c d6 a0 ...........S^\..
0010 - 34 27 ea 22 ed 01 dc 36-bb 0b 84 1e 5a 58 3e d5 4'."...6....ZX>.
0020 - 95 4d 5f 81 9f 2a f0 27-75 fb 1f 00 00 5c c0 14 .M_..*.'u....\..
0030 - c0 0a 00 39 00 38 00 88-00 87 c0 0f c0 05 00 35 ...9.8.........5
0040 - 00 84 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a ................
0050 - c0 13 c0 09 00 33 00 32-00 9a 00 99 00 45 00 44 .....3.2.....E.D
0060 - c0 0e c0 04 00 2f 00 96-00 41 00 07 c0 11 c0 07 ...../...A......
0070 - c0 0c c0 02 00 05 00 04-00 15 00 12 00 09 00 14 ................
0080 - 00 11 00 08 00 06 00 03-00 ff 01 00 00 44 00 0b .............D..
0090 - 00 04 03 00 01 02 00 0a-00 34 00 32 00 01 00 02 .........4.2....
00a0 - 00 03 00 04 00 05 00 06-00 07 00 08 00 09 00 0a ................
00b0 - 00 0b 00 0c 00 0d 00 0e-00 0f 00 10 00 11 00 12 ................
00c0 - 00 13 00 14 00 15 00 16-00 17 00 18 00 19 00 23 ...............#
00d2 - <SPACES/NULS>
read from 0x14ad698 [0x13edaab] (5 bytes => 5 (0x5))
0000 - 16 03 01 00 2c ....,
read from 0x14ad698 [0x13edab0] (44 bytes => 44 (0x2C))
0000 - 02 00 00 26 03 01 53 5e-5c d6 4a 5a 5b 4d 63 38 ...&..S^\.JZ[Mc8
0010 - 57 47 53 45 4d 5b 3f 3c-5f 38 23 67 26 32 38 4c WGSEM[?<_8#g&28L
0020 - 2e 67 47 67 28 56 00 00-2f .gGg(V../
002c - <SPACES/NULS>
read from 0x14ad698 [0x13edaab] (5 bytes => 5 (0x5))
0000 - 16 03 01 02 99 .....
read from 0x14ad698 [0x13edab0] (665 bytes => 665 (0x299))
0000 - 0b 02 96 02 94 2d 2d 2d-2d 2d 42 45 47 49 4e 20 .....-----BEGIN
0010 - 43 45 52 54 49 46 49 43-41 54 45 2d 2d 2d 2d 2d CERTIFICATE-----
0020 - 0a 4d 49 49 42 75 54 43-43 41 53 49 43 43 51 43 .MIIBuTCCASICCQC
0030 - 43 65 67 31 46 6f 4f 76-43 4b 6a 41 4e 42 67 6b Ceg1FoOvCKjANBgk
0040 - 71 68 6b 69 47 39 77 30-42 41 51 55 46 41 44 41 qhkiG9w0BAQUFADA
0050 - 68 4d 51 73 77 43 51 59-44 56 51 51 47 45 77 4a hMQswCQYDVQQGEwJ
0060 - 4c 0a 52 54 45 53 4d 42-41 47 41 31 55 45 41 78 L.RTESMBAGA1UEAx
0070 - 4d 4a 62 47 39 6a 59 57-78 6f 62 33 4e 30 4d 42 MJbG9jYWxob3N0MB
0080 - 34 58 44 54 45 30 4d 44-51 79 4d 54 45 32 4e 44 4XDTE0MDQyMTE2ND
0090 - 4d 30 4e 56 6f 58 44 54-45 31 4d 44 51 79 4d 54 M0NVoXDTE1MDQyMT
00a0 - 45 32 0a 4e 44 4d 30 4e-56 6f 77 49 54 45 4c 4d E2.NDM0NVowITELM
00b0 - 41 6b 47 41 31 55 45 42-68 4d 43 53 30 55 78 45 AkGA1UEBhMCS0UxE
00c0 - 6a 41 51 42 67 4e 56 42-41 4d 54 43 57 78 76 59 jAQBgNVBAMTCWxvY
00d0 - 32 46 73 61 47 39 7a 64-44 43 42 6e 7a 41 4e 42 2FsaG9zdDCBnzANB
00e0 - 67 6b 71 0a 68 6b 69 47-39 77 30 42 41 51 45 46 gkq.hkiG9w0BAQEF
00f0 - 41 41 4f 42 6a 51 41 77-67 59 6b 43 67 59 45 41 AAOBjQAwgYkCgYEA
0100 - 72 51 71 76 50 36 4c 35-41 71 31 31 67 76 38 2b rQqvP6L5Aq11gv8+
0110 - 2f 59 55 53 62 50 46 4b-34 66 51 71 30 74 42 79 /YUSbPFK4fQq0tBy
0120 - 36 53 39 6c 0a 78 6f 45-6d 50 47 79 52 49 7a 44 6S9l.xoEmPGyRIzD
0130 - 31 46 78 78 52 65 50 79-55 6a 69 78 63 39 66 41 1FxxRePyUjixc9fA
0140 - 59 6f 74 5a 31 53 71 71-2f 2b 37 77 69 52 2b 7a YotZ1Sqq/+7wiR+z
0150 - 33 46 6f 65 51 58 73 53-64 32 78 32 44 4b 63 62 3FoeQXsSd2x2DKcb
0160 - 73 62 64 62 76 0a 2f 73-49 2b 68 63 57 39 4c 5a sbdbv./sI+hcW9LZ
0170 - 48 4d 45 75 49 6a 4d 42-73 6f 6f 4d 52 6a 76 35 HMEuIjMBsooMRjv5
0180 - 79 78 79 50 67 38 33 35-34 66 46 6d 51 50 38 4a yxyPg8354fFmQP8J
0190 - 49 73 54 54 48 31 54 56-5a 4f 47 48 79 49 62 76 IsTTH1TVZOGHyIbv
01a0 - 6e 34 7a 36 35 6b 0a 48-63 62 75 4f 52 38 43 41 n4z65k.HcbuOR8CA
01b0 - 77 45 41 41 54 41 4e 42-67 6b 71 68 6b 69 47 39 wEAATANBgkqhkiG9
01c0 - 77 30 42 41 51 55 46 41-41 4f 42 67 51 41 72 73 w0BAQUFAAOBgQArs
01d0 - 36 62 74 6f 38 6b 76 67-6b 48 70 4d 56 50 42 42 6bto8kvgkHpMVPBB
01e0 - 50 62 4e 71 6d 2f 62 0a-4a 78 4a 34 4a 78 5a 72 PbNqm/b.JxJ4JxZr
01f0 - 51 4c 6b 6a 48 7a 39 34-44 75 57 7a 64 67 41 6a QLkjHz94DuWzdgAj
0200 - 56 2b 70 39 72 7a 65 76-37 56 65 57 44 49 5a 41 V+p9rzev7VeWDIZA
0210 - 78 39 6a 43 6b 65 39 59-51 4c 68 42 67 62 2b 7a x9jCke9YQLhBgb+z
0220 - 48 73 6d 30 39 70 50 43-0a 4c 4f 50 37 4b 67 4b Hsm09pPC.LOP7KgK
0230 - 42 78 6e 68 52 49 33 4f-43 48 41 39 6f 43 78 30 BxnhRI3OCHA9oCx0
0240 - 78 46 35 46 65 34 53 38-34 65 6b 30 5a 37 65 5a xF5Fe4S84ek0Z7eZ
0250 - 4c 55 63 7a 52 41 6f 55-57 50 42 65 70 32 6e 62 LUczRAoUWPBep2nb
0260 - 44 77 39 78 6c 6e 30 57-49 0a 53 33 72 6d 2f 47 Dw9xln0WI.S3rm/G
0270 - 4d 6d 6e 4e 73 78 75 74-68 69 63 41 3d 3d 0a 2d MmnNsxuthicA==.-
0280 - 2d 2d 2d 2d 45 4e 44 20-43 45 52 54 49 46 49 43 ----END CERTIFIC
0290 - 41 54 45 2d 2d 2d 2d 2d-0a ATE-----.
read from 0x14ad698 [0x13edaab] (5 bytes => 5 (0x5))
0000 - 0e 03 01 ...
0005 - <SPACES/NULS>
read from 0x14ad698 [0x13edaab] (5 bytes => -1 (0xFFFFFFFF))
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 724 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1398693078
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
PEM is certainly not the right format to send on the wire. You should send it in binary form (use a base-64 decoded version of this PEM content).
You'll also need to wrap this in other layers, since a certificate_list in the Certificate struct is expected.
If you want to learn a bit more about all this, it's probably worth looking at existing traffic produced by working implementations using Wireshark. Its SSL wiki page even has an existing capture file that you can use.
(You're also mentioning you want to implement TLS 1.2, but you're sending 03 01, which is for TLS 1.0, although this shouldn't matter very much at this stage of your implementation.)
I have an OTI Copni device and I need to install a .cap file to this Copni device. So I have JCOP tools with Eclipse and I try to upload and install. It then gives this the indicated error. I presume this is happening because of a failed authentication.
cm> /term "winscard:4|SCM Microsystems Inc. SDI011G Contactless Reader 0"
--Opening terminal
> /card -a a000000003000000 -c com.ibm.jc.CardManager
resetCard with timeout: 0 (ms)
--Waiting for card...
ATR=3B 88 80 01 00 73 C8 40 00 00 90 00 62 ;....s.#....b
ATR: T=0, T=1, Hist=0073C84000009000
=> 00 A4 04 00 08 A0 00 00 00 03 00 00 00 00 ..............
(21592 usec)
<= 6F 65 84 08 A0 00 00 00 03 00 00 00 A5 59 9F 65 oe...........Y.e
01 FF 9F 6E 06 47 91 20 17 3F 00 73 4A 06 07 2A ...n.G. .?.sJ..*
86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 FC 6B .H..k.`...*.H..k
02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B 03 64 ....c...*.H..k.d
0B 06 09 2A 86 48 86 FC 6B 04 02 15 65 0B 06 09 ...*.H..k...e...
2B 85 10 86 48 64 02 01 03 66 0C 06 0A 2B 06 01 +...Hd...f...+..
04 01 2A 02 6E 01 02 90 00 ..*.n....
Status: No Error
cm> set-key 255/1/DES-ECB/404142434445464748494a4b4c4d4e4f 255/2/DES-ECB/404142434445464748494a4b4c4d4e4f 255/3/DES-ECB/404142434445464748494a4b4c4d4e4f
cm> init-update 255
=> 80 50 00 00 08 C2 3F 4B C4 BE B6 E5 58 00 .P....?K....X.
(43622 usec)
<= 00 00 32 98 00 09 30 97 06 25 01 02 00 10 68 6C ..2...0..%....hl
E3 CA 2C 2B 4D 2C 4B 0D 0E 62 5F 8C 90 00 ..,+M,K..b_...
Status: No Error
cm> ext-auth plain
=> 84 82 00 00 10 EB FC 66 BC FA 30 91 58 5B 51 FA .......f..0.X[Q.
0C 46 D7 43 C9 .F.C.
(12557 usec)
<= 69 85 i.
Status: Conditions of use not satisfied
jcshell: Error code: 6985 (Conditions of use not satisfied)
jcshell: Wrong response APDU: 6985
Unexpected error; aborting execution
Can someone tell me how to upload a .cap file to this device?
Try ext-auth mac instead, the smart card is probably in the state OP_SECURE, which means that at minimal command MAC is required.
As JCOP tools is not publicly available nor open source, I'd suggest you try a publicly available piece of software instead:
https://github.com/martinpaljak/GlobalPlatform#globalplatform-from-openkms
(as the name of the github repository implies this is self-promotion)
I capture packets sent/received by Win Xp machine when connecting to SQL Server 2005 Express using TLS encryption.
Server and Client exchange Hello messages
Server and Client send ChangeCipherSpec message
Then Server and Client server send strange message that is not described in TLS protocol
What is the message?
Server side capture:
16 **SSL Handshake**
03 01
00 4a
02 ServerHello
00 00 46
03 01
4b dd 68 59 GMT
33 13 37 98 10 5d 57 9d ff 71 70 dc d6 6f 9e 2c Random[00..13]
cb 96 c0 2e b3 2f 9b 74 67 05 cc 96 Random[14..27]
20 72 26 00 00 0f db 7f d9 b0 51 c2 4f cd 81 4c Session ID
3f e3 d2 d1 da 55 c0 fe 9b 56 b7 6f 70 86 fe bb Session ID
54 Session ID
00 04 Cipher Suite
00 Compression
14 03 01 00 01 01 **ChangeCipherSpec**
16 03 01 ???? Finished ???
00 20 d0 da cc c4 36 11 43 ff 22 25 8a e1 38 2b ???? ???
71 ce f3 59 9e 35 b0 be b2 4b 1d c5 21 21 ce 41 ???? ???
8e 24
16 03 01
00 20 d0 da cc c4 36 11 43 ff 22 25 8a e1 38 2b
71 ce f3 59 9e 35 b0 be b2 4b 1d c5 21 21 ce 41
8e 24
This message is already encrypted, therefore to see
14 03 01 00 00 0c
it needs to be decrypted first