# SSL/TLS

> CatSuite SSL/TLS Analyzer: how to use and configure handshake triage, TLS version, cipher suite, chain validation to the root, fingerprints and expiry.

- Language: en
- Canonical URL: https://netcattest.com/catsuite/en/docs/modules/ssl-tls
- Section: Modules
- Updated: 2026-10-06
- Other language (pt-BR): https://netcattest.com/catsuite/docs/modulos/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.

> [!NOTE]
> The SSL/TLS Analyzer is a read-only diagnostic tool. It only opens TLS connections and reads what the server presents; it does not send HTTP requests or change any system setting. The chain verdict always comes from Android's own store of trusted authorities.

## 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.

| Term | What it is | Where it appears in the module |
| --- | --- | --- |
| Handshake | Initial TLS negotiation | Handshake time, loading and error messages |
| Protocol version | Negotiated TLS edition | Negotiated TLS and the TLS Versions panel |
| Cipher suite | Combination of session algorithms | Negotiated cipher suite and the Cipher Suites panel |
| SNI | Hostname sent at the start of the handshake | Influences the certificate received and the hostname chip |
| Chain | Leaf, intermediates and root | Certification chain card |
| Trusted root | Authority present in the Android store | CHAIN OK or CHAIN WITH ALERT chip and chain message |
| SAN | Names covered by the certificate | Chips on each certificate card |
| Fingerprint | SHA-256 or SHA-1 hash of the certificate | Session Summary and each certificate card |
| Validity | Start and end of the valid period | Validity, Expiration status and validity chip |

## 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

| State | What appears |
| --- | --- |
| Before the first analysis | "No analysis done yet" card, reminding you that the analyzer identifies the host automatically to verify the certificate. |
| In progress | "Performing TLS handshake, validating the chain and calculating fingerprints." card. |
| Error | "SSL/TLS parsing failed" card, with the detailed message of the problem. |
| Completed | Session Summary, Certification chain, TLS Versions and Cipher Suites cards. |

### 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.

| Item | What it shows |
| --- | --- |
| CHAIN OK / CHAIN WITH ALERT | Green when the chain reaches a trusted root and the hostname matches; orange otherwise. |
| HOSTNAME OK / HOSTNAME FAILED | Result of checking the host against the leaf certificate. |
| VALID CERTIFICATE / OUT OF VALIDITY | Status of the leaf certificate at the current date and time. |
| Host | Host and port actually analyzed, in the `host:port` format. |
| Normalized target | Final address used in the analysis, always in `https://`. |
| Negotiated TLS | Protocol version accepted in the handshake. |
| Negotiated cipher suite | Cipher suite chosen for the session. |
| Handshake time | Duration of the handshake, in milliseconds. |
| Validity | Start and end of the leaf certificate's validity. |
| Expiration status | Days remaining, expiring today, or how many days ago it expired. |
| Fingerprint SHA-256 | SHA-256 hash of the leaf certificate, with a copy button. |
| SHA-1 Fingerprint | SHA-1 hash of the leaf certificate, with a copy button. |
| Chain message | Colored strip explaining the chain verdict. |

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.

| Field | What it shows |
| --- | --- |
| Subject | Distinguished name of the holder, such as `CN=example.com`. |
| Issuer | Distinguished name of whoever signed the certificate. |
| Serial | Serial number in uppercase hexadecimal. |
| Signature | Signature algorithm, such as `SHA256withRSA`. |
| Public key | Public key algorithm, such as `RSA` or `EC`. |
| Validity | Start and end of that certificate's validity. |
| Status | Days remaining or how many days ago it expired. |
| SAN chips | Alternative names covered, when present. |
| SHA-256 and SHA-1 | Fingerprints of that certificate, each with a copy button. |

> [!IMPORTANT]
> Each certificate's role follows its position in the list sent by the server: the first one is the leaf and the last one gets the root label. Many servers do not send the root, only the leaf and an intermediate. In that case, the card marked **ROOT** is actually the last intermediate; check its **Issuer** field to find out which authority closes the chain.

### 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.

> [!NOTE]
> The Cipher Suites chip list describes what the **device** offers, not everything the server accepts. The data that comes from the server is the negotiated cipher suite.

## 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.

| Option | Values | Default | What it does |
| --- | --- | --- | --- |
| Address field (TARGET HTTPS) | Domain, URL, `host:port`, IPv4 or bracketed IPv6 | Empty | Sets the host and port of the triage; path, query and fragment are discarded. |
| Port | 1 to 65535, inside the address | 443 | Picks the TLS service to analyze, such as `example.com:8443`. |
| Enable SSL/TLS Analyzer (Settings > Apps) | On / Off | Off, unless picked in the initial module selection | Shows or hides the module in the main menu and enables the send shortcut from captures. |
| AI SSL/TLS ANALYZER permission | On / Off | Off | Lets the CatSuite AI assistant run the triage and read certificates and fingerprints. |

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.

