• Registered: 2024-10-02
  • Posts: 2

Topic: certificate validation on an IoT device

Hi WolfSSL team,

typically IoT devices have limited memory and you can only store limited certificates in flash memory (unlike modern phones, Laptop, browsers, high-end linux devices,  etc).

Currently when I see https://www.wolfssl.com/documentation/m … ter07.html and "Certificate Chain Verification" section it says a device just need to store "A" (root CA) and all intermediate certs are not required.

as of today, when server is sending A (root) > B (intermediate) > C(Intermediate) > D (Server Cert). When we load just A in the device, connection is successful and everything works ok.  However, as some users may say A keeps changing and we should load B or C (intermediate) as it is more safer.


1. Is this implementation in accordance to RFC?  what part of RFC does this comply to that we need to absolute load "A"?
2. What changes are needed in embeddedSSL if we just need to validate using B or C?
3. from a security perspective, I understand both are secure and loading A does not mean it is more secure, but isnt B or C more likely to be revoked rather than A?
5. if there are multiple flavors of B and C, wouldn't it be safer to just load A and let device validate B/C/D through chain validation?
5. do we know if all the SSL clients operate same way (openSSL, mbedTLS, etc)?

Share

  • From: Mobile, AL
  • Registered: 2013-12-11
  • Posts: 352

Re: certificate validation on an IoT device

Hi wirediot,

Welcome to the wolfSSL Forums. Could you tell us a bit about your project using wolfSSL and where you are located for our support records?

The default cert verification logic in wolfSSL is more stringent (secure) than other SSL libs in that we require the root CA to be loaded, as opposed to verifying the peer cert based on any cert that matches. You can loosen this requirement by enabling the define WOLFSSL_ALT_CERT_CHAINS.

https://github.com/wolfSSL/wolfssl/blob … .c#L33-L37
* WOLFSSL_ALT_CERT_CHAINS:
*     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.

So to answer your questions:

1. Is this implementation in accordance to RFC?  what part of RFC does this comply to that we need to absolute load "A"?

Yes

2. What changes are needed in embeddedSSL if we just need to validate using B or C?

See discussion above.

3. from a security perspective, I understand both are secure and loading A does not mean it is more secure, but isnt B or C more likely to be revoked rather than A?

Root certs are much less frequently revoked, but it can happen. Which is why things like OCSP exist.

5. if there are multiple flavors of B and C, wouldn't it be safer to just load A and let device validate B/C/D through chain validation?

Yes!

5. do we know if all the SSL clients operate same way (openSSL, mbedTLS, etc)?

They are definitely different.

Thanks,
Eric - wolfSSL Support

embhorn's Website

Share

  • Registered: 2024-10-02
  • Posts: 2

Re: certificate validation on an IoT device

Welcome to the wolfSSL Forums. Could you tell us a bit about your project using wolfSSL and where you are located for our support records?
>> answered in PM

Thanks for quick response.

Can you please give me some details on item #1/2.  I see TLS1.2/1.3 RFC. It says rootCA on server response is a "MAY" but it has  underlying assumption that client device already possess root CA in order to validate.

so you are saying that by enabling " WOLFSSL_ALT_CERT_CHAINS" we technically avoid storing "A(root cert)" and store either B or C in our device and and still validate the chain. Is that correct?  (though it is not default logic and not as stringent).
Are there any security issues with doing this?

certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

Share

  • From: Mobile, AL
  • Registered: 2013-12-11
  • Posts: 352

Re: certificate validation on an IoT device

I've requested our business director, Scott McClung, to reach out to set up a call with our engineers. Please keep an eye out for an email.

Thanks,
Eric - wolfSSL Support

embhorn's Website

Share