TLS Concepts

Educational background on TLS terminology and concepts for Bindplane collectors.

What is TLS?

TLS (Transport Layer Security) is a cryptographic protocol that provides secure communication over a network. It's the successor to SSL (Secure Sockets Layer) and is used to encrypt data in transit between clients and servers.

Brief History

• SSL 1.0 - Never released (had security flaws)

• SSL 2.0 - 1995 (deprecated, insecure)

• SSL 3.0 - 1996 (deprecated, insecure)

• TLS 1.0 - 1999 (deprecated as of 2020)

• TLS 1.1 - 2006 (deprecated as of 2020)

• TLS 1.2 - 2008 (current standard, widely supported)

• TLS 1.3 - 2018 (modern, faster, more secure)

Recommended: Use TLS 1.2 as minimum. TLS 1.3 is preferred where client compatibility allows.

TLS Handshake Overview

When a client connects to a TLS server (like a Bindplane collector receiver), they perform a "handshake":

1. Client Hello - Client proposes TLS version, cipher suites, and random data

2. Server Hello - Server selects TLS version, cipher suite, sends certificate

3. Certificate Verification - Client verifies server's certificate against trusted CAs

4. Key Exchange - Client and server negotiate encryption keys

5. Finished - Both sides confirm handshake, encrypted communication begins

In Mutual TLS (mTLS), the server also requests and verifies the client's certificate during step 3.

How Encryption Works (Simplified)

TLS uses hybrid encryption:

1. Asymmetric encryption (public/private key pairs) for the handshake and key exchange

2. Symmetric encryption (shared secret key) for the actual data transmission

This approach provides both security (asymmetric) and performance (symmetric).

TLS Terminology

Certificate

A certificate (also called a public certificate or X.509 certificate) is a digital document that:

• Contains a public key

• Contains metadata (domain name, organization, validity period)

• Is digitally signed by a Certificate Authority (CA)

• Proves the identity of the certificate holder

Example Certificate Components:

• Subject: Who the certificate identifies (e.g., CN=collector.example.com)

• Issuer: Who issued/signed the certificate (e.g., CN=Example CA)

• Validity Period: Start and end dates (e.g., 2024-01-01 to 2025-01-01)

• Public Key: The cryptographic public key

• Signature: Digital signature from the issuing CA

Private Key

A private key is the secret half of a public/private key pair. It must be:

• Kept secret and secure

• Never shared or transmitted

• Used to decrypt data encrypted with the corresponding public key

• Used to create digital signatures

In Bindplane collectors:

• The private key file (key_file) must be unencrypted (no password protection)

• Must match the certificate's public key

• Should have restrictive file permissions (600)

Public Key

A public key is the public half of a public/private key pair. It:

• Is contained within the certificate

• Can be freely shared

• Is used to encrypt data that only the private key can decrypt

• Is used to verify digital signatures created by the private key

Certificate Authority (CA)

A Certificate Authority is an entity that:

• Issues and signs digital certificates

• Acts as a trusted third party

• Maintains certificate revocation lists (CRLs)

• Provides trust infrastructure

Types of CAs:

