[Ovmsdev] TLS CA question
Stephen Casner
casner at acm.org
Thu Mar 4 15:10:47 HKT 2021
Mark,
Thanks. That fix avoids the signature error. I still have the
problem that the TLS handshake gets only part way through and then the
network task gets locked up for 90 seconds. It's not always in the
same place in the log, but since ~100 log messages get lost when this
occurs, I can't be sure where it happens. It could be a timing
dependency between a couple of events such that in some circumstances
a blocking operation is executed.
-- Steve
On Thu, 4 Mar 2021, Mark Webb-Johnson wrote:
> Steve,
>
> Mea culpa.
>
> Here is the main cert:
>
> X509v3 Subject Alternative Name:
> DNS:*.openvehicles.com, DNS:openvehicles.com <http://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 <http://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 at 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 at 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 at 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 at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
More information about the OvmsDev
mailing list