I don't think just being able to specify the cert path is good enough. I want to control how the cert validation is done and ideally I might want to control the underlying HttpClient as well. I would think this integration would wire up to DI for the GrpcChannel to pick up the HttpClient just like the HTTP side of the otlp exporter already does.

Hi @cijothomas and @alanwest,
Is there any progress on this?

Hi, we also have an use case where we need to use mTLS with OTLP, and thus need to set client certificate. Right now it's not possible to do it with GRPC.
I've made a CR to make HttpClientFactory work with GRPC also: #4625 .
The only issue that I see is that this change will not have effect on netstadard2.0 (and other .NET Framework targets). This is due to the fact that netstadard2.0 for some reason used the old Grpc.Core library which does not use HttpClient. This will create a discrepancy in API functionalities between different targets, which I'm not sure is acceptable.

I've updated the issue description to make it more clear that this issue is specifically about supporting the three TLS related OTLP configuration options that we do not yet support. Exposing the HttpClientFactory to the gRPC exporter is not part of the scope of this issue.

@matt-hensley has offered to help out with implementing these configuration options.

I currently working on a (draft) PR: #4731
Some things I'm still trying to figure out:

• How to build custom trust store with HttpClient to verify server Certificate file
• How to load PEM file (with different key algo) in .NET Framework.

Old .NET (netstandard2.0) lacks the PEM-support APIs. Parsing and loading PEM certificates and keys is quite tricky.
The only (easy) solution I've managed to find is to use BouncyCastle https://github.com/bcgit/bc-csharp. I've updated to PR with this method.
I'm wondering if we have any constraints for using in dependency libraries?

Curious about the status of this issue, saw that above pr is closed. Do we support exporting over tls now?

If no one is working on this, can I work on this? I'd like to take this issue up

We have a production use case that would benefit from #4731 What is needed to revive that PR and not have it die in bureaucracy again? @varkey98 looks like you can take it. I see no other initiative that got as far as #4731 or anybody willing to pick it up.

Hi! Me and @sokoide are going to create PRs accordingly.

Reopening, as I understand we have now only infrastructure for the real implementation?

@Kielek Yep, I am working on the 2nd PR to add mTLS :)