Add API to specify a file path for TLS certificates

[seanmonstar]

It would ease usage if users could just specify a path to a certificate instead of requiring it be parsed first, such as:

let client = Client::builder()
    .certificate_file("/some/user/path")
    .build()?;

[lucab]

I'd be happier if the argument for this new API could be a std::fs:File instead of a path.

The reason is that (at least on Linux) a program can receive a file-like object as a file-descriptor from its parent or as a memfd from some peer. In both cases those file-objects have no corresponding file-system entries, thus a path-based API won't work without further workarounds.

Additional question: how does the current "pkcs12 vs pem" split fit here? Do you plan to have two separate helpers for those two cases?

[seanmonstar]

Allowing to provide a File seems fine also. I think providing a path option is important, because otherwise everyone needs to import File and call File::open and etc, when we can reduce that boilerplate.

A couple options to support both:

• Have 2 methods, certificate_file and certificate_path.
• Or have certificate_file be generic over some sealed PathOrFile trait (naming is hard).

If we can easily try both PEM and DER without the user being bother, that's probably best...

What do you think?

[lucab]

As a consumer I prefer handling file opening on my side, but I think we just have a different API taste so I won't keep arguing this further.

On the format topic, the pkcs12 has an additional mandatory parameter (the password), and that's the reason why I was asking how you want to handle the two cases. I'm not seeing right now how to make auto-detection and password input work at the same time.

[seanmonstar]

Oh right, for Identity...

Just thinking out loud here: following the thoughts in my previous comment, we could either:

• Have multiple methods, one for PEM and one for DER.
• Use a new trait such that we could pass File as PEM, and (File, &str) for DER.