Client cert auth does not verify that cert/key/ca are consistent

[cfcs]

• see comment by @hannesm #32 (comment)
• I think this should be patched in the config parser somewhere
• The problem is that when we are given a ca (Ca), cert (Tls_cert), key (Tls_key) we do not validate that:

1. cert is issued by ca
2. key is the private key of cert

It would be cleaner if the config parser could complain with a helpful message to assist the user debug their faulty config.

[hannesm]

from the openvpn manpage, I gather the following:

• --ca may contain multiple certificates (not clear to me whether this should be a single chain or a set of trust anchors -- likely the latter): This file can have multiple certificates in .pem format, concatenated together. -- we are assuming a single certificate here.
• --capath is an alternative, pointing to a directory of trust anchors. afaict we don't support this (mbed-tls only, unclear whether this is mutually exclusive with ca)
• --extra-certs another file with a list of certificates (the intermediates)

--> I guess the chain cert :: extra-certs should be signed by some trust anchor in ca/capath. not clear what to send over the wire (cert only, or cert :: extra_certs?), and what to verify against (expect from the server), ca or received_cert :: extra_certs against CA?

--> but I've never seen anyone using extra_certs (nor capath), we can defer this to a later point when someone actually has a use case for this :)

[cfcs]

Same re: extra certs.

[hannesm]

from the list above, (2) has been implemented in #79.

The verification of a correct certificate chain rooted in CA/CA_path/extra_certs is still up in the air, I'll describe the missing parts in a separate issue (since it's pretty intricate, and includes research to figure out what openvpn does).