• Public CAs: Trusted by browsers and operating systems (e.g., Let's Encrypt, DigiCert, IdenTrust)

• Private/Internal CAs: Managed by organizations for internal use

• Self-Signed: Certificates signed by their own private key (not trusted by default)

Certificate Chain and Trust

A certificate chain is the path of trust from a certificate back to a trusted root CA:

Root CA Certificate (self-signed, in trust store)
    ↓ signs
Intermediate CA Certificate
    ↓ signs
Server/Leaf Certificate (your certificate)

Trust verification process:

1. Client receives server certificate

2. Client checks if issuer is in trust store (usually not)

3. Client requests intermediate certificate(s)

4. Client follows chain up to a root CA in its trust store

5. If chain is valid and complete → Trust established

6. If chain is broken or root not trusted → Verification fails

Why Certificate Chains Matter

Your cert_file should contain the full chain (server cert + intermediates) so clients can verify the complete trust path. Missing intermediates cause "Unknown CA" errors.

Root CA, Intermediate CA, Leaf Certificate

Root CA Certificate:

• Self-signed (issuer = subject)

• Stored in operating system/browser trust stores

• Long validity period (10-25 years)

• Rarely used to sign certificates directly

Intermediate CA Certificate:

• Signed by root CA (or another intermediate)

• Used to sign server/client certificates

• Can be rotated without changing root

• Adds flexibility and security

Leaf/Server/End-Entity Certificate:

• Your actual certificate for the collector

• Signed by an intermediate CA

• Short validity period (1-2 years)

• Contains your domain name or organization info

Cipher Suites

A cipher suite is a combination of algorithms used for:

• Key exchange (e.g., ECDHE, RSA)

• Authentication (e.g., RSA, ECDSA)

• Encryption (e.g., AES-GCM, ChaCha20)

• Message authentication (e.g., SHA256, SHA384)

Example cipher suite name: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• ECDHE - Elliptic Curve Diffie-Hellman Ephemeral (key exchange)

• RSA - RSA authentication

• AES_256_GCM - AES encryption with 256-bit key in GCM mode

• SHA384 - SHA-384 hash for message authentication

Recommendation

Use the default cipher suites unless you have specific security requirements. The defaults are secure and broadly compatible.

TLS Versions

Supported TLS versions in OpenTelemetry Collector:

Version	Status	Notes
TLS 1.0	Deprecated	Insecure, should not be used
TLS 1.1	Deprecated	Insecure, should not be used
TLS 1.2	Supported	Current standard, widely compatible
TLS 1.3	Supported	Modern, faster, more secure

TLS 1.3 improvements:

• Faster handshake (1-RTT vs 2-RTT)

• Removed insecure cipher suites

• Forward secrecy by default

• Encrypted server certificate

Certificate Files and Extensions

File Extension Conventions

Important: File extensions are naming conventions, NOT strict indicators of content or format. Always verify file contents.

Extension	Typical Content	Format	Notes
.pem	Anything (cert, key, CA, chain)	Base64 text with headers	Most common, flexible
.crt / .cert / .cer	Certificate	Usually PEM, sometimes DER	Suggests it's a certificate
.key	Private key	Usually PEM, sometimes DER	Suggests it's a private key
.ca / .ca-bundle	CA certificate(s)	Usually PEM	Multiple CAs concatenated
.der	Anything	Binary DER encoding	Not human-readable
.p12 / .pfx	Certificate + key bundle	Binary PKCS#12	Windows common format
.csr	Certificate Signing Request	Usually PEM	Used to request certs from CA

Content Types in TLS

Private Key (.key, .pem)

• Secret cryptographic key that must be kept secure

• Used for decrypting data and creating digital signatures

• Header: -----BEGIN PRIVATE KEY----- or -----BEGIN RSA PRIVATE KEY-----

• Must be unencrypted for use with Bindplane collectors

Certificate / Public Certificate (.crt, .cert, .pem)

• Contains public key + metadata (domain, organization, validity) + CA signature

• Used for proving identity and establishing encrypted connections

• Header: -----BEGIN CERTIFICATE-----

• Can contain a single certificate or a chain (multiple certificates concatenated)

CA Certificate (.crt, .pem, .ca)

• Special certificate used to sign and verify other certificates

• Contains CA's public key + metadata + signature

• Header: -----BEGIN CERTIFICATE----- (same as regular certificate)

• Used as a trust anchor for certificate verification

Certificate Chain / Bundle (.pem, .crt, .chain)

• Multiple certificates concatenated in a single file

• Order: Leaf certificate → Intermediate CA(s) → (optionally) Root CA

• Example structure:

  -----BEGIN CERTIFICATE-----
  (server certificate)
  -----END CERTIFICATE-----
  -----BEGIN CERTIFICATE-----
  (intermediate CA certificate)
  -----END CERTIFICATE-----

Format Types: PEM vs DER

PEM (Privacy Enhanced Mail)

• Format: Base64-encoded text with headers

• Readable: Yes (text file)

• Support: Supported by Bindplane collectors

• Headers: -----BEGIN CERTIFICATE-----, -----BEGIN PRIVATE KEY-----, etc.

• Extensions: Usually .pem, .crt, .key, .cer

DER (Distinguished Encoding Rules)

• Format: Binary encoding

• Readable: No (binary file, gibberish when viewed as text)

• Support: NOT supported by Bindplane collectors

• Headers: None (binary data)

• Extensions: Usually .der, sometimes .cer

Bindplane collectors only support PEM format. DER files must be converted to PEM before use. See Certificate Conversion.

Inspecting File Contents

You can't always trust the file extension. To see what's actually in a file:

Linux/macOS

# View file contents (look for BEGIN/END headers)
cat certificate.pem

# Check certificate details
openssl x509 -in certificate.crt -text -noout

# Check private key details
openssl rsa -in private.key -text -noout

# Determine if file is PEM or DER format
head -n 1 certificate.crt
# PEM starts with "-----BEGIN CERTIFICATE-----"
# DER is binary data (gibberish when viewed as text)

Windows PowerShell

TLS in Observability Pipelines

Why TLS Matters for Telemetry Data

Telemetry data (logs, metrics, traces) often contains sensitive information:

• System performance and health data

• Application behavior and errors

• User activity patterns

• Infrastructure topology

• Security events

TLS protects this data by:

• Encryption: Preventing eavesdropping on telemetry in transit

• Authentication: Verifying collector and client identities

• Integrity: Detecting tampering or modification

• Compliance: Meeting regulatory requirements (PCI-DSS, HIPAA, etc.)

Collector as Server vs Collector as Client

Collector as Server (Receivers)

• Collector accepts connections from clients sending telemetry

• Collector presents its server certificate

• Clients verify the collector's certificate

• Optionally: Collector verifies client certificates (mTLS)

• Configuration: receivers section with tls block

Collector as Client (Exporters)

• Collector connects to backend systems

• Collector verifies the backend's certificate

• Optionally: Collector presents its client certificate (mTLS)

• Configuration: exporters section with tls block

This guide focuses on Collector as Server (receiver configuration). For exporter TLS configuration, see the OpenTelemetry Collector TLS documentation.

Trust Models

Public CA Trust Model:

• Certificates signed by publicly trusted CAs (Let's Encrypt, DigiCert, etc.)

• Clients have root CAs in their trust stores by default

• No additional client configuration needed

• Works well for internet-facing collectors

Private CA Trust Model:

• Organization runs its own Certificate Authority

• Certificates signed by internal CA

• Clients must be configured to trust the internal CA

• Common for internal/private deployments

• More control over certificate lifecycle

Self-Signed Trust Model:

• Certificates signed by their own private key

• No CA infrastructure needed

• Clients must explicitly trust each self-signed certificate

• Not recommended for production

• Useful for testing and development