SSL/TLS

The SSL/TLS Analyzer is the CatSuite module that triages the secure connection of an authorized host. You enter a domain or URL (with the port, when it is not 443), tap CHECK, and the module performs the TLS handshake, shows the negotiated protocol version and cipher suite, validates the certificate chain up to a trusted root in Android, checks the hostname, calculates the SHA-256 and SHA-1 fingerprints of every certificate and displays the validity dates with the days remaining. This page explains every term, every panel on the screen, and how to use and configure the module to diagnose TLS failures in the lab.

SSL/TLS concepts used in the module #

Before reading the results, it helps to pin down the terms that appear in the chips, labels and messages on the screen.

TLS and SSL #

TLS (_Transport Layer Security_) is the protocol that protects HTTPS and other services: it encrypts the traffic and lets the client confirm the server's identity through certificates. SSL is the name of TLS's predecessor and is still used day to day as a synonym, which is why the module is called SSL/TLS. In practice, what the analyzer negotiates and shows are the modern TLS versions, such as TLSv1.3 and TLSv1.2.

TLS handshake #

The handshake is the initial negotiation between client and server, before any application data. During it, both sides agree on the protocol version and the cipher suite, the server presents its certificate chain and both derive the session keys. The analyzer measures how long this step takes and shows the result in the Handshake time field, in milliseconds. If the handshake does not complete, the triage fails and the error message appears on the screen.

Protocol version and cipher suite #

The protocol version is the TLS edition both sides agreed to use, such as TLSv1.3. The cipher suite is the combination of algorithms chosen for the session: key exchange, symmetric cipher and integrity function, for example TLS_AES_128_GCM_SHA256 or TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Old versions and weak ciphers point to configurations that deserve attention in the report.

SNI (Server Name Indication) #

SNI is a TLS extension in which the client states, right at the start of the handshake, which hostname it wants to reach. This lets a single IP address serve several sites, each with its own certificate. On Android, when the target is a domain name, that name is sent in the negotiation as SNI. When the target is an IP address, there is no name to indicate, and the server usually answers with a default certificate, which often leads to HOSTNAME FAILED.

Certificate chain: leaf, intermediates and root #

The server does not present a single certificate but a chain. The first one is the leaf certificate, issued for the host. Next come the intermediates, which link the leaf to a certificate authority. At the top sits the root, the authority the system trusts directly. Each certificate is signed by the next one, and validating the chain up to the root means checking those signatures one by one until a trusted authority is reached.

Trusted root and the Android store #

A trusted root (_trust anchor_) is a certificate authority present in the device's trust store. The analyzer uses Android's default validator to decide whether the presented chain ends at one of these roots. Self-signed certificates, certificates issued by a private CA, or chains with missing intermediates do not reach a trusted root and produce CHAIN WITH ALERT.

Hostname verification and SAN #

A valid chain is not enough: the leaf certificate must have been issued for the host being accessed. This check uses the Subject Alternative Names (SAN), the list of domains and addresses the certificate covers. The result appears in the HOSTNAME OK or HOSTNAME FAILED chip, and the SAN entries of each certificate appear as chips on its card.

SHA-256 and SHA-1 fingerprints #

A fingerprint is the hash of the whole certificate, calculated over its encoded form. Two identical certificates have the same fingerprint, and any difference, however small, changes the value completely. That makes the fingerprint the safest way to compare certificates and record them as evidence. The module shows each value in uppercase hexadecimal, with the bytes separated by colons. SHA-256 is the recommended reference; SHA-1 is shown for compatibility with older inventories and tools.

Validity dates #

Every certificate has a start (_not before_) and an end (_not after_) of validity. Outside that interval, the certificate must be rejected. The analyzer shows both dates in the dd/mm/yyyy hh:mm format, in the device's time zone, and summarizes the situation as days remaining, expiring today, or expired.

The SSL/TLS Analyzer screen #

The screen is a scrollable column. The header and the input panel sit at the top; below them, the result area changes according to the state of the triage.

Module header #

The header shows the SSL/TLS ANALYZER tag, the CERTIFICATES AND TLS SESSION title and the summary "Analyze certificates, TLS, ciphers, and fingerprints."

TARGET HTTPS panel #

The TARGET HTTPS panel holds the address field (with the "Your URL" hint) and the CHECK button. While the analysis runs, the button shows ANALYZING with a progress indicator and is disabled, and the panel displays "Connecting, negotiating TLS and validating the chain...".

Result area states #

Session Summary #

The SESSION SUMMARY card ("See the host, certificate, and TLS session.") starts with three verdict chips and continues with the main connection data.

The final strip repeats the color of the chain chip. It shows "The certificate chain was successfully validated for the provided host.", "The chain was accepted, but the hostname does not match the certificate that was presented." or the reason returned by the Android validator when the chain is not accepted.

