TLS investigations become confusing when certificates, cipher suites, encryption algorithms, signatures, and key exchange are treated as one thing. They are related parts of a secure session, but each answers a different security question.

Cisco’s current 200-201 CCNACBR v1.2 blueprint explicitly includes public-key infrastructure and certificate fields, symmetric and asymmetric cryptography, cipher suites, X.509, key exchange, and protocol version. A SOC analyst should be able to look at TLS evidence and separate identity, negotiation, key establishment, and encrypted data protection.

X.509 certificates bind an identity to a public key

An X.509 certificate contains structured information about an entity and its public key.

Important fields include:

• the issuer
• the subject
• the validity period
• the subject public-key information
• extensions such as Subject Alternative Name
• the signature information used to validate the certificate

The certificate’s validity period includes notBefore and notAfter times. Subject Alternative Name can bind DNS names, IP addresses, email identities, or other forms to the certificate.

For web TLS, the hostname the client expects should be represented in the certificate’s identity information. A general explanation of an SSL/TLS certificate helps with the browser-facing concept; a security analyst needs to go further and examine the actual fields and chain.

Other fields help determine how the certificate may be used. Basic Constraints identifies whether a certificate is allowed to act as a certificate authority, while Key Usage and Extended Key Usage can restrict operations such as certificate signing, digital signatures, or server authentication. The serial number identifies the certificate within the issuing CA’s namespace and can be useful when checking revocation or comparing two certificates that share similar names.

For modern web identity, Subject Alternative Name deserves particular attention. RFC 5280 allows DNS names, IP addresses, URIs, and other identities in that extension. An analyst should therefore check the SAN values that actually correspond to the destination instead of relying on the visual familiarity of a subject common name.

The certificate is not the encrypted session key

A common mistake is assuming the server certificate directly contains the symmetric key used to encrypt application traffic.

It does not.

The certificate normally carries a public key and supports authentication. The TLS handshake establishes shared secrets that are then used to derive symmetric traffic keys.

This is why symmetric and asymmetric encryption serve different purposes in a modern TLS session. Public-key mechanisms help with authentication and key establishment; high-volume record protection uses efficient symmetric cryptography.

The certificate chain establishes trust

A server certificate is usually not evaluated in isolation.

The client attempts to build a certification path from the leaf certificate through one or more intermediate certificate authorities to a trusted root.

The issuer of one certificate should correspond to the subject of the next certificate in the chain, subject to the rules of certificate-path validation.

For an analyst, a “valid certificate” therefore involves several separate checks:

• Is the certificate within its validity period?
• Does the identity match what the client intended to reach?
• Can the certificate chain to a trusted authority?
• Are the certificate’s key usage and constraints appropriate?
• Has the trust decision been altered by an enterprise interception system?

A successful TLS connection does not necessarily mean the destination is trustworthy. Attackers can obtain valid certificates for domains they control. Certificates authenticate an identity according to PKI rules; they do not certify good intent.

Path validation also depends on more than matching names. Each issuing CA must be permitted to act as a CA, signatures in the chain must validate, time constraints must be satisfied, and the final path must reach a trust anchor accepted by the client. Revocation mechanisms such as CRLs or OCSP may add another policy-dependent check. A chain can therefore fail even when the leaf certificate’s hostname and dates appear correct.

The reverse is also important: a chain can be cryptographically valid while the destination is malicious. Public certificate authorities validate control of an identity under defined rules; they do not attest that the site is safe. Treat certificate validity as evidence about identity and trust-path mechanics, not as a reputation verdict.

Cipher suites changed meaning in TLS 1.3

Older TLS versions packed several choices into the cipher-suite name, including key exchange, authentication, bulk encryption, and hashing.

TLS 1.3 changed that model.

In TLS 1.3, the cipher suite identifies the symmetric AEAD record-protection algorithm and the hash used with HKDF. Authentication and key exchange are negotiated separately.

That distinction matters when reading captures. A TLS 1.3 cipher suite such as TLS_AES_128_GCM_SHA256 does not tell you that RSA or ECDHE was used for key exchange. You need to inspect the handshake extensions and selected group/key share.

This is one reason analysts should record the protocol version before interpreting a cipher-suite name.

A TLS 1.3 client advertises supported cipher suites, supported groups, signature algorithms, and—when using (EC)DHE—one or more key shares. Those choices are deliberately more independent than in older TLS naming. The server can select an AEAD/hash pair for record protection, an elliptic-curve group for key establishment, and a certificate/signature algorithm for authentication as separate decisions.

That independence is visible in packet analysis. If a capture shows TLS_AES_256_GCM_SHA384, the analyst knows the record-protection AEAD and HKDF hash, but still needs the supported-group/key-share exchange to identify the (EC)DHE group and the certificate/signature fields to understand authentication.

Key exchange establishes shared secret material

