Hi,
We want to setup HTTPS server to do LTE module FOTA with self-signed CA for verification. But we see that AT+QFOTADL command supports HTTPS server but we don’t know how to configure our self-signed CA. Could you tell how to do LTE module FOTA using self-signed CA? BTW, I have referred following document: [At1]Quectel_EG800Q&EG91xQ_Series_DFOTA_Upgrade_Guide_V1.3.pdf. Thanks.
Dear @WangNan ,
Thank you for reaching out and providing the details.
AT+QFOTADL supports downloading a DFOTA package from an HTTP(S) URL. For HTTPS, the key requirement is that the module must be able to verify the HTTPS server certificate. This is done by loading your trusted certificate (your self-signed CA certificate, or the self-signed server certificate if you are using a single self-signed certificate) into the module file system and then configuring the module SSL parameters so the HTTPS connection can validate the server.
Recommended approach is:
- Prepare the trusted certificate in PEM format.
- If your HTTPS server certificate is signed by your own CA, use the CA certificate.
- If the server uses a single self-signed certificate, use that server certificate as the trusted certificate.
-
Upload the trusted certificate to the module UFS (file system) as a certificate file.
-
Configure the SSL parameters to enable certificate verification and point to the trusted certificate file using the SSL configuration commands (AT+QSSLCFG and related parameters such as TLS version/security level, if required).
-
Trigger DFOTA using AT+QFOTADL with your HTTPS URL, for example:
AT+QFOTADL=“https:///<dfota_package>” -
Monitor progress using the FOTA URCs (+QIND: “FOTA”, …). Please ensure the module has stable power throughout the download and upgrade process.
Also, please make sure the hostname used in the HTTPS URL matches the certificate, and that the module time is valid for certificate date checking. These are the most common reasons HTTPS verification fails.
If you share your module firmware version (AT+QGMR) and whether your HTTPS URL uses a domain name or an IP address, we can confirm the exact SSL parameter set needed for your setup.
Best regards,
Aghelan
Thank you very much for your reply. Here is module firmware version: Quectel EG915Q-JP Revision - EG915QJPLGR01A05M04. Currently our HTTPS URL uses an IP address and maybe in the future, we will use domain name. Could you provide the exact SSL parameter configuration for both HTTPS URLs for AT+QSSLCFG in detail? In your approach, there is still one question: how to upload the trusted certificate to the module UFS (file system)? Thanks again.
BRs.
Dear @WangNan ,
Thanks for the update and the firmware version (EG915QJPLGR01A05M04).
For HTTPS DFOTA with a self-signed CA, the module must trust your server certificate chain. This is achieved by storing the trusted CA certificate in the module file system (UFS) and then configuring the SSL parameters with AT+QSSLCFG. After that, you can trigger the DFOTA download with AT+QFOTADL using the HTTPS URL.
-
How to upload the trusted certificate into UFS
Please prepare the trusted certificate in PEM format:
-
If your HTTPS server certificate is signed by your own CA, use the CA certificate (recommended).
-
If you are using a single self-signed server certificate, use that server certificate as the trusted certificate.
Upload it to the module UFS using AT+QFUPL. Depending on firmware, AT+QFUPL may request only the filename, or it may require filename together with size/timeout. Please use the exact syntax shown by your module when you run AT+QFUPL=? and follow the module prompt:
AT+QFUPL= (your filename and optional parameters)
CONNECT
(send the complete PEM file content)
+QFUPL: < resul t>,< filesize >
OKAfter upload, you will reference the certificate as a UFS file (for example, UFS:cacert.pem).
-
Exact SSL parameter configuration (works for both IP URL and domain URL)
Please run this first on your module so we use only the parameters and value ranges supported by EG915QJPLGR01A05M04:
AT+QSSLCFG=?Then configure one SSL context ID (for example, context ID 1) using only items that appear in your AT+QSSLCFG=? output. The required items for server verification are:
a) Bind the trusted CA certificate file
Set the CA certificate file path to the UFS file you uploaded, for example:
AT+QSSLCFG=“cacert”,1,“UFS:cacert.pem”b) Enable server certificate verification
Set the security/verification level to the mode that verifies the server certificate using the CA certificate. The exact numeric value depends on your firmware and will be listed in AT+QSSLCFG=? output:
AT+QSSLCFG=“seclevel”,1,Do not select a mode that requires a client certificate/private key unless your HTTPS server is configured for mutual TLS.
c) Select TLS version supported by your server (recommended: TLS 1.2)
Choose the TLS version value from your AT+QSSLCFG=? output (use the value that corresponds to TLS 1.2 if your server supports it):
AT+QSSLCFG=“sslversion”,1,d) Time validation
If you keep certificate date checking enabled, the module time must be correct for certificate validity checking. If your test environment does not have reliable time, use the option in AT+QSSLCFG to ignore local time checking (only if it exists in your AT+QSSLCFG=? output):
AT+QSSLCFG=“ignorelocaltime”,1,<0 or 1 per your requirement>e) Cipher suites (optional)
If you see handshake failures due to cipher mismatch, set ciphersuite according to the options available in AT+QSSLCFG=? (some firmwares allow “all supported ciphers” via a special value). -
IP address URL vs domain name URL (what changes)
The SSL configuration steps above are the same. The main difference is the certificate identity requirement:
-
If you use an IP address in the HTTPS URL, the server certificate must include that IP address in the certificate Subject Alternative Name (SAN), otherwise verification will fail.
-
If you use a domain name in the HTTPS URL, the server certificate must include that domain name in CN/SAN, and using a domain name is generally recommended for certificate verification.
If your AT+QSSLCFG=? output includes an SNI option, you may enable it when using a domain name and your server uses virtual hosting. If SNI is not listed in AT+QSSLCFG=?, please ignore it.
-
Start DFOTA
After the trusted CA is uploaded and SSL parameters are configured, trigger DFOTA with:
AT+QFOTADL=“https:///<dfota_package>”Please keep the power supply stable throughout the download and upgrade, and monitor the DFOTA progress URCs (+QIND: “FOTA”, …) to confirm download and update status.
If you can share the output of AT+QSSLCFG=? from your EG915QJPLGR01A05M04 unit and confirm whether your server is “server-auth only” (typical) or requires mutual TLS, we can map the exact numeric values for seclevel and sslversion directly to your firmware’s supported list.
Best Regards,
Aghelan
Hi,
Thank you very much for your detail description. After executing AT+QSSLCFG=?, we get following output:
There is one thing that we need to verify. For SSL context ID, the context ID range is 0–5. Which one should I use(you use context ID 1), or can I freely assign any context ID within this range in the SSL parameter configuration? Thank you.
BRs.
Dear @WangNan ,
Thank you for sharing the AT+QSSLCFG=? output.
Based on your output, each AT+QSSLCFG parameter is defined with an SSL context ID range of 0–5 (for example, “sslversion”,(0–5), “seclevel”,(0–5), “cacert”,(0–5), “sni”,(0–5), etc.). This means you can choose any context ID within 0–5 for your SSL parameter configuration.
Please select one context ID (for example, 1) and then apply all required SSL settings using that same ID consistently (cacert path, seclevel, sslversion, ciphersuite, ignorelocaltime, and other items you need).
Best Regards,
Aghelan