| You type | Normalized target | Host analyzed |
| --- | --- | --- |
| `example.com` | `https://example.com` | `example.com:443` |
| `https://example.com/login?next=/dashboard` | `https://example.com` | `example.com:443` |
| `example.com:8443` | `https://example.com:8443` | `example.com:8443` |
| `https://example.com:443/` | `https://example.com` | `example.com:443` |
| `[2001:db8::10]:8443` | `https://[2001:db8::10]:8443` | `[2001:db8::10]:8443` |

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.

| Parameter | Value | Effect |
| --- | --- | --- |
| Connect and read timeout | 4.5 seconds | Slow or filtered hosts produce a timeout error. |
| Default port | 443 | Used when the address has no port. |
| Versions tested | TLSv1.3, TLSv1.2, TLSv1.1 and TLSv1 | Only those the device supports; each one is a separate handshake. |
| Cipher suite list | Negotiated plus up to 18 from the device | Excludes null, anonymous, RC4 and 3DES suites. |
| Chain validation | Android default validator | Sets CHAIN OK or CHAIN WITH ALERT. |

> [!TIP]
> Each triage opens one main connection plus one per TLS version tested. On targets with connection limits or scan alerts, wait a few seconds between checks.

## Buttons and actions

### Input panel

| Button or action | What it does |
| --- | --- |
| CHECK | Normalizes the address and starts the triage. Turns into ANALYZING and stays disabled until it finishes. |
| Keyboard Go key | Starts the triage from the field, just like CHECK. |
| Empty field + CHECK | Shows the "Enter a domain or URL to analyze." notice. |

### Results

| Button or action | Where | What it does |
| --- | --- | --- |
| Fingerprint SHA-256 copy icon | Session Summary | Copies the leaf's SHA-256 and confirms with "Copied SHA-256 fingerprint." |
| SHA-1 Fingerprint copy icon | Session Summary | Copies the leaf's SHA-1 and confirms with "Copied SHA-1 fingerprint." |
| SHA-256 copy icon | Certificate card | Copies that certificate's SHA-256. |
| SHA-1 copy icon | Certificate card | Copies that certificate's SHA-1. |
| Text selection | Any value | Opens the CatSuite context menu. |

### 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.

| Action | What it does |
| --- | --- |
| COPY | Copies the selected text. |
| CUT | Cuts the selection (address field only). |
| PASTE | Pastes the clipboard content (address field only). |
| DECODER | Sends the selection to the [Decoder](https://netcattest.com/catsuite/en/docs/modules/decoder). |
| NOTES | Sends the selection to the notepad in [History and notes](https://netcattest.com/catsuite/en/docs/modules/history). |
| EVERYTHING | Selects the whole text of the value. |
| BLOCK | Copies the entire value. |

### Shortcuts from other modules

| Source | Action | Result |
| --- | --- | --- |
| [Interceptor](https://netcattest.com/catsuite/en/docs/modules/interceptor) | Long press on a capture > **Send to SSL/TLS Analyzer** | Opens the module with the request's host already normalized and starts the triage automatically. |
| Floating button | SSL/TLS Analyzer action | Opens the module directly. |
| AI assistant | SSL/TLS analysis tool, with the permission on | Runs the triage on an in-scope host or opens the module with the address of the request or of the current Browser page. |

## 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](https://netcattest.com/catsuite/en/docs/modules/proxy) capturing authorized traffic, open the [Interceptor](https://netcattest.com/catsuite/en/docs/modules/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](https://netcattest.com/catsuite/en/docs/modules/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](https://netcattest.com/catsuite/en/docs/modules/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.

> [!WARNING]
> A chain with an alert in production is a finding, not an obstacle to work around. Record the result and treat disabling validation in the Repeater strictly as a lab resource.

## Examples

Inputs accepted in the TARGET HTTPS panel field.

```text
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.

```text
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.

```text
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.

```text
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.

```bash
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.

```bash
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**.

> [!DANGER]
> Analyze only hosts you are authorized to test. Even as a read-only triage, every check opens several real TLS connections against the target. See [Security](https://netcattest.com/catsuite/en/docs/security).

## Next step

- [Network Proxy](https://netcattest.com/catsuite/en/docs/modules/proxy)
- [Repeater](https://netcattest.com/catsuite/en/docs/modules/repeater)
- [Interceptor](https://netcattest.com/catsuite/en/docs/modules/interceptor)
- [Decoder](https://netcattest.com/catsuite/en/docs/modules/decoder)
- [History and notes](https://netcattest.com/catsuite/en/docs/modules/history)
- [Modules overview](https://netcattest.com/catsuite/en/docs/modules)