Certification chain #

The CERTIFICATION CHAIN card states how many certificates were observed during the handshake and lists one card per certificate, in the order the server sent them. Each card has a role chip (LEAF, INTERMEDIATE 1, INTERMEDIATE 2 and so on, and ROOT) and the "Valid now" or "Outside validity period" indicator.

TLS Versions #

The TLS VERSIONS card ("See the protocol and accepted TLS versions.") shows a highlighted chip with the negotiated version and one chip for each version the server accepted in individual tests. Below, the Versions visible on the device line lists the TLS versions the device itself supports.

Cipher Suites #

The CIPHER SUITES card ("See the negotiated cipher suite and available options.") contains the Negotiated line and a list of chips. The first, highlighted chip is the negotiated cipher suite; the others are cipher suites supported by the device, in alphabetical order and without the insecure categories (null, anonymous, RC4 and 3DES), limited to the first 18. With more than six chips, the list becomes a horizontally scrolling strip.

SSL/TLS Analyzer options and how to configure them #

The module has no settings sheet of its own: the triage depends on the address you enter and on two general CatSuite switches.

To configure it: type in the field only what identifies the service, such as example.com or api.example.com:8443; if you paste a full URL, the module extracts the host and port by itself. Always enter the port explicitly when the TLS service is not on 443. If the module does not appear in the menu, turn on ENABLE SSL/TLS ANALYZER under Settings > Apps; while it is hidden, the send shortcut from captures is unavailable too. Only turn on the AI permission if you want the assistant to run the triage on its own within the scope.

How the host and port are normalized #

Before connecting, the analyzer rewrites what you typed and updates the field with the result.

The final scheme is always https://, because the module only speaks TLS. Internationalized domain names are converted to their ASCII form (punycode) before connecting.

Fixed triage parameters #

Some behaviors are not configurable, but they help you interpret the result.

Buttons and actions #

Input panel #

Results #

Selection context menu #

Every value on the screen, such as subject, issuer, serial and fingerprints, can be selected. The address field also has the menu, with the editing actions.

Shortcuts from other modules #

Step by step: how to use the SSL/TLS Analyzer #

Run the first triage of a host #

1. Open the SSL/TLS Analyzer from the main menu. If it does not appear, enable it under Settings > Apps.
2. In the TARGET HTTPS panel, type the domain or paste the URL of the authorized target. Add :port if the service is not on 443.
3. Tap CHECK or the keyboard Go key.
4. Wait for the loading card and check the three verdict chips in the Session Summary.
5. Read Host and Normalized target to confirm the module analyzed exactly the intended service.

Validate the chain up to the root #

1. Look at the CHAIN OK or CHAIN WITH ALERT chip and read the message strip at the end of the summary.
2. Scroll down to CERTIFICATION CHAIN and check how many certificates were observed.
3. On each card, compare one certificate's Issuer with the next one's Subject: they must match all the way to the top.
4. On the last card, check the issuer to identify the authority that closes the chain.
5. Check the "Valid now" indicator on every certificate; an expired intermediate also breaks the chain.

Check and record fingerprints #

1. In the Session Summary, tap the copy icon of Fingerprint SHA-256 to put the leaf hash on the clipboard.
2. Compare the value with the expected fingerprint, provided by the target owner or obtained with another tool.
3. Select the fingerprint and use NOTES to record it in the notepad, along with the host, date and TLS version.
4. Repeat on the intermediate cards when you need to document the whole chain.

Check protocol versions and cipher #

1. On the TLS VERSIONS card, read the highlighted chip with the negotiated version.
2. Check the chips of accepted versions: the presence of TLSv1 or TLSv1.1 indicates support for legacy versions.
3. Compare with Versions visible on the device: a version missing from that line could not be tested by the device.
4. On the CIPHER SUITES card, read the Negotiated line and record the chosen cipher.

Diagnose a TLS failure #

1. Run the triage and read the message on the SSL/TLS parsing failed card, if it appears.
2. If the message mentions a timeout, a refused connection or an unresolved host, the problem lies before TLS: review host, port and network.
3. If the handshake completes but the chain has an alert, read the chain message strip and the certificate cards to find the cause.
4. If the HOSTNAME FAILED chip appears, compare the host you typed with the SAN chips on the leaf certificate.
5. If OUT OF VALIDITY appears, check the validity dates and the device clock.

Analyze the host of a Proxy capture #

1. With the Network Proxy capturing authorized traffic, open the Interceptor.
2. Long press the capture you want and choose Send to SSL/TLS Analyzer.
3. The module opens with the request's host filled in and starts the check right away.
4. Compare the server's real certificate with the behavior observed on the client.

How it relates to the Network Proxy and the Repeater #

The SSL/TLS Analyzer connects directly from the device to the server, without going through the Network Proxy. That is why it sees the target's genuine certificate. When a client browses through the proxy with HTTPS interception on, the certificate that client receives is issued on the fly by the lab CA, so the leaf fingerprint seen by the client will differ from the fingerprint the analyzer shows. That difference is expected and confirms that interception is active. If a client refuses the connection through the proxy, use the analyzer to check whether the problem lies in the server itself (chain, validity, version) or in the trust placed in the lab CA.

In the Repeater, an HTTPS send can fail because of an invalid certificate or an incompatible protocol. Before turning on Ignore certificate errors in the Repeater settings, run the analyzer against the same host: it shows whether the chain is self-signed, whether the hostname does not match or whether the certificate has expired. This way you document the exact reason for the failure and only disable validation in the Repeater when the environment is your own and authorized.

Examples #

Inputs accepted in the TARGET HTTPS panel field.

example.com
https://example.com/login?next=/dashboard
api.example.com:8443
https://[2001:db8::10]:8443/

Summary of a healthy session, as recorded in the notepad.

Host: example.com:443
Normalized target: https://example.com
Negotiated TLS: TLSv1.3
Negotiated cipher suite: TLS_AES_128_GCM_SHA256
Handshake time: 182 ms
Validity: 01/08/2026 00:00 to 30/10/2026 23:59
Expiration status: 24 days remaining

A typical chain with a leaf and an intermediate, as listed on the Certification chain card. Note that the second card gets the ROOT label even though it is the intermediate: the server did not send the root, and its issuer reveals the authority that closes the chain.

LEAF
Subject: CN=example.com
Issuer: CN=Example Intermediate CA,O=Example,C=US

ROOT
Subject: CN=Example Intermediate CA,O=Example,C=US
Issuer: CN=Example Root CA,O=Example,C=US

Format of the fingerprints displayed by the module.

SHA-256: 3B:7E:1A:C4:59:02:DF:88:6A:E1:4C:93:B0:27:5D:F6:11:A8:7C:E9:42:0B:D5:36:9F:C2:68:E4:1D:B7:05:7A
SHA-1: 9C:2E:41:B8:07:D3:6F:A5:18:E0:C7:52:3B:94:FD:61:0A:8E:27:C3

Checking the leaf's SHA-256 fingerprint outside the app, on a workstation.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256

Manual test of a specific TLS version, useful to confirm the TLS Versions panel.

openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

Common problems and frequently asked questions (FAQ) #

"Enter a domain or URL to analyze." appeared. The field was empty. Type a domain, a URL or host:port and tap CHECK again.

The failure says the address could not be parsed or the host could not be identified. The text does not form a valid URL. Remove spaces and stray characters and use the example.com or example.com:8443 format. IPv6 addresses must be enclosed in brackets.

The analysis failed with a timeout or a refused connection. The port is closed or filtered, or the host did not answer within 4.5 seconds. Confirm the TLS service port, the device's connectivity and whether the target accepts connections from your network.

The failure mentions that the host could not be resolved. The name does not exist in the DNS used by the device. Check the domain spelling or use the IP address, keeping in mind that this affects SNI and hostname verification.

The handshake does not complete and the message mentions the handshake or the protocol. The service on that port may not speak TLS (plain HTTP, for example), may require a client certificate, or may accept only versions and ciphers the device does not offer.

Why does CHAIN WITH ALERT appear if the site opens in the browser? The alert also appears when the chain is valid but the hostname does not match; read the message strip. Another common cause is a server that does not send the intermediate: some browsers complete the chain on their own, but the Android validator does not.

The chain message mentions "Trust anchor for certification path not found". The chain does not end at a trusted Android root. This is the typical case of a self-signed certificate, a private CA or a missing intermediate.

I analyzed an IP and got HOSTNAME FAILED. Without a domain name there is no SNI, and the server answers with its default certificate, which rarely covers the IP. Analyze by hostname instead.

The ROOT card shows an intermediate certificate. The server sent only the leaf and the intermediate, and the last one in the list gets the root label. See the note in the Certification chain section above.

The status says it expires today, but the chip shows OUT OF VALIDITY. The days remaining are counted in whole days. A certificate that expired a few hours ago still shows as expiring today, while the chip already reflects the exact validity.

The dates look wrong. The dates follow the device's time zone and clock. A misconfigured clock can also make a valid certificate appear out of validity.

The fingerprint on the client going through the Proxy differs from the analyzer. That is expected with HTTPS interception on: the client receives a certificate issued by the lab CA. See the section on how the module relates to the Network Proxy and the Repeater, above.

I do not see "Send to SSL/TLS Analyzer" on captures. The shortcut only appears when the module is enabled under Settings > Apps.

Next step #

• Network Proxy
• Repeater
• Interceptor
• Decoder
• History and notes
• Modules overview