# TLS Concepts

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

{% hint style="success" %}
**Recommended:** Use TLS 1.2 as minimum. TLS 1.3 is preferred where client compatibility allows.
{% endhint %}

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

{% hint style="info" %}
**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.
{% endhint %}

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

{% hint style="success" %}
**Recommendation**

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

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

{% hint style="info" %}
**Important:** File extensions are naming conventions, NOT strict indicators of content or format. Always verify file contents.
{% endhint %}

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

{% hint style="danger" %}
**Bindplane collectors only support PEM format.** DER files must be converted to PEM before use. See [Certificate Conversion](/how-to-guides/security-and-tls/using-tls/reference/certificate-conversion.md).
{% endhint %}

### Inspecting File Contents

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

{% tabs %}
{% tab title="Linux/macOS" %}

```bash
# 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)
```

{% endtab %}

{% tab title="Windows PowerShell" %}

```powershell
# View file contents (look for BEGIN/END headers)
Get-Content C:\certs\certificate.pem

# Check certificate details
openssl x509 -in C:\certs\certificate.crt -text -noout

# Check private key details
openssl rsa -in C:\certs\private.key -text -noout

# Determine if file is PEM or DER format
Get-Content C:\certs\certificate.crt -First 1
# PEM starts with "-----BEGIN CERTIFICATE-----"
# DER is binary data (gibberish when viewed as text)
```

{% endtab %}
{% endtabs %}

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

{% hint style="info" %}
This guide focuses on **Collector as Server** (receiver configuration). For exporter TLS configuration, see the [OpenTelemetry Collector TLS documentation](https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/configtls/README.md).
{% endhint %}

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.bindplane.com/how-to-guides/security-and-tls/using-tls/reference/tls-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.