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:

• https://github.com/open-telemetry/opentelemetry-specification/pull/3088

[pellared]

Related to https://github.com/open-telemetry/opentelemetry-specification/pull/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.

[jack-berg]

but SIG Config would be responsible for changing it.

Why? If you generalize this guidance, the config SIG is responsible for driving all config of all spec components. We're not experts on all components of the spec. We're experts on the consistent modeling of config options in JSON schema, and interpreting that data model to produce SDK components.

Anyone should feel empowered to make spec changes related to configuration.

We should get in the habbit (or mandate) simultaneous modeling of spec config changes in opentelemetry-configuration so the changes can be evaluated holistically.

[sandy2008]

Our mTLS PR got merged in https://github.com/open-telemetry/opentelemetry-python/issues/3327 (Python) & https://github.com/open-telemetry/opentelemetry-dotnet/pull/6343 (.NET), and we have similar requests for adding this spec as well, hopefully we can accelerate this process.

[svrnm]

Why? If you generalize this guidance, the config SIG is responsible for driving all config of all spec components. We're not experts on all components of the spec. We're experts on the consistent modeling of config options in JSON schema, and interpreting that data model to produce SDK components.

My comment was referring to the later, not that SIG configuration needs to drive the specifics of mTLS configuration, but that such a change needs to be consistent with the existing configuration options, i.e. the PR suggests the addition of environment variables, but I suspect this should be a spec change related to configuration.

So if I understand it correctly, instead of suggesting new environment variables like OTEL_EXPORTER_OTLP_CERTIFICATE_REVOCATION_FLAGetc, those should be defined as config first?