Steve,

Mea culpa.

Here is the main cert:

X509v3 Subject Alternative Name:
  DNS:*.openvehicles.com, DNS:openvehicles.com
Issuer: C=LV, L=Riga, O=GoGetSSL, CN=GoGetSSL RSA DV CA
Validity
  Not Before: Feb 11 00:00:00 2020 GMT
  Not After : Feb 10 23:59:59 2022 GMT

Then the intermediate certs:

Subject: C=LV, L=Riga, O=GoGetSSL, CN=GoGetSSL RSA DV CA
Issuer: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
Validity
  Not Before: Sep  6 00:00:00 2018 GMT
  Not After : Sep  5 23:59:59 2028 GMT

Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
Validity
  Not Before: May 30 10:48:38 2000 GMT
  Not After : May 30 10:48:38 2020 GMT

It seems the second intermediate certificate has expired, and that is perhaps the problem you are seeing?

Very annoying. I really hate it when certificate authorities issue certificates signed by intermediate CA certificates, or trusted roots, that expire before the certificate itself.

AddTrust has already issued a new intermediate cert which expires in 2038, and have managed to get that in as a trusted CA in most modern browsers. It is in my server’s bundle for older browsers, and is also in the OVMS firmware as a trusted CA. I guess wolfssl and mbedtls behave differently in this situation (where the same certificate is provided as a trusted CA as well as in the bundle, but with different expiration dates). Either that, or mbedtls is not verifying expired intermediate certs  😱

I replaced that certificate on my server, and now see:

Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
Issuer: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
Validity
  Not Before: Feb  1 00:00:00 2010 GMT
  Not After : Jan 18 23:59:59 2038 GMT

A test now looks ok:

$ openssl s_client -connect api.openvehicles.com:6870

CONNECTED(00000005)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = LV, L = Riga, O = GoGetSSL, CN = GoGetSSL RSA DV CA
verify return:1
depth=0 CN = *.openvehicles.com
verify return:1
---
Certificate chain
 0 s:/CN=*.openvehicles.com
   i:/C=LV/L=Riga/O=GoGetSSL/CN=GoGetSSL RSA DV CA
 1 s:/C=LV/L=Riga/O=GoGetSSL/CN=GoGetSSL RSA DV CA
   i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
   i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority

Can you try again? See if you still get an error?

Regards, Mark.

On 4 Mar 2021, at 12:52 PM, Stephen Casner <casner@acm.org> wrote:

Your server api.openvehicles.com on port 6870.

On Thu, 4 Mar 2021, Mark Webb-Johnson wrote:

What site (and port) are you trying to access?

On 4 Mar 2021, at 12:09 PM, Stephen Casner <casner@acm.org> wrote:

Mark,

Thanks for that reply.  As I mentioned, if I don't configure
WOLFSSL_ALT_CERT_CHAIN then I get an "ASN no signer to confirm"
error.  Do you have any idea why that might be?  That is, am I likely
to be missing access to some key?  Of some key not being present in a
cert when it should be there?

                                                      -- Steve

On Thu, 4 Mar 2021, Mark Webb-Johnson wrote:

Steve,

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).

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.

I don't think we should set WOLFSSL_ALT_CERT_CHAIN.

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.

Regards, Mark.

On 4 Mar 2021, at 9:00 AM, Stephen Casner <casner@acm.org> wrote:

I find that I need to enable the following option in my testing of the
possible replacement of MEDTLS with WolfSSL, otherwise I get an "ASN
no signer to confirm" error:

 WOLFSSL_ALT_CERT_CHAIN allows CA's to be presented by peer, but
 not part of a valid chain. Default wolfSSL behavior is to require
 validation of all presented peer certificates. This also allows
 loading intermediate CA's as trusted and ignoring no signer
 failures for CA's up the chain to root. The alternate certificate
 chain mode only requires that the peer certificate validate to a
 trusted CA.

Is that expected for the trust arrangements we are using?

A possibly related question: do we expect the server to validate
clients, or only the clients to validate the server?

                                                     -- Steve
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev