TLS issue with OTLP exporter

[stephenhong]

Describe the bug

Hello team, I've been using Otel collector v0.94 and recently updated to v0.103. My collector config includes an OTLP exporter and had no issues with v0.94 but after updating to v0.103, I started to see tls related error message

Steps to reproduce

Using OTLP exporter with Otel collector v0.94 produces no tls related errors Using OTLP exporter with Otel collector v0.103 produces tls related errors

What did you expect to see?

No tls related errors

What did you see instead?

tls related errors

warn        zapgrpc/zapgrpc.go:193        [core] [Channel #3 SubChannel #6]grpc: addrConn.createTransport failed to connect to {Addr: "##.##.##.##:####", ServerName: "some-endpoint.com:####", }. Err: connection error: desc = "transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate is not valid for any names, but wanted to match some-endpoint.com"        {"grpc_log": true}

If I add tls: insecure: true in the config, I get the following error

warn        zapgrpc/zapgrpc.go:193        [core] [Channel #3 SubChannel #6]grpc: addrConn.createTransport failed to connect to {Addr: "##.##.##.##:####", ServerName: "some-endpoint.com:####", }. Err: connection error: desc = "error reading server preface: EOF"        {"grpc_log": true}

If I add tls: insecure_skip_verify: true in the config, I get the following error

warn        zapgrpc/zapgrpc.go:193        [core] [Channel #1 SubChannel #6]grpc: addrConn.createTransport failed to connect to {Addr: "##.##.##.##:####", ServerName: "some-endpoint.com:####", }. Err: connection error: desc = "error reading server preface: http2: frame too large"        {"grpc_log": true}

What version did you use?

v0.103

What config did you use?

exporters: otlp: endpoint: some-endpoint:####

Environment

AmazonLinux2-x64

Additional context

[cbvbs]

I'm also seeing this issue. Did you happen to find a fix?

[carlos4ndre]

Also having the same issue, both otlp and otlphttp exporters.

I'm using v0.108.0, and setting insecure_skip_verify to true works for me, but this is not desirable.

To add more context, this was only tested with SPIFEE certs, and the lack of CN or SAN in the cert itself might explain this behaviour (see https://github.com/istio/istio/issues/42114).