EJB remoting issue in WildFly 16 - wildfly

When I connect from client java application to wildFly remote ejb over SSL, getting this error.
The client connects to EJB via remoting. The remoting in WildFly is configured with SSLRealm and the HTTPS listener also set with SSLRealm.
The same worked with WF 8.2 and this issue seen after migrating to WF-16.
SSL debug log:
%% No cached client session update handshake state: client_hello[1]
upcoming handshake states: server_hello[2]
* ClientHello, TLSv1.2 RandomCookie: GMT: 1583221271 bytes = { 169, 19, 89, 86, 88, 131, 155, 237, 237, 142, 227, 16, 104, 162, 145, 10,
46, 109, 215, 68, 16, 53, 154, 91, 112, 216, 168, 160 } Session ID:
{} Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, secp384r1,
secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1,
sect571r1, secp256k1} Extension ec_point_formats, formats:
[uncompressed] Extension signature_algorithms, signature_algorithms:
SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA,
SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA224withECDSA,
SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
Extension extended_master_secret
XNIO-1 I/O-1, WRITE: TLSv1.2 Handshake, length = 199 XNIO-1 I/O-1, READ: TLSv1.2 Handshake, length = 1035 check handshake state:
server_hello[2]
ServerHello, TLSv1.2 RandomCookie: GMT: 1583221271 bytes = { 107, 141, 20, 188, 78, 97, 175, 228, 80, 217, 148, 35, 196, 141, 120, 88,
110, 219, 94, 135, 8, 172, 103, 78, 85, 107, 177, 129 } Session ID:
{94, 94, 10, 23, 107, 225, 45, 207, 234, 219, 71, 87, 112, 37, 218,
175, 226, 249, 235, 229, 43, 149, 49, 236, 27, 116, 133, 118, 174, 68,
89, 148} Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Compression Method: 0 Extension renegotiation_info,
renegotiated_connection: Extension extended_master_secret
* %% Initialized: [Session-3, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384]
** TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 update handshake state: server_hello[2] upcoming handshake states: server certificate[11]
upcoming handshake states: server_key_exchange12 upcoming
handshake states: certificate_request13 upcoming handshake
states: server_hello_done[14] upcoming handshake states: client
certificate11 upcoming handshake states:
client_key_exchange[16] upcoming handshake states:
certificate_verify15 upcoming handshake states: client
change_cipher_spec[-1] upcoming handshake states: client finished[20]
upcoming handshake states: server change_cipher_spec[-1] upcoming
handshake states: server finished[20] check handshake state:
certificate[11] update handshake state: certificate[11] upcoming
handshake states: server_key_exchange12 upcoming handshake
states: certificate_request13 upcoming handshake states:
server_hello_done[14] upcoming handshake states: client
certificate11 upcoming handshake states:
client_key_exchange[16] upcoming handshake states:
certificate_verify15 upcoming handshake states: client
change_cipher_spec[-1] upcoming handshake states: client finished[20]
upcoming handshake states: server change_cipher_spec[-1] upcoming
handshake states: server finished[20]
*** Certificate chain chain [0] = [ [ Version: V3 Subject: EMAILADDRESS=app-webserver#appdev.com, CN=app-webserver-commonName,
OU=app Demo, O=app cert, ST=CA, C=US Signature Algorithm:
SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 1024 bits modulus:
10594925822321141887721258456061864128740466833580453489554475888747706649063995418909414161
public exponent: 65537 Validity: [From: Sat Feb 14 05:00:36 IST
2009,
To: Tue Oct 23 06:47:16 IST 2040] Issuer: EMAILADDRESS=app-webserver#appdev.com, CN=app-webserver-commonName,
OU=app Demo, O=app cert, ST=CA, C=US SerialNumber: [ 7cd0a83e
8bdfd29d]
] Algorithm: [SHA1withRSA] Signature: 0060: 2A 78 FB 9B 2E EA 22
F5 A9 42 04 72 E3 45 4F 76 *x...."..B.r.EOv 0070: D9 38 F2 54 57 FA
AE 5F 42 CA FE 8C 5E 05 3E CE .8.TW.._B...^.>.
]
XNIO-1 I/O-1, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
%% Invalidated: [Session-1, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384]
XNIO-1 I/O-1, SEND TLSv1.2 ALERT: fatal, description = certificate_unknown
XNIO-1 I/O-1, WRITE: TLSv1.2 Alert, length = 2
XNIO-1 I/O-1, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: General SSLEngine problem
XNIO-1 I/O-1, called closeOutbound()
XNIO-1 I/O-1, closeOutboundInternal()
org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:592)
Any idea?

It looks like you are not using a valid certificate. Do you get a warning about the cert if you goto the server in your browser?
If you can't use a cert issued from a proper CA, then you will need to use a truststore with your client

Related

Decrypting secure string with aes key

So I was given a key and a hash to decrypt with PowerShell.
key: (165, 49, 50, 151, 4, 58, 80, 217, 250, 19, 249, 150, 185, 102, 202, 113)
hash:
76492d1116743f0423413b16050a5345MgB8AEsAVQBkAGkAWQBQAGYAcgA2ADQASwBCAGQ
AcwBkAFEATQByAFQATABqAFEAPQA9AHwAOQBkAGQAYQA2AGQAYgA4ADQAZQBmAGUAMgBiADQ
ANgA1ADkANAA5AGYAMQBlADIAYgA5ADIAMQBmADUANgA0ADgANgBiADYANwBmAGMANgBjADAA
ZgA5AGUAZQAxAGQANgA3ADUANwA3ADUAZgA1AGYAOABlADcAOQA0AGMAOQA4ADMAZgBmADQ
AMQBkADcAYgAyADkAZQBhADEANwA2AGEAMQBhADMAZQBiADEAOQBkAGMANABiAGIANQBhAGM
AOQA0ADQAMwBhADAAZQAzAGQAZQAwADIANwA2ADUANwAzADcAMABhAGMAMwAxAGYAYwBjA
DYANAA5ADYAZgBlAGQANAA3ADIAMAA2AGUAOQA0ADEAMQA2ADEAYgA2ADMAYgAwADUANQA1A
GQAYQBiADQAOABkAGMANQAyADUAZABkADIANQA5AGQANQA3ADIANgA4ADUAYQA3ADcAMgAxAD
AAOQA2AGUAYQA4ADUAZQAyADgAZABhADMANABlADkANwA0ADIAZQBiADMAMwAzADMAMwAwA
DIAZAA4ADIAYgAwADkAZgBjADUAMgA4AGQANQBkADUAOQA0ADgAMwA4ADEAYgBmAGIAMwBjAGU
AYQAyADUAZgA3ADgAOQA0AGUAZABiAGMAYgBkADcANQAyADQAOQA0ADkANwAxADgAOQAxAGMA
ZAA5ADcAMQA2AGQAOABjAGQAOQAyAGIANQA0AGUAZgAzADcANwA0ADkAOQAxAGIANQA2AGUANw
AyADIAMAA5ADcAOQA3ADIANwAyADAAZgAyAGUAMgA2AGQAMwA1ADMAMAA1AGUAYwAxADcAYw
A2AGQAMwA2AGQAZQBjADgANwAyADYAYwBkADgANQA5AGYANwAwAGUAMQA3AGUANwBkADIAMQ
A4ADgANAA2ADIANAAwAGIANAA5ADgAMwBiADMAOAA1ADUAYgBiAGUAMABhAGIANgAxAGEAMwB
mADYAYQA5ADUANQBmAGUAZQAyADAAZQBhADAAZQAxADUAOAAxAGIAZQA1ADMAMAA5AGUAYQ
BiADkANwAwAGQAMQBmAGQAYgAxAGIANQA0ADAAYwAwADMAOQA5ADcANQA1ADcAOABjADUANg
AyADAAMAA2ADEAZAAyAGQAYgA0ADYAZAA2AGUAOABhADUANQA4ADgAYQA0AGMAZgAwADQANwB
lAGMAZABiAGQAYgBjADQANwA1AGQAYQA2ADQAYgA4ADcAMAAzADIAMgBhADIAZgA1ADAANgA4AGU
AYwBlADgAMgA4AGEAMwAzAGYAMAAzADkANQBlADkAMgBkADIAMgA1ADAAOAA4AGIAOQA3AGUAYg
AzADIAZQA3ADMAMQA4AA==
My code:
$Key = (165, 49, 50, 151, 4, 58, 80, 217, 250, 19, 249, 150, 185, 102, 202, 113)
ConvertFrom-SecureString (ConvertTo-SecureString
"abovehash" -AsPlainText -Force) -Key $Key
My theory is that it is already a secure string but to flip it to plaintext I would need to convertto and convertfrom to translate it. I used a website which decoded it perfectly
https://www.wietzebeukema.nl/powershell-securestring-decoder/#
I get the hash re-hashed again.
I know how to make my own secure key and decrypt it but how would you decrypt a hash if you were given the hash and the key.
I remember trying to do this 4 or 5 years ago to store random stuff in it. What I found out is for some reason the ConvertFrom-SecureString never worked. After some reasearch I found out converting to BTSR using the System.Runtime.InteropServices.Marshal SecureStringtoBTSR from a SecureString and then using the PtrToStringAuto will decrypt it properly. I will try to locate the reasoning and post it. But this should work and provide you the message you want:
$Key = (165, 49, 50, 151, 4, 58, 80, 217, 250, 19, 249, 150, 185, 102, 202, 113)
$hash = "76492d1116743f0423413b16050a5345MgB8AEsAVQBkAGkAWQBQAGYAcgA2ADQASwBCAGQAcwBkAFEATQByAFQATABqAFEAPQA9AHwAOQBkAGQAYQA2AGQAYgA4ADQAZQBmAGUAMgBiADQANgA1ADkANAA5AGYAMQBlADIAYgA5ADIAMQBmADUANgA0ADgANgBiADYANwBmAGMANgBjADAAZgA5AGUAZQAxAGQANgA3ADUANwA3ADUAZgA1AGYAOABlADcAOQA0AGMAOQA4ADMAZgBmADQAMQBkADcAYgAyADkAZQBhADEANwA2AGEAMQBhADMAZQBiADEAOQBkAGMANABiAGIANQBhAGMAOQA0ADQAMwBhADAAZQAzAGQAZQAwADIANwA2ADUANwAzADcAMABhAGMAMwAxAGYAYwBjADYANAA5ADYAZgBlAGQANAA3ADIAMAA2AGUAOQA0ADEAMQA2ADEAYgA2ADMAYgAwADUANQA1AGQAYQBiADQAOABkAGMANQAyADUAZABkADIANQA5AGQANQA3ADIANgA4ADUAYQA3ADcAMgAxADAAOQA2AGUAYQA4ADUAZQAyADgAZABhADMANABlADkANwA0ADIAZQBiADMAMwAzADMAMwAwADIAZAA4ADIAYgAwADkAZgBjADUAMgA4AGQANQBkADUAOQA0ADgAMwA4ADEAYgBmAGIAMwBjAGUAYQAyADUAZgA3ADgAOQA0AGUAZABiAGMAYgBkADcANQAyADQAOQA0ADkANwAxADgAOQAxAGMAZAA5ADcAMQA2AGQAOABjAGQAOQAyAGIANQA0AGUAZgAzADcANwA0ADkAOQAxAGIANQA2AGUANwAyADIAMAA5ADcAOQA3ADIANwAyADAAZgAyAGUAMgA2AGQAMwA1ADMAMAA1AGUAYwAxADcAYwA2AGQAMwA2AGQAZQBjADgANwAyADYAYwBkADgANQA5AGYANwAwAGUAMQA3AGUANwBkADIAMQA4ADgANAA2ADIANAAwAGIANAA5ADgAMwBiADMAOAA1ADUAYgBiAGUAMABhAGIANgAxAGEAMwBmADYAYQA5ADUANQBmAGUAZQAyADAAZQBhADAAZQAxADUAOAAxAGIAZQA1ADMAMAA5AGUAYQBiADkANwAwAGQAMQBmAGQAYgAxAGIANQA0ADAAYwAwADMAOQA5ADcANQA1ADcAOABjADUANgAyADAAMAA2ADEAZAAyAGQAYgA0ADYAZAA2AGUAOABhADUANQA4ADgAYQA0AGMAZgAwADQANwBlAGMAZABiAGQAYgBjADQANwA1AGQAYQA2ADQAYgA4ADcAMAAzADIAMgBhADIAZgA1ADAANgA4AGUAYwBlADgAMgA4AGEAMwAzAGYAMAAzADkANQBlADkAMgBkADIAMgA1ADAAOAA4AGIAOQA3AGUAYgAzADIAZQA3ADMAMQA4AA=="
$Secured = $hash | ConvertTo-SecureString -key $key
$BTSR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($Secured)
[System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BTSR)
And of course in pure Microsoft fashion the explanation article is no longer where it used to be. Once I have the context reasoning I will update.
Update
Here is an SO Answer giving some context to it: Are you able to use PtrToStringAuto to decrypt a secure string in Powershell 7 on macOS?

How can I convert a compressed .gz file that I'm getting from a bluetooth Low-energy device to an actual decompressed file in Swift 4.2, using gzip?

I am very new to Xcode and iOS, I have a device, let's call it Brains, that I'm connecting to via Bluetooth LE using an app I built with Swift 4 and Xcode 10 on my iPhone 5, call it Body. Brains is similar to an arduino board, but not exactly. I can connect and get all the data with BLE with no problems, until I tried to get a compressed file filled with json strings.
I am receiving the compressed bytes but I can't seem to know what to do next. How can I get the compressed file, decompress it and read the data inside?
I have tried many things from using the Modules: GzipSwift,
DataCompression and SSZipArchive
I have used gunzipped(), gunzip() and decompress() but none of them seem to work.
I have read this thread: iOS :: How to decompress .gz file using GZIP Utility? and it say that I have to get all the compressed bytes stream and convert that to NSData and then decompress it, trouble is he's Using objective-c and I cant seem to translate into swift 4.
I'm getting the bytes from the Bluetooth LE characteristic in a [UInt8] array, in this function:
func received_logs(data: [UInt8]) {
let data_array_example = [31, 139, 8, 8, 16, 225, 156, 92, 2, 255, 68, 97, 116, 97, 0, 181, 157, 107, 110, 220, 56, 16, 6, 175, 226, 3, 248, 71, 63, 73, 234, 44, 193, 222, 255, 26, 171, 30, 35, 192, 90, 20, 18, 121, 182, 11, 112, 16, 35, 48, 10, 31, 154, 197, 22, 135, 34, 227, 95, 191, 76, 244, 16, 183, 248, 252, 48, 137, 229, 38, 242, 249, 161, 231, 87, 156, 127, 207, 113, 126, 227, 159, 31, 231, 183, 110, 223, 255, 200, 239, 47, 203, 252, 253, 173, 255, 231, 159, 235, 235, 108, 105, 110, 101, 48, 47, 50, 48]
for data_byte in stride(from: 0, to: data_array_example.count, by: 1) {
let byte = String(data_array_example[data_byte])
sourceString = sourceString + byte //getting all the bytes and converting to string to store in a variable
}
/******************************************************************/
let text = sourceBuffer
do {
try text.write(to: path!, atomically: false, encoding: String.Encoding.utf8)
}
catch {
print("Failed writing")
} //dump the var into a txt file
/**********UPDATED**********/
var file_array : [UInt8] = []
let byte2 = NSData(data: data_array_example.data)
let asc_array = Data(bytes: byte2.data)
let decompressedData: Data
do {
try decompressedData = asc.gunzipped()
print("Decom: ", String(data: decompressedData, encoding: .utf8))
}
catch {
print(error) //Gives me the "unknown compression method error"
}
}
I expect to see the Uncompressed file's contents but I only get:
GzipError(kind: Gzip.GzipError.Kind.data, message: "incorrect header check")
Maybe I'm just making it more complicated than It needs to be. Any help would be greatly appreciated!
Thank you very much :)
UPDATE:
I created a .gz file and used the both the gunzipped() and gunzip() functions and both of them worked.
UPDATE:
Tried to directly convert the data to NSData and then gunzip() but now getting the error:
GzipError(kind: Gzip.GzipError.Kind.data, message: "unknown compression method")
The updated example data has a correct gzip header, and so would not be giving you an incorrect header check if you are feeding the data correctly to the gunzipper.
I solve my issue. Turns out I was miscounting the bytes and some of them were in the wrong order. Thank you guys for your help!

ZXing truncading negative bytes

In ZXing i'm creating a string of a binary data using the encode "ISO-8859-1"
but somehow negative bytes in the data get truncated to byte 63 when reading the produced QR code
Example: String before QR code (as bytes)
-78, 99, -86, 15, -123, 31, -11, -64, 77, -91, 26, -126, -68, 33
String read from QR code:
63, 99, 63, 15, 63, 31, 63, 63, 77, 63, 26, 63, 63, 33
How do I prevent that without using base64?
For some reason ZXing assembles the QR matrix with the correct data, it's the reading that truncates the bytes. I ended up sidestepping the problem by encoding my binary data to base64 and dealing with the increased message size

How can I read an hex number with dlmread?

I'm trying to read a .csv file with Octave (I suppose it's equivalent on Matlab). One of the columns contains hexadecimal values identifying MAC addresses, but I'd like to have it parsed anyway, I don't mind if it's converted to decimal.
Is it possible to do this automatically with functions such as dlmread? Or do I have to create a custom function?
This is how the file looks like:
Timestamp, MAC, LastBsn, PRR, RSSI, ED, SQI, RxGain, PtxCoord, Channel: 26
759, 0x35c8cc, 127, 99, -307, 29, 237, 200, -32
834, 0x32d710, 183, 100, -300, 55, 248, 200, -32
901, 0x35c8cc, 227, 100, -300, 29, 238, 200, -32
979, 0x32d6a0, 22, 95, -336, 10, 171, 200, -32
987, 0x32d710, 27, 96, -328, 54, 249, 200, -32
1054, 0x35c8cc, 71, 92, -357, 30, 239, 200, -32
1133, 0x32d6a0, 122, 95, -336, 11, 188, 200, -32
I can accept any output value for the (truncated) MAC addresses, from sequence numbers (1-6) to decimal conversion of the value (e.g. 0x35c8cc -> 3524812).
My current workaround is to use a text editor to manually replace the MAC addresses with decimal numbers, but an automated solution would be handy.
The functions dlmread and csvread will handle numeric files. You can use textscan (which is also present in Matlab), but since you're using Octave, you're better off using csv2cell (part of Octave's io package). It basically reads a csv file and returns a cell array of strings and doubles:
octave-3.8.1> type test.csv
1,2,3,"some",1c:6f:65:90:6b:13
4,5,6,"text",0d:5a:89:46:5c:70
octave-3.8.1> plg load io; # csv2cell is part of the io package
octave-3.8.1> data = csv2cell ("test.csv")
data =
{
[1,1] = 1
[2,1] = 4
[1,2] = 2
[2,2] = 5
[1,3] = 3
[2,3] = 6
[1,4] = some
[2,4] = text
[1,5] = 1c:6f:65:90:6b:13
[2,5] = 0d:5a:89:46:5c:70
}
octave-3.8.1> class (data{1})
ans = double
octave-3.8.1> class (data{9})
ans = char
>> type mycsv.csv
Timestamp, MAC, LastBsn, PRR, RSSI, ED, SQI, RxGain, PtxCoord, Channel: 26
759, 0x35c8cc, 127, 99, -307, 29, 237, 200, -32
834, 0x32d710, 183, 100, -300, 55, 248, 200, -32
901, 0x35c8cc, 227, 100, -300, 29, 238, 200, -32
979, 0x32d6a0, 22, 95, -336, 10, 171, 200, -32
987, 0x32d710, 27, 96, -328, 54, 249, 200, -32
1054, 0x35c8cc, 71, 92, -357, 30, 239, 200, -32
1133, 0x32d6a0, 122, 95, -336, 11, 188, 200, -32
You can read the file with csv2cell. The values starting with "0x" will be automatically converted from hex to decimal values. See:
>> pkg load io % load io package for csv2cell
>> data = csv2cell ("mycsv.csv");
>> data(2,1)
ans =
{
[1,1] = 759
}
To access the cell values use:
>> data{2,1}
ans = 759
>> data{2,2}
ans = 3524812
>> data{2,5}
ans = -307

how to prove that one certificate is issuer of another certificates

I have two certificate. One certificate is issuer of another certificate.
how can I see with java code that, my issuer certificate is really issuer?
I know that AuthorityKeyIdentifier of my certificate and SubjectKeyIdentifie of issuer certifiactes must be the same. I checked and they are the same.
but with java code I have that result:
CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
InputStream usrCertificateIn = new FileInputStream("/usr.cer");
X509Certificate cert = (X509Certificate) certFactory.generateCertificate(usrCertificateIn);
InputStream SiningCACertificateIn = new FileInputStream("/siningCA.cer");
X509Certificate issuer = (X509Certificate) certFactory.generateCertificate(SiningCACertificateIn);
byte[] octets = (ASN1OctetString.getInstance(cert.getExtensionValue("2.5.29.35")).getOctets());
System.out.println(Arrays.toString(octets) + " bouncycastle, AuthorityKeyIdentifier");
System.out.println(Arrays.toString(cert.getExtensionValue("2.5.29.35")) + "java.security, AuthorityKeyIdentifier");
octets = ASN1OctetString.getInstance(issuer.getExtensionValue("2.5.29.14")).getOctets();
System.out.println((Arrays.toString(octets) + "bouncycastle, SubjectKeyIdentifie "));
System.out.println(Arrays.toString(issuer.getExtensionValue("2.5.29.14")) + "java.security, SubjectKeyIdentifie ");
adn the result is that:
[48, 22, -128, 20, 52, -105, 49, -70, -24, 78, 127, -113, -25, 55, 39, 99, 46, 6, 31, 66, -55, -86, -79, 113] bouncycastle, AuthorityKeyIdentifier
[4, 24, 48, 22, -128, 20, 52, -105, 49, -70, -24, 78, 127, -113, -25, 55, 39, 99, 46, 6, 31, 66, -55, -86, -79, 113]java.security, AuthorityKeyIdentifier
and another byte array that MUST BE THE SAME, BUT IT IS NOT another bytes is added at the beginning of the array.
[4, 20, 52, -105, 49, -70, -24, 78, 127, -113, -25, 55, 39, 99, 46, 6, 31, 66, -55, -86, -79, 113]bouncycastle, SubjectKeyIdentifie
[4, 22, 4, 20, 52, -105, 49, -70, -24, 78, 127, -113, -25, 55, 39, 99, 46, 6, 31, 66, -55, -86, -79, 113]java.security, SubjectKeyIdentifie
question 1)
Can I calculates the key Identifiers to get the same Arrays?
question 2)
is there another way in order to prove that one certificate is issuer of another certificates.
AuthorityKeyIdentifier and SubjectKeyIdentifier are defined differently:
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
SubjectKeyIdentifier ::= KeyIdentifier
KeyIdentifier ::= OCTET STRING
(sections 4.2.1.1 and 4.2.1.2 of RFC 5280)
Thus, merely comparing the extension values cannot work, instead you have to extract the KeyIdentifier contents and compare them, e.g. using BouncyCastle ASN.1 helper classes.
BTW, the actual key identifier bytes are only
52, -105, 49, -70, -24, 78, 127, -113, -25, 55, 39, 99, 46, 6, 31, 66, -55, -86, -79, 113
The 4, 20 before that indicates an OCTET STRING, 20 bytes long. In the AuthorityKeyIdentifier the 4 is replaced by the tag [0] (byte -128) due to implicit tagging.
The 48, 22 before that in your AuthorityKeyIdentifier means (constructed) SEQUENCE, 22 bytes long.
Etc. etc.
Thus,
Can I calculates the key Identifiers to get the same Arrays?
Yes, drill down to the actual KeyIdentifier OCTET STRING values.
is there another way in order to prove that one certificate is issuer of another certificates
Well, you can check whether the signature in the certificate is signed by the private key associated with the assumed issuer certificate by verifying against that certificate's public key.
PS: Concerning the question in the comments
is key identifier's length always 20? is it fixed? may be no, is not it?
No, it is not. The before mentioned RFC 5280 says:
For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common
methods for generating key identifiers from the public key are:
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits).
(2) The keyIdentifier is composed of a four-bit type field with
the value 0100 followed by the least significant 60 bits of
the SHA-1 hash of the value of the BIT STRING
subjectPublicKey (excluding the tag, length, and number of
unused bits).
Other methods of generating unique numbers are also acceptable.
I assume your CA uses method 1 (160 bit = 20 bytes) but this is merely a common method, not even something explicitly recommended, let alone required. Thus, no, you cannot count on the identifier being 20 bytes long.
PPS: Concerning the question in the comments
Isn't the signature the only way to truly prove one cert is issued by another?
That is no prove of the issuer-issuedBy relation either, it merely proves (at least to a certain degree) that the private key associated with the assumed issuer certificate signed the inspected certificate but there are situations where the same private-public key pair is used in multiple certificates.
In essence you need to do multiple complementary test and even then have to trust the CA not to do weird stuff. Not long ago e.g. the Swisscom changed one of their CA certificates to include an additional extension or critical attribute (I'd have to look up the details; I think someone certifying them demanded that change), and by the certificate signature verification test old signer certificates now seem to be issued by the new CA certificate even though the owners of the signer certificates might not be aware of that new extension/critical attribute.
So eventually real life simply is not as simple as one would like it to be...
To prove one certificate was issued by another, you should prove it was signed by the private key corresponding to the public key in the issuing certificate.
Let's call 2 certificates caCert and issuedCert. These are of type X509Certificate.
The Java code to prove issuedCert is signed by the entity represented by caCert is quite simple.
PublicKey caPubKey = caCert.getPublicKey();
issuedCert.verify(caPubKey);
If the verify method returns without throwing an exception, then issuedCert was signed by the private key corresponding to the public key in caCert.