How to troubleshoot client certificate authentication for inbound communication to Cloud Integration using Wireshark
This blog describes how to troubleshoot TLS mutual authentication or Client Certificate Authentication to Cloud Integration using Wireshark, the most common errors and root cause, and gives step-by-step instructions on key points to validate.
Scenario: Connecting a customer system to Cloud Integration using Client Certificate Authentication. The communication is failing due to some SSL errors such as: “unknown_ca” or “An Authentication object was not found in the SecurityContext” or “Could not create SSL/TLS secure channel” or many other different errors.
Common errors and root causes:
“unknown_ca” is because the public key’s root certificate is not included in SAP Trusted CA List or the Keypair does not include the complete certificate chain
“An Authentication object was not found in the SecurityContext” possible options:
- No certificate is being provided for TLS mutual authentication
- Certificate is not correctly configured on BTP Cockpit > Instance (type = x_509) > Service Key
“Could not create SSL/TLS secure channel” could have different causes but the most common is TLS version is not supported (i.e. TLS 1.0, TLS 1.1)
To be able to validate we will use “Wireshark Network Protocol Analyzer”
Note: Please find the installer for Windows, Linux, and Mac OS, the installation process is not in the scope of this blog. https://www.wireshark.org
But first, some needed Technical background:
I recommend the following blog by Priyanka Pillai from where I have taken the following:
“Client Certificate Authentication is mutual certificate-based authentication, where the client provides its Client Certificate to the Server to prove its identity. This happens as a part of the SSL Handshake.
Important: As the SSL Handshake happens before HTTP communication, Client Certificate Authentication takes the highest precedence over any other type of authentication that takes place over HTTP protocol.”
For mutual authentication, the server sends a CertificateRequest* message to the client during the SSL handshake.
- Access to Wireshark on sender system
- Test scenario on sender system ready to be executed.
- iFlow successfully deployed in tenant
- CF tenant must have created corresponding service key with PEM
Neo tenant must have uploaded the certificate and created certificate-to-user mapping.
Step 1: Execute Wireshark
Step 4: Analysis
- Client Hello: Sends a packet with all the cipher suites supported by sending system or application; Validate the actual TLS version (Please be aware that some middleware might configure TLS version but execute differently, it happens a lot); and last validate that indeed are sending information to BTP CI tenant under Server Name. Cipher Suites ➡️ Transport Layer Security > TLSv1.2 > Handshake protocol >Cipher SuitesTLS Version ➡️ Transport Layer Security > TLSv1.2 > Handshake protocol > VersionServer Name ➡️ Transport Layer Security > TLSv1.2 > Handshake protocol > Extension: server_name >> Server Name
- Server Hello: Sends a packet with the cipher suite that was selected.
Cipher Suite ➡️ Transport Layer Security > TLSv1.2 > Handshake protocol >> Cipher Suite
- Certificate: Server will provide the public certificate including all the intermediate certificates in the certificate chain. These certificates belong to the Load Balancer (not your tenant). You can validate the certificates exchanged here.
- Server Key Exchange: The ServerKeyExchange message is sent by the server only when the
server Certificate message (if sent) does not contain enough data
to allow the client to exchange a premaster secret.
- Certificate Request: The server requests a certificate for mutual authentication, and provides a list of the distinguished names of acceptable certificate authorities (this is the same as the one from SAP Globa Trust List. Note: Always validate SAP note 2801396
- Server Hello Done: This message is sent by the server in order to indicate the end of the server hello and associated messages. After this message, the server waits for a client response.
- Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message:
“Certificate” is the message that contains the client certificate.
Validate that the certificate complete chain matches the one contained in the keystore (Private + Public) ➡️ Transport Layer Security > TLSv1.2 > Handshake protocol >Certificates > Certificate
“Client Key Exchange” with this message, the premaster secret is set.”Certificate Verify” this message is used to provide explicit verification of a client
certificate. The client is authenticated by using its private key to sign a hash of all the messages up to this point. The recipient verifies the signature using the public key of the signer, thus ensuring it was signed with the client’s private key.”Finished (Encrypted Handshake Message)” this message is the first one protected with the just negotiated algorithms, keys, and secrets, which indicates that the TLS negotiation is completed for the client.
- New Session, Change Cipher Spec, Encrypted Handshake Message: This is the server response, informing the client messages will be encrypted with the selected algorithms and keys, and change its state to use the symmetric key encryption, the “Finished” message is similar to the client but will include the previous Finished message. Once the client successfully decrypts and validates, the server is authenticated.
- Now the client and server can exchange application data using the symmetric encryption and session key.
This was a successful execution now let’s analyze specific cases.
A certificate is found but it does not contain a valid certificate chain, the root CA cannot be validated.
Error: SSLException: Received fatal alert: protocol_version
I hope this could help you troubleshoot the connectivity to SAP Cloud Integration 🖖🏻