TLS v.1.0 ServerHello阶段未知报文的技术求助

Hey there, let's break down this TLS 1.0 traffic mystery you've encountered. I've parsed the byte data you provided, and here's what's going on with that "unknown content" after ServerHello:

1. First: Split the byte stream correctly #

The opening segment is a valid ServerHello handshake message wrapped in a TLS record:

• 16 03 01 00 2a: TLS Handshake record (type 16, TLS 1.0 version 03 01, total length 42 bytes)
• Inside the record: 02 00 00 26: ServerHello message (type 02, length 38 bytes)
  • Core ServerHello content: TLS 1.0 version, 32-byte random value, empty session ID, cipher suite TLS_RSA_WITH_AES_256_CBC_SHA (00 35), no compression.

2. The "unknown content" is a standalone leaf X.509 certificate #

Right after ServerHello, the next TLS record contains a single X.509 v3 certificate (this is what you're seeing as the "single certificate" before the full chain). When decoded from its DER byte format, here's its key details:

• Certificate Version: X.509 v3
• Serial Number: 01
• Signature Algorithm: SHA1 with RSA Encryption (1.2.840.113549.1.1.5)
• Issuer:
  • Country: UA (Ukraine)
  • State/Province: Kyiv
  • Locality: Kyiv
  • Organization: Crypto GmbH
  • Organizational Unit: Techops Team
  • Common Name: www.crypto.com
  • Email: alexanderko@crypto.com
• Validity Period:
  • Not Before: Oct 15 19:43:19 2015 UTC
  • Not After: Oct 10 19:43:19 2035 UTC
• Subject (End-Entity Certificate):
  • Country: UA
  • State/Province: Kyiv
  • Locality: Kyiv
  • Organization: Crypto GmbH | Warface
  • Organizational Unit: Techops Team
  • Common Name: warface.crypto.com
  • Email: alexanderko@crypto.com
• Public Key: 2048-bit RSA key (exponent 0x010001)

3. Why a separate certificate followed by a full chain? #

This behavior is non-standard but not unheard of in older/custom TLS implementations:

• Non-compliant server implementation: The TLS spec requires the Certificate handshake message to include the full trust chain (leaf → intermediate CA(s) → trusted root, omitting the root if it's already in the client's trust store). Some older servers split this into multiple Certificate messages.
• Wireshark parsing quirk: It's possible the single certificate is part of a larger, fragmented Certificate message that Wireshark displayed as two separate entries.
• Server-specific optimization: Rarely, servers might send the leaf certificate first to kick off key exchange faster, then send the rest of the chain for trust validation.

4. Verify this yourself with OpenSSL #

To confirm the certificate details, save the DER bytes starting at 308205b4 (the start of the X.509 sequence) to a file named unknown-cert.der, then run:

openssl x509 -in unknown-cert.der -inform der -text -noout

This will output the full human-readable certificate details matching what I outlined above.

内容的提问来源于stack exchange，提问作者Илья Петров