Add mTLS client key password and certificate revocation configuration options for OTLP exporters

[sandy2008]

What are you trying to achieve?

I need to configure OTLP exporters to support additional mTLS security options that are commonly required in enterprise environments:

1. Password-protected private keys: Many organizations use encrypted private key files for enhanced security, but there's currently no way to specify the password for these encrypted keys.

2. Certificate revocation checking: Enterprise environments often require strict certificate validation including revocation checks, but there's no configuration option to control how certificate revocation is handled.

3. Flexible revocation scope: Different security policies may require different levels of certificate chain validation for revocation checks.

What did you expect to see?

1. Client Key Password

• OTEL_EXPORTER_OTLP_CLIENT_KEY_PASSWORD
• OTEL_EXPORTER_OTLP_TRACES_CLIENT_KEY_PASSWORD
• OTEL_EXPORTER_OTLP_METRICS_CLIENT_KEY_PASSWORD
• OTEL_EXPORTER_OTLP_LOGS_CLIENT_KEY_PASSWORD

Purpose: Specify password for encrypted client private key files (PEM format)

2. Certificate Revocation Mode

• OTEL_EXPORTER_OTLP_CERTIFICATE_REVOCATION_MODE
• OTEL_EXPORTER_OTLP_TRACES_CERTIFICATE_REVOCATION_MODE
• OTEL_EXPORTER_OTLP_METRICS_CERTIFICATE_REVOCATION_MODE
• OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE_REVOCATION_MODE

Purpose: Configure certificate revocation checking mode
Values: Online, Offline, NoCheck
Default: Online

3. Certificate Revocation Flag

• OTEL_EXPORTER_OTLP_CERTIFICATE_REVOCATION_FLAG
• OTEL_EXPORTER_OTLP_TRACES_CERTIFICATE_REVOCATION_FLAG
• OTEL_EXPORTER_OTLP_METRICS_CERTIFICATE_REVOCATION_FLAG
• OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE_REVOCATION_FLAG

Purpose: Configure certificate revocation checking scope
Values: ExcludeRoot, EntireChain, EndCertificateOnly
Default: ExcludeRoot

What did you see instead?

Currently, the OTLP exporter configuration only supports:

• OTEL_EXPORTER_OTLP_CLIENT_KEY (for unencrypted private keys)
• OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE (for client certificates)
• OTEL_EXPORTER_OTLP_CERTIFICATE (for server certificate verification)

There is no support for:

• Encrypted private key files with password protection
• Certificate revocation checking configuration
• Control over revocation validation scope

Additional context

Use Cases

1. Enterprise Security Requirements: Many enterprise environments mandate the use of encrypted private keys and require certificate revocation checking to be enabled.

2. Compliance Standards: Various compliance frameworks (SOC2, ISO 27001, etc.) require proper certificate validation including revocation checks.

3. Security Best Practices: Using encrypted private keys and proper certificate validation is considered a security best practice in production environments.

Current Workarounds

• Users must currently use unencrypted private keys, which is less secure
• Certificate revocation checking behavior depends on the underlying TLS implementation and cannot be controlled
• No way to configure revocation checking scope per security policy requirements

Similar Implementations

These configuration options are commonly available in other TLS client implementations:

• OpenSSL supports password-protected private keys
• Most TLS libraries provide certificate revocation checking options
• .NET HttpClient, Java HttpsURLConnection, and Go's crypto/tls all support these features

Proposed Changes

The implementation should:

1. Add the three new configuration options to specification/protocol/exporter.md
2. Update OTEP 225 configuration files (oteps/assets/0225-config.yaml and oteps/assets/0225-schema.json)
3. Follow existing patterns for per-signal configuration (traces, metrics, logs)
4. Maintain backward compatibility (all new options should be optional)

This enhancement would bring OpenTelemetry's mTLS configuration capabilities in line with industry standards and enterprise security requirements.

[marcalff]

Related:

• Add variables to support TLS version and cipher in the OTLP exporter #3088

[pellared]

Related to #4500

[svrnm]

cc @open-telemetry/configuration-approvers

From triage: A change to the spec might be needed, but SIG Config would be responsible for changing it.