feat(server/tls): add support for multiple CAs

[OverOrion]

This PR allows one to configure multiple CAs for their WEC server.

Given the following scenario:

• Root CA
• CA1 and CA2, both signed by Root CA - intermediate certificate authorities
• Client1 and Client2 - each signed by their respective CA (CA1, CA2)

This requires the WEC server to return the proper (CA) thumbprint for each client.

I do have the following questions:

1. During my tests Windows clients only sent their peer certificate, not including the intermediate CA. Is it a known Windows behavior/quirk?
   RFC 5246 - 7.4.2 says:

certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.

But based on DSP0226) - C.3.5 http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/https/mutual it says the following:

Client connects with no authorization header but supplies an X.509 certificate.

This matches with my observed behavior, but wanted to confirm nevertheless.

2. Is using the issuer field a proper way to identify certificate entities? I think it is enough, as the file is controlled by the user and they should be aware of its' contents. Nevertheless there is a warn for duplicates, and a hard error for same issuers, but different thumbprints.

[vruello]

Hi!

During my tests Windows clients only sent their peer certificate, not including the intermediate CA. Is it a known Windows behavior/quirk?

I'm not aware of this, but that would not be very surprising.

Is using the issuer field a proper way to identify certificate entities? I think it is enough, as the file is controlled by the user and they should be aware of its' contents. Nevertheless there is a warn for duplicates, and a hard error for same issuers, but different thumbprints.

It looks like you used the certificates subject to check for duplication (and not the issuer). I think this approach is okay.

However, I'm unsure about the method you used to retrieve the appropriate thumbprint for the client. As I understand it:

• we retrieve the client peer certificates and only take the first one (

  openwec/server/src/lib.rs

  Line 1002 in fd5cf96

  let cert = stream

  )
• we try to find a CA subject that matches the issuer field of this certificate, and panic otherwise.
• we retrieve the thumbprint of the matching CA certificate.

If the client properly sends a full certificates chain, the server will panic if it does not trust the first intermediate authority, even if it trusts a parent authority in the chain.

I think we should try to find a matching CA within all the client peer certificates, and raise an error if we cannot find one (rather than panicking). Does this approach seem reasonable to you?

[vruello]

Looks like the variable should be named subject?

[OverOrion]

Hey @vruello!

Thank you for the quick review, I appreciate it!

It looks like you used the certificates subject to check for duplication (and not the issuer). I think this approach is okay.

Yes, sorry for the confusion, I meant it from the peer's perspective. Yes, the subject field is used as a key.

If the client properly sends a full certificates chain, the server will panic if it does not trust the first intermediate authority, even if it trusts a parent authority in the chain.
I think we should try to find a matching CA within all the client peer certificates, and raise an error if we cannot find one (rather than panicking). Does this approach seem reasonable to you?

Absolutely, will change the PR accordingly, thank you!

[vruello]

Looks good to me, thanks @OverOrion! :)