Topic: aws and No CA signer to verify with

I'm trying to connect to aws. I have loaded 4 certificates. The first 2 as root certificates, the others client and key certificates.
But I received the message "No CA signer to verify with".
These certificates are correct because on another platform with these certificates, I'm trying to connect.
Do you have any suggestions, please?
Thank you.

Share

Re: aws and No CA signer to verify with

Hi Isabella,

My name is Anthony and I am a member of the wolfSSL team.  I will be helping you with this issue.  This happens quite often when connecting to large web infrastructures.  Please use --enable-altcertchains on your configure command line. If you don't use the confugre script, please define WOLFSSL_ALT_CERT_CHAINS in your user_settings.h .

Here at wolfSSL we love learning about how people are using our libraries.  Can you please tell me a bit about yourself, your use case and any other information that would give us some context so that we can better help you?

Warm regards, Anthony

Share

Re: aws and No CA signer to verify with

anthony wrote:

Hi Isabella,

My name is Anthony and I am a member of the wolfSSL team.  I will be helping you with this issue.  This happens quite often when connecting to large web infrastructures.  Please use --enable-altcertchains on your configure command line. If you don't use the confugre script, please define WOLFSSL_ALT_CERT_CHAINS in your user_settings.h .

Here at wolfSSL we love learning about how people are using our libraries.  Can you please tell me a bit about yourself, your use case and any other information that would give us some context so that we can better help you?

Warm regards, Anthony

Using this #define, can cause issues to the connection to infrastructures that doesn't need this #define?What does this #define different?Thank you.

Share

Re: aws and No CA signer to verify with

Hi Isabelle,

https://datatracker.ietf.org/doc/html/r … tion-4.4.2 has the following pragraph:

Note: Prior to TLS 1.3, "certificate_list" ordering required each
   certificate to certify the one immediately preceding it; however,
   some implementations allowed some flexibility.  Servers sometimes
   send both a current and deprecated intermediate for transitional
   purposes, and others are simply configured incorrectly, but these
   cases can nonetheless be validated properly.  For maximum
   compatibility, all implementations SHOULD be prepared to handle
   potentially extraneous certificates and arbitrary orderings from any
   TLS version, with the exception of the end-entity certificate which
   MUST be first.

Without WOLFSSL_ALT_CERT_CHAINS we expect the proper ordering and no other extra certificates.  With WOLFSSL_ALT_CERT_CHAINS we follow the guidance above.

Warm regards, Anthony

Share