Part Number: LAUNCHCC3220MODASF
Hello all,
The section 17.1.1.4 Certificate Creation of the SimpleLink Network Processor User's Guide show a code example for the creation of a self signed certificate request based on the device internal key number 0 ( SL_NETUTIL_CRYPTO_SERVICES_IOT_RESERVED_INDEX ).
To create my self signed certificate I replaced the parameter SL_NETUTIL_CRYPTO_CSR_SAVE of the last sl_NetUtilCmd call with SL_NETUTIL_CRYPTO_CERT_SIGN_AND_SAVE.
The resulting certificate /cert/iot/cert.der is then used for an HTTP - TLS connection.
There are some things in that process that are not clear to me.
1. Specifying the Serial number seems to be ignored
The sample code specifies the serial number to 1.
/*
* set a serial number for the certificate
* this serial number must be a positive integer unique number per issuer name
* (i.e., the issuer name and serial number identify a unique certificate, every time a
* certificate is generated on a device, the serial number must be changed)
* the simplelink device allow serial number of up to 8 bytes (64bits)
*
*/
certCmd.SubCmd = SL_NETUTIL_CRYPTO_CERT_SERIAL;
certSerial = 0x00000001;
retVal = sl_NetUtilCmd( SL_NETUTIL_CRYPTO_CMD_CREATE_CERT, (uint8_t*)&certCmd, sizeof(SlNetUtilCryptoCmdCreateCertAttrib_t), (uint8_t*)&certSerial, sizeof( certSerial ), NULL, &outputLen );
if( 0 != retVal )
return retVal;
Why openssl shows a different serial number?
$ echo | openssl s_client -showcerts -connect 192.168.178.50:4711 2>/dev/null | openssl x509 -inform pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 133035896477998514 (0x1d8a37167f25db2)
Signature Algorithm: ecdsa-with-SHA1
...
I noticed that the serial number of the certificate changes every time a new one is created, regardless of the serial number specified in the software.
If the serial number is not specified with SL_NETUTIL_CRYPTO_CERT_SERIAL the creation of the certificate also works.
It is necessary to specify the serial number?
2. Comment for SL_NETUTIL_CRYPTO_CERT_SIG_TYPE does not match
The comment talks about SL_UTILS_CRYPTO_SIG_SHAwECDSA but the command uses SL_NETUTIL_CRYPTO_SIG_SHAwECDSA as parameter.
I assume that the name in the comment is wrong/ old, right?
/* * set the signature type of the certificate * the type represent the algorithm used * by the device to sign the certificate * the simplelink device support only SL_UTILS_CRYPTO_SIG_SHAwECDSA for certificate generation * */ certCmd.SubCmd = SL_NETUTIL_CRYPTO_CERT_SIG_TYPE; certSigType = SL_NETUTIL_CRYPTO_SIG_SHAwECDSA; retVal = sl_NetUtilCmd(SL_NETUTIL_CRYPTO_CMD_CREATE_CERT, (uint8_t*)&certCmd, sizeof(SlNetUtilCryptoCmdCreateCertAttrib_t), (uint8_t*)&certSigType, sizeof(certSigType), NULL, &outputLen);
3. Specification of the SL_NETUTIL_CRYPTO_CERT_SIG_TYPE
The resulting certificate is rated in the Qualys SSL Labs Rating Guide as Insecure certificate signature (SHA1), score capped at F
$ nmap --script ssl-enum-ciphers -p 4711 192.168.178.50
tarting Nmap 7.94SVN ( https://nmap.org ) at 2024-05-07 15:37 CEST
Nmap scan report for xxxxxx (192.168.178.50)
Host is up (0.0034s latency).
PORT STATE SERVICE
8443/tcp open https-alt
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - F
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - F
| compressors:
| NULL
| cipher preference: server
| warnings:
| Insecure certificate signature (SHA1), score capped at F
| TLSv1.2:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256r1) - F
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - F
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - F
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - F
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - F
| TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256-draft (secp256r1) - F
| compressors:
| NULL
| cipher preference: server
| warnings:
| Insecure certificate signature (SHA1), score capped at F
|_ least strength: F
Changing the value of SL_NETUTIL_CRYPTO_CERT_SIG_TYPE from SL_UTILS_CRYPTO_SIG_SHAwECDSA to SL_NETUTIL_CRYPTO_SIG_SHA256wECDSA results in a much better rating:
$ nmap --script ssl-enum-ciphers -p 4711 192.168.178.50
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-05-07 15:49 CEST
Nmap scan report for xxxxxxx (192.168.178.50)
Host is up (0.0032s latency).
PORT STATE SERVICE
8443/tcp open https-alt
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.1:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256-draft (secp256r1) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A
Nmap done: 1 IP address (1 host up) scanned in 43.21 seconds
Following the associated comment (see the last listing) only the value of SL_UTILS_CRYPTO_SIG_SHAwECDSA is allowed as parameter for SL_NETUTIL_CRYPTO_CERT_SIG_TYPE, not SL_NETUTIL_CRYPTO_SIG_SHA256wECDSA.
But the last one results in a better certificate rating and is working.
Can I be sure that SL_NETUTIL_CRYPTO_SIG_SHA256wECDSA will also work in future SDKs?
Perhaps the comment does not cover the current SDK versions.
Many thanks,
Roman
