1

(3 replies, posted in wolfSSL)

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.

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