<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Menlo-Regular;" class="">What site (and port) are you trying to access?</span><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 4 Mar 2021, at 12:09 PM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Mark,<br class=""><br class="">Thanks for that reply. As I mentioned, if I don't configure<br class="">WOLFSSL_ALT_CERT_CHAIN then I get an "ASN no signer to confirm"<br class="">error. Do you have any idea why that might be? That is, am I likely<br class="">to be missing access to some key? Of some key not being present in a<br class="">cert when it should be there?<br class=""><br class=""> -- Steve<br class=""><br class="">On Thu, 4 Mar 2021, Mark Webb-Johnson wrote:<br class=""><br class=""><blockquote type="cite" class="">Steve,<br class=""><br class="">A thorny issue. Servers are _supposed_ to provide intermediate certificates, up to a trusted root. When you are issued a certificate, it includes a bundle of these intermediary certificates to be installed at the same time. In practice, servers are often mis-configured so they do not. This is made worse by browsers silently detecting this, then downloading the missing intermediate certificates (the child certificate contains a URL to its parent's cert).<br class=""><br class="">For Open Vehicles, I don't think we need to deal with this, and we certainly don't need the complexity of automatically downloading intermediate certificates. I think if the user wants to access a server misconfigured in that way, he can simply import and trust the intermediate certificate directly.<br class=""><br class="">I don't think we should set WOLFSSL_ALT_CERT_CHAIN.<br class=""><br class="">Regarding your question, in normal operation OVMS as a client must validate the server certificates it connect to. I don't think OVMS currently supports client certificates, although if it did we would have to correctly provide those to the server on connection.<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 4 Mar 2021, at 9:00 AM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:<br class=""><br class="">I find that I need to enable the following option in my testing of the<br class="">possible replacement of MEDTLS with WolfSSL, otherwise I get an "ASN<br class="">no signer to confirm" error:<br class=""><br class=""> WOLFSSL_ALT_CERT_CHAIN allows CA's to be presented by peer, but<br class=""> not part of a valid chain. Default wolfSSL behavior is to require<br class=""> validation of all presented peer certificates. This also allows<br class=""> loading intermediate CA's as trusted and ignoring no signer<br class=""> failures for CA's up the chain to root. The alternate certificate<br class=""> chain mode only requires that the peer certificate validate to a<br class=""> trusted CA.<br class=""><br class="">Is that expected for the trust arrangements we are using?<br class=""><br class="">A possibly related question: do we expect the server to validate<br class="">clients, or only the clients to validate the server?<br class=""><br class=""> -- Steve<br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></blockquote><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></body></html>