SPWF04SA: Certificate Error: 11 trying to connect to AWS IoT

[Yongliang Zhan]

Posted on December 13, 2017 at 17:05

Hi,

I am attempting to establish an MQTT connection with mutual TLS authentication to a AWS IoT Endpoint.

The command I use is

AT+S.MQTTCONN=♯♯♯♯♯.iot.eu-west-1.amazonaws.com,443,,2,,,,,,,,

(I only paste the hostname partially for security reasons).

There seems to be some issue validating the server-side certificate, since we always receive the following error:

AT-S.Certificate Error:11

According to UM2114, the error means Parsing the signature failed, but I fail to understand which certificate (client, server or ca) is failing.

I have already a

dded the AWS IoT root certificate, client certificate and client private key into the filesystem, according to the convention specified in AN4963 (tls.cert, tls.key and <auth-id>.ca files).

It may be worth mentioning that even if no certificates are loaded, the same error is still shown; this leads me to believe the failure should occur when parsing the server certificate.

Is the problem caused by my wrong usage? Or is it a failure of the module?

?

Attached I send the certificate chain the endpoint sends and a screenshot with the result of AT+S.STS, hoping they may be useful.

Many thanks

#spwf04s #mqtt #iot #aws

[Gerardo GALLUCCI]

Posted on December 14, 2017 at 11:16

Can you please load certs into flash at this stage? This way the subject key id is managed by module itself.

Once solved, we can move back to filesystem.

Please attach the output for all TLSCERT and MQTT commands.

[Yongliang Zhan]

Posted on December 14, 2017 at 12:13

Hi Gerardo,

Thanks for the quick reply.

Here are screenshots of the commands and outputs you mentioned.

Please do tell me when you need any more information.

P.S.: In case it may somehow affect the result, I should note I'm using minicom in instead of recommended TeraTerm as my application of choice in order to establish the Serial connection via USB.

The certificates, private key (all in PEM format) and subjectId are loaded via the command 'cat tls.cert > /dev/ttyACM0' when minicom is pending data.

________________ Attachments : tlscert.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyFu&d=%2Fa%2F0X0000000b53%2FnoAOAQa1.jMclrKnw8livRGuMHZ7E123DQWhMsALtps&asPdf=falsemqttconn.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyFl&d=%2Fa%2F0X0000000b52%2FKpch7UrAqyc7ZETWtfG7RAokAMz7n0rmxraMuGKvlak&asPdf=false

[Gerardo GALLUCCI · Accepted solution]

Posted on December 18, 2017 at 10:18

After some investigations, we found the issue. Current TLS implementation is not able to use mixed ECC and RSA certificates. Used (here) root CA is signed by RSA, while certificate is ECDSA based.

Thanks for catching it. Has been signaled to developers team, and hopefully will be solved into next FW revision. In the meanwhile, please try to used an homogeneous certificates chain.

[VChur.1]

and still nothing in firmware to resolve the problem... Gerardo GALLUCCI (ST Employee) what next?