• State Verified Answer
  • Replies 5 replies
  • Subscribers 87 subscribers
  • Views 270 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 358193
Options

AT%CMNG types 0 and 1 always fail on nRF9151-SMA-DK — error 527

Ibraim

Board: nRF9151-SMA-DK

Modem firmware tested: mfw_nrf9151-ntn_1.0.0-1.alpha and mfw_nrf91x1_2.0.4

nRF Connect SDK version: 3.2.1 Host OS: Windows 11

Problem description:

I am trying to provision TLS certificates for AWS IoT Core onto the nRF9151-SMA-DK modem using AT%CMNG. The Private Key (type 2) writes successfully every time, but Root CA (type 0) and Client Certificate (type 1) always fail regardless of the approach used.

What I have tried:

1. Raw AT commands via Serial Terminal

AT+CFUN=4
AT%CMNG=0,16842753,0,"-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n"
→ ERROR
AT%CMNG=0,16842753,1,"-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n"
→ ERROR
AT%CMNG=0,16842753,2,"-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----\n"
→ OK

2. Python script via pyserial Same result — type 2 succeeds, types 0 and 1 fail.

3. nRF Connect for Desktop — Certificate Manager Same result.

4. Enabled verbose errors with AT+CMEE=2

AT%CMNG=0,16842753,0,"..."
→ +CME ERROR: 527

Error 527 = "Invalid certificate content for write of type 0 or 1" per the AT commands documentation.

5. Tried multiple sec_tags (1, 100, 1000, 12345, 16842753) All return the same error 527 for types 0 and 1.

6. Tried writing a minimal fake certificate to rule out content issues

AT%CMNG=0,1,0,"-----BEGIN CERTIFICATE-----\nMIIBIjAN...\n-----END CERTIFICATE-----\n"
→ +CME ERROR: 527

Even a fake/minimal certificate body fails, so the issue is not specific to the AWS certificate content.

7. Tried AT%XSUDO authentication as per section 14 of the AT commands reference (v1.4)

  • Generated EC P-256 key pair
  • Uploaded public key via AT%XPMNG=0,"..." → OK
  • Signed the command body using SHA-256 digest + ECDSA (matching the OpenSSL steps in the documentation)
  • Sent authenticated command:
AT%XSUDO=1229,"<base64_signature>";%CMNG=0,16842753,0,"..."
→ +CME ERROR: 520

Error 520 = "Authentication failed"

Observations:

  • Type 2 (Private Key) works perfectly without any authentication on both firmware versions
  • Type 4 (PSK Identity, plain string) also works
  • Type 0 and 1 fail on every sec_tag, with every firmware version tested, with every certificate content including fake/minimal ones
  • AT%WHOAMI returns ERROR on both firmware versions
  • AT+CFUN=4 is confirmed active before all write attempts
  • The board is the SMA variant (NTN/satellite), originally shipped with mfw_nrf9151-ntn_1.0.0-1.alpha

Questions:

  1. Is AT%CMNG type 0 and 1 write intentionally restricted on the nRF9151-SMA-DK hardware?
  2. Is AT%XSUDO required for types 0 and 1 on this board, and if so, what is the exact expected signing format?
  3. Is there a known issue with mfw_nrf91x1_2.0.4 and certificate writes on the nRF9151-SMA-DK?
  4. Is there a different recommended provisioning flow for the SMA-DK variant specifically?

Any help would be greatly appreciated. Thank you!

Feel free to copy and paste this directly. The more detail you give them upfront the faster they'll be able to help. Good luck and rest well! Slight smile

Parents
  • 0

    Hi,

    Thanks for the detailed explanation.

    When you are writing a certificate using AT%CMNG=0, the 527 Error indicates a certificate formatting issue for write of type 0 or 1 as mentioned here. Instead of the \n string can you try using the actual line breaks like this:

    AT%CMNG=0, 12345678, 0,"