In a normal TLS 1.3 handshake without a pre-shared key, the client offers supported groups and a key_share, and the server selects compatible parameters.

Ephemeral Diffie-Hellman mechanisms, commonly elliptic-curve Diffie-Hellman ephemeral or ECDHE, allow both sides to derive shared secret material without sending the final symmetric traffic key across the network.

TLS 1.3 removed static RSA and static Diffie-Hellman cipher suites from the protocol and uses key-establishment approaches that provide forward secrecy for public-key-based handshakes.

Forward secrecy means compromise of the server’s long-term certificate private key later should not automatically decrypt previously captured sessions that used ephemeral key exchange.

TLS 1.3 can also use pre-shared keys for resumption or other PSK scenarios. A PSK can be combined with (EC)DHE, preserving forward secrecy for the resumed connection, or used without an ephemeral Diffie-Hellman exchange, which changes that property. For incident analysis, the presence of a resumed session can explain why the handshake contains fewer certificate messages than a fresh connection.

This is another reason to avoid interpreting one missing field in isolation. A session that lacks a new server certificate is not automatically malformed; it may be using a permitted resumption path. The analyst first identifies the handshake mode, then evaluates whether that mode is expected for the application and policy.

Digital signatures authenticate the handshake

Key exchange and authentication are separate ideas.

The server can use its certificate private key to sign handshake data, allowing the client to verify that the entity presenting the certificate possesses the corresponding private key.

That is different from using the certificate key to encrypt all application traffic.

For an analyst, this separation helps explain why a certificate can use one signature algorithm while the session uses a different symmetric cipher for record protection and a separate elliptic-curve group for key establishment.

TLS inspection changes what the analyst sees

Enterprise security devices can perform authorized TLS inspection by acting as an intermediary and establishing separate encrypted sessions.

That changes the certificate chain visible to the endpoint and allows the inspection device to see plaintext in the middle, subject to policy and technical constraints.

Authorized SSL decryption can explain why a corporate endpoint sees an enterprise-issued certificate rather than the public origin server’s original leaf certificate.

During an investigation, identify whether inspection is expected before assuming a changed certificate issuer is malicious.

Inspection effectively creates two TLS relationships: client-to-inspection device and inspection device-to-origin server. The endpoint validates the enterprise-issued certificate presented by the inspection system, while the inspection system separately validates and connects to the remote server. Network captures taken on opposite sides of that device can therefore show different certificates, keys, and session parameters for what the user experiences as one request.

When an issuer suddenly changes, check the sensor location and inspection policy before declaring certificate substitution malicious. Conversely, if a destination that should be inspected bypasses the enterprise issuer, that difference can itself be useful evidence of a policy exception, unsupported application, or alternate network path.

Useful TLS indicators for a SOC analyst

A certificate or handshake becomes more interesting when several properties are unusual together.

Examples include:

• an unexpected issuer for a destination that should not be intercepted
• a certificate identity that does not match the intended hostname
• a very short or unusual validity period in context
• a self-signed certificate where enterprise policy does not expect one
• an old protocol version or weak negotiated algorithm
• repeated TLS failures after a security-policy change
• a destination that is newly observed and already associated with suspicious DNS or endpoint behavior

None of these should be interpreted without context.

A valid certificate can be used by malicious infrastructure. A self-signed certificate can be legitimate inside a controlled system. The job is to combine TLS evidence with domain, endpoint, process, and network behavior.

Read the handshake in layers

A reliable analysis sequence is:

1. Identify the TLS protocol version.
2. Inspect the server certificate and chain.
3. Check the expected identity, validity, issuer, and trust path.
4. Identify the negotiated cipher suite.
5. For TLS 1.3, inspect the selected key-exchange group and key-share behavior separately from the cipher suite.
6. Note signature algorithms and certificate-authentication details.
7. Determine whether enterprise TLS inspection is present.
8. Correlate the session with DNS, endpoint, and threat-intelligence evidence.

That sequence prevents a common analyst error: seeing one cryptographic field and drawing a conclusion about the entire connection.

The value of TLS evidence is not that every certificate anomaly is malicious. It is that certificates, negotiation, and key exchange expose structured clues that can be tested against what the endpoint and destination were supposed to do.

In practice, preserve enough metadata to reconstruct those layers later: protocol version, SNI or destination identity where visible, certificate chain, SAN values, issuer, validity, serial number, cipher suite, selected group/key-share information, signature algorithm, session-resumption indicators, and the sensor location. Proxy or TLS-inspection logs may supply fields that a packet capture cannot decrypt.

Then combine the cryptographic evidence with the rest of the investigation. DNS establishes what name the endpoint tried to reach, process telemetry identifies which application opened the connection, and reputation or threat intelligence provides external context. TLS fields are most useful when they explain whether the secure channel behaved as expected for that specific application and network path.