[Ovmsdev] TLS CA question

Mark Webb-Johnson mark at webb-johnson.net
Thu Mar 4 13:32:18 HKT 2021


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210304/ad7da588/attachment-0001.htm>


More information about the OvmsDev mailing list