-----BEGIN CERTIFICATE-----
MIIDSjCCA...
...bKbYK7p2CNTUQ
-----END CERTIFICATE-----"

    Whereas %XSUDO is for future releases so that's why this seems to give the Authentication error. Try out to provision the certificate as mentioned above and let us know if it works.

     Best Regards,
    Syed Maysum

  • 0 in reply to Syed Maysum Abbas Zaidi

    Hi Syed,

    Thanks for taking the time to look at my issue. I have followed the following steps to test your sugestions:

    1. Upload the AT Commands application program from nRF Connect for Desktop and the QuickStart Options.

    2. After succesfully uploading the program I was able to connect with Serial Terminal provided on nRF Connect for Desktop as well.

    3. I tested AT commands and it worked fine.

    4. I sent the following commands on the terminal:

    > AT%CMNG=0, 12345678, 0,"
    > -----BEGIN CERTIFICATE-----
    > MIIDSjCCA
    > bKbYK7p2CNTUQ
    > -----END CERTIFICATE-----"

    5. I checked, I was sending line breaks and wrote each line on the terminal windows line per line, to be sure the terminal was sending the line breaks charecters.

    I got the same error as before: ERROR

    6. I used another terminal from the Arduino IDE that allows to select the type of ending to each command on the terminal. I tested the line break was being written but of kept getting the error.

    I don't understand why for the client private key it works whiout any problem and for the Root CA certificate and Client certificate it doesn't, when on the documentation the structure of the information seems to be the same (ASCII text):

    0 – Root CA certificate (ASCII text).
    1 – Client certificate (ASCII text).
    2 – Client private key (ASCII text).

    I appreciate if you have any other idea. Have you reproduced this same commands on your board and have they worked?

    Regards,

    Ibraim

  • +1 in reply to Ibraim

    Hi,

    Okay so Serial Terminal seems not the best tool for certificate provisioning as mentioned here that the Serial Terminal app does not properly format line breaks. And more importantly you also mentioned that you have tried Certificate Manager which should handle the formatting but that also failed.

    Before we investigate it further can you try out using nrfcredstore (command line) which is the officially recommended tool that reads directly from a .pem file as mentioned here. You already have at_client flashed, so download the Amazon Root CA 1 certificate directly from https://www.amazontrust.com/repository/AmazonRootCA1.pem, then provision it using the following commands (check link above for detailed explanation):

    nrfcredstore COM<X> list
nrfcredstore COM<X> write <sec tag> ROOT_CA_CERT AmazonRootCA1.pem

    And the modem has a specific content validation step for types 0 and 1, this is evidenced by error 527, which is defined exclusively for those types. No equivalent validation error exists for type 2, which is consistent with why the private key writes successfully even when the certificate does not.

    Please try out using nrfcredstore and let us know if it works. Thanks.

    Best Regards,
    Syed Maysum

Reply
  • +1 in reply to Ibraim

    Hi,

    Okay so Serial Terminal seems not the best tool for certificate provisioning as mentioned here that the Serial Terminal app does not properly format line breaks. And more importantly you also mentioned that you have tried Certificate Manager which should handle the formatting but that also failed.

    Before we investigate it further can you try out using nrfcredstore (command line) which is the officially recommended tool that reads directly from a .pem file as mentioned here. You already have at_client flashed, so download the Amazon Root CA 1 certificate directly from https://www.amazontrust.com/repository/AmazonRootCA1.pem, then provision it using the following commands (check link above for detailed explanation):

    nrfcredstore COM<X> list
nrfcredstore COM<X> write <sec tag> ROOT_CA_CERT AmazonRootCA1.pem

    And the modem has a specific content validation step for types 0 and 1, this is evidenced by error 527, which is defined exclusively for those types. No equivalent validation error exists for type 2, which is consistent with why the private key writes successfully even when the certificate does not.

    Please try out using nrfcredstore and let us know if it works. Thanks.

    Best Regards,
    Syed Maysum

Children
Related
Terms of service