READ: TLSv1.2 handshake, length = 2660 READ: TLSv1.2 handshake, length = 2660Fatal (HANDSHAKE_FAILURE): Received fatal alert: handshake_failure
Consuming ServerHello handshake message (
There was a problem at the server end. Go and find what the problem was."ServerHello" message content
"ServerHello": { "server version" : "TLSv1.2", "random" : "60 07 18 3D 36 24 8E 9F 17 CD 0F 2F 20 1A 50 3E A0 08 BA 4A 9B 70 14 88 9A 25 FF F0 AF 47 62 C3", "session id" : "60 07 18 3D 5E 82 93 3D 3E B5 5B E2 74 39 9C 8E 4E C1 CD 07 7B C2 B9 F3 B0 7F 58 AD 0C 37 3A B3", "cipher suite" : "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030)", "compression methods" : "00", "extensions" : [ "renegotiation_info (65,281)": { "renegotiated connection": [] }, "ec_point_formats (11)": { "formats": [uncompressed] }, "extended_master_secret (23)": { <empty> } }Fatal (PROTOCOL_VERSION): The server selected protocol version TLS10 is not accepted by client preferences [TLS12] See here.
End of the "serverHello" messageDisplay what attributes/extensions were sent/not sent in the message
Ignore... means it was not in the message Ignore unavailable extension: supported_versions Negotiated protocol version: TLSv1.2 Consume... means it was present in the message Consumed extension: renegotiation_info Ignore unavailable extension: server_name Ignore unavailable extension: max_fragment_length Ignore unavailable extension: status_request Consumed extension: ec_point_formats Ignore unavailable extension: status_request_v2 Consumed extension: extended_master_secret Consumed extension: renegotiation_info Session initialized: Session(1611077669542 Ignore unavailable extension: server_name Ignore unavailable extension: max_fragment_length Ignore unavailable extension: status_request Ignore impact of unsupported extension: ec_point_formats Ignore unavailable extension: application_layer_protocol_negotiation Ignore unavailable extension: status_request_v2 Ignore impact of unsupported extension: extended_master_secret Ignore impact of unsupported extension: renegotiation_info
If the client is expected to authenticate the server, the server sends down it
certificate and possibly its CA.
Consuming server Certificate handshake message (
It will be used for this connection
"Certificates": [
"certificate" : {
"subject" : "CN=SERVER, OU=SSS, O=ZZZZ",
"certificate" : {
"version" : "v3",
"serial number" : "1A",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=TEMP4Certification Authority, OU=TEST, O=TEMP",
"not before" : "2020-12-17 24:00:00.000 GMT",
"not after" : "2021-12-17 23:59:59.000 GMT",
"subject" : "CN=SERVER, OU=SSS, O=ZZZZ",
"subject public key" : "RSA",
"extensions" : [
{
ObjectId: 2.16.840.1.113730.1.13 Criticality=false
},
{
ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 4E 84 B6 96 07 27 AE 17 BB F6 D9 14 53 10 45 77 N....'......S.Ew
0010: 1E 0E 9B 43 ...C
]
]
},
{
ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_Encipherment
]
},
{
ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
IPAddress: 10.1.3.10
]
},
{
ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 1E 3E 5B E5 A8 F1 A2 8E 2B 7D 46 33 BB 74 9A 6A .>[.....+.F3.t.j
0010: 6A D1 17 AE j...
]
]
}
]},
and the CA for the certificate - optional
"certificate" : {
"subject" : "CN=TEMP4Certification Authority, OU=TEST, O=TEMP",
"certificate" : {
"version" : "v3",
"serial number" : "00",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=TEMP4Certification Authority, OU=TEST, O=TEMP",
"not before" : "2020-07-14 24:00:00.000 BST",
"not after" : "2021-07-02 23:59:59.000 BST",
"subject" : "CN=TEMP4Certification Authority, OU=TEST, O=TEMP",
"subject public key" : "RSA",
"extensions" : [
{
ObjectId: 2.16.840.1.113730.1.13 Criticality=false
},
{
ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
},
{
ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]
},
{
ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 4E 84 B6 96 07 27 AE 17 BB F6 D9 14 53 10 45 77 N....'......S.Ew
0010: 1E 0E 9B 43 ...C
]
]
}
]}
]
Fatal (CERTIFICATE_UNKNOWN): PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
certification path to requested target (
"throwable" : { sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
The following are a list of certificate in the CA chain (in order) for the
above certificate - optional
These are the CAs
Found trusted certificate (
"certificate" : {
"subject" : "CN=TEMP4Certification Authority, OU=TEST, O=TEMP",
"certificate" : {
"version" : "v3",
"serial number" : "00",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=TEMP4Certification Authority, OU=TEST, O=TEMP",
"not before" : "2020-07-14 24:00:00.000 BST",
"not after" : "2021-07-02 23:59:59.000 BST",
"subject" : "CN=TEMP4Certification Authority, OU=TEST, O=TEMP",
"subject public key" : "RSA",
"extensions" : [
{
ObjectId: 2.16.840.1.113730.1.13 Criticality=false
},
{
ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
},
{
ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]
},
{
ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 4E 84 B6 96 07 27 AE 17 BB F6 D9 14 53 10 45 77 N....'......S.Ew
0010: 1E 0E 9B 43 ...C
]
]
}
]}
)
End of optional...
This is what will be used to encrypt the handshake. secp256r1 is an elliptic curve
Consuming ECDH ServerKeyExchange handshake message (
"ECDH ServerKeyExchange": {
"parameters": {
"named group": "secp256r1"
"ecdh public": {
},
},
"digital signature": {
"signature algorithm": "rsa_pkcs1_sha256"
"signature": {
},
}
}
If the server has requested client authentication, it sends a CertificateRequest message.
The following says “Please authenticate by sending the certificate to identify the client”.
Consuming CertificateRequest handshake message (
"CertificateRequest": {
Server accepts any of the following types
"certificate types": [rsa_sign, dss_sign, ecdsa_sign]
(Optionally) and any of the followin algorithms
"supported signature algorithms": [ecdsa_secp521r1_sha512, rsa_pkcs1_sha512, ...
Server knows about the following "certificate authorities" or
self signed certificates
Note it is hard to tell where one CA ends and the next starts.
CA should begin with CN=
"certificate authorities": [CN=ECBPECC, OU=EC, O=ZZZZ,
CN=SSCA8, OU=CA, O=SSS, C=GB,
CN=TEMP4Certification Authority, OU=TEST, O=TEMP,
CN=CA_BPECC, OU=TEST, O=TEMP,
CN=TEMP4Certification Authorit2, OU=TEST, O=TEMP,
CN=SS, O=SSS, C=GB]
}
There is logic
If the client has not specified which alias (keystore entry) to use
- For each item in the signature algorithms ( EC, RSA, ECDSA...)
See the listof valid values from the spec
- For each item in the CA List
- Get the first entry in the keystore which matches the Lookup(signature,CA)
and has a private certificate
The certificate from the key store did not have a private key, and failed validation
ss is not a private key entry
Unavailable authentication scheme: ecdsa_secp521r1_sha512
There were no entries in the keystore for EC No X.509 cert selected for EC Unavailable authentication scheme: ecdsa_secp521r1_sha512 But it found a matching entry so use this one matching alias: ss
Consuming ServerHelloDone handshake message ( <empty>If you get
*** ServerHelloDone Warning: no suitable certificate found - continuing without client authentication *** Certificate chain <Empty> ***it means the client could not find a matching certificate in the client’s keystore. See the description in the box above. The certificaterequest is documented here. and here(for Elliptic certificate). The certificate types can be
- rsa_sign
- dss_sign
- rsa_fixed_dh
- dss_fixed_dh
- rsa_ephemeral_dh_RESERVED
- dss_ephemeral_dh_RESERVED
- fortezza_dms_RESERVED
- ECDSA_sign:Certificate MUST contain an ECDSA-capable public key and be signed with ECDSA.
- ECDSA_fixed_ECDH:Certificate MUST contain an ECDH-capable public key on the same elliptic curve as the server’s long-term ECDH key. This certificate MUST be signed with ECDSA.
- RSA_fixed_ECDH: Certificate MUST contain an ECDH-capable public key on the same elliptic curve as the server’s long-term ECDH key. This certificate MUST be signed with RSA.
Send this back to the server
Produced client Certificate handshake message (
"Certificates": [
"certificate" : {
"subject" : "CN=SS, O=SSS, C=GB",
"certificate" : {
"version" : "v3",
"serial number" : "73 CB 2B 49 D0 E5 6B BE AA 95 EC 8E A0 1F CC C5 49 A9 7B A8",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=SS, O=SSS, C=GB",
"not before" : "2021-01-18 14:14:38.000 GMT",
"not after" : "2021-02-17 14:14:38.000 GMT",
"subject" : "CN=SS, O=SSS, C=GB",
"subject public key" : "RSA",
"extensions" : [
{
ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 2A 83 45 6A B1 FE 87 E8 DA 55 D3 AD 39 09 C4 2E *.Ej.....U..9...
0010: 4F 61 2C 02 Oa,.
]
]
},
{
ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
},
{
ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Key_CertSign
]
},
{
ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 2A 83 45 6A B1 FE 87 E8 DA 55 D3 AD 39 09 C4 2E *.Ej.....U..9...
0010: 4F 61 2C 02 Oa,.
]
]
}
]}
]
Send up the encrypted key
WRITE: TLS12 handshake, length = 1356
Produced ECDHE ClientKeyExchange handshake message (
"ECDH ClientKeyExchange": {
"ecdh public": {
},
}
Send information to confirm that both ends work
WRITE: TLS12 handshake, length = 70
Produced CertificateVerify handshake message (
"CertificateVerify": {
"signature algorithm": rsa_pkcs1_sha512
"signature": {
}
}
Send up client has finished
WRITE: TLS12 handshake, length = 520
Produced ChangeCipherSpec message
Produced client Finished handshake message (
"Finished": {
"verify data": {
}'}
WRITE: TLS12 handshake, length = 24
wait for server to reply, and read the data sent to the client
</small
ColinPaice 