[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