Well, although you seem to have fixed the problem let me address your questions one by one so you can figure where you took the wrong turn:
I didn't try to make it work with AdoptOpenJDK-11,
Well, as mentioned: The example makes use of internal classes not part of the public SE API - hence it does matter what compiler and runtime is used. As this example is within the AdoptOpenJDK-11 repo it's meant to be used with the AdoptOpenJDK-11 compiler and runtime. If you try to use ANY other environment it's pretty much doomed to fail or produce some different output than what's expected.
[...] about Wireshark [...] so even if the certificateStatusMessage packet was lost [...]
IF some packet was lost TLS demands the connection to be terminated right away with a SSL_ERROR as one of the key features is not just encryption but also authenticity: Each packet goes through a continuous hash to ensure that both sides send and receive the same byte-stream. If one side detects a mismatch it has to terminate the connection right away with just a general error. So, it's not about "losing some packets" or "not correctly capturing them" - as if this would be caused by packet drop the connection wouldn't get to the CHANGE_CIPHER_SUITE message but would be terminated way before reaching that part of the handshake.
Running AdoptOpenjdk 11 did not work.
Please post code and error messages as text, not images. And if you do use images please use the attachment function of this forum instead of linking in from external sources. Reason: Image-Hosters such as Imgur are only host the content for a limited amount of time. They get delted pretty fast and all we end up with are broken links. Please don't do that. If there really is something you can't get as a text-only output use this sites attachement function to upload your images right to this thread. I tried my best to "translate" your images into text ...
Someone knows how to get the hole sun.security package downloaded??
Should I compile openjdk myself?
You don't "download a whole package", and surely no internal stuff. It's part of the environment this code was written for. In order to have access to it you have to use the same environment: an AdoptOpenJDK-11 package
// followed by some wireshark packet capture, followed by some packet analysis, followed by some more deeper analysis
TLDR: As the one comment on SO already mentioned: These screenshots only show "wireshark thinks there's something wrong according to its own standards" - but for the actual question they contain no value at all. Instead of using those cut down shots the short command like mine has the same information value: ZERO
note: this could had been done by some openssl textoutput (see example below)
And from here on it's just text again. So, end of "transcribing images to text" by me.
Let me address a few important key aspects here:
! RFC 3280 ! - although it's updated by some newer ones - THIS is the RFC to build your CA by ... it lists what extensions has to be part of a X.509v3 CA and cert chain and what values they should contain - Section 4.2 starting lower half of page 24.
And make sure too that your ssl certificate is chained with the CA or CA and intermediate certificates, depending how your setup is.
THIS line is not fully correct. A ROOT CA is NEVER bundled with anything - as it HAS to be in the clients TrustStore for the connection to actually work. If, for some reason, your setup is that simple to not include an intermediate level all you send is your sole certificate. The ROOT CA cert is NOT sent along with it.
One only sends additional certs along if and only if there's at least one or maybe even more intermediate certificates between the end entity cert and the root ca cert.
As an example: Using a Let's encrypt cert you have the chain: LE ROOT > LE intermediate > your cert
- the chain the server sends to the client only consists of your cert + the intermediate cert - but not the root cert as this has to be already in the clients trust store. In fact, test sites like ssllabs.com mark it as error if they detect the root cert is sent along and give a warning regarding fixing it.
So, the correct answer would be: Send along any intermediate certs if there're any - otherwise if the end entity cert is directly one level down from the root cert don't send the root cert along.
So, you see: Aside from the rather complicated example code specific to the AdoptOpenJdk-11 environment your cert chain was messed up. That's the reason why I suggested to try and test the provided original example as is - as if this would contain any error it would most like be fixed already by now.
example how to use openssl x509
to get a text output of your certificate: