Changes for Cert Injection - #3460
Conversation
prajesh-gupta
left a comment
prajesh-gupta
left a comment
There was a problem hiding this comment.
Reviewed against the behaviour we measured across dev, stage and prod for TE-22997. Overall this reads well — the Android network_security_config warning and the device-pool FAQ are exactly the things customers get wrong, and it's good to see them called out prominently.
Four items I'd treat as blocking, all verified rather than assumed:
- The upload curl does not work — the field is
media_file, notfile(lines 126, 140) - The upload response example is wrong — there is no
media_idkey (line 161) - "A failed certificate does not fail your session" is true for a partial failure only; a total failure refuses the session (line 306, and the manual page line 131)
- The
.pfxpassword section contradicts itself — required at upload, optional in capabilities (lines 289, 362)
Plus one that will generate support tickets: the iOS verification path points at VPN & Device Management, where MDM-delivered certificates do not appear (manual page line 201).
Details inline.
| <CodeBlock className="language-bash"> | ||
| {`curl -u "${YOUR_LAMBDATEST_USERNAME()}:${YOUR_LAMBDATEST_ACCESS_KEY()}" \\ | ||
| -X POST "https://api.lambdatest.com/mfs/v1.0/media/upload" \\ | ||
| -F "file=@/Users/macuser/Downloads/corp-root-ca.crt" \\ |
There was a problem hiding this comment.
Blocking — this curl fails. The upload field is media_file, not file.
Run against prod just now:
-F "file=@..." -> {"type":"error","title":"Bad Request",
"message":"No file has been selected. Please try again"}
-F "media_file=@..." -> {"media_url":"lt://MEDIA...","name":"ca-root.cer","status":"success"}
Step 1 is the first thing a reader copies, so this stops them at the door. Same fix needed on line 140 (the .pfx tab).
| <CodeBlock className="language-bash"> | ||
| {`curl -u "${YOUR_LAMBDATEST_USERNAME()}:${YOUR_LAMBDATEST_ACCESS_KEY()}" \\ | ||
| -X POST "https://api.lambdatest.com/mfs/v1.0/media/upload" \\ | ||
| -F "file=@/Users/macuser/Downloads/client-identity.pfx" \\ |
There was a problem hiding this comment.
Same as line 126 — -F "file=@..." needs to be -F "media_file=@...", otherwise the upload is rejected with "No file has been selected".
|
|
||
| ```json | ||
| { | ||
| "media_id": "MEDIA9f2c4b18a7d54e3ba0c6f19d2e8b7c05", |
There was a problem hiding this comment.
The response shape is wrong. There is no media_id key. Actual response:
{"media_url": "lt://MEDIAbc3a1e5207d549b1a6808bcefd979905",
"name": "ca-root.cer",
"status": "success"}As written, the page tells the reader to take media_id from a response that does not contain it. The id to reference is the value of media_url.
Worth adding that both forms work as certificateId — the full lt://MEDIA... and the bare MEDIA... used in the capability examples below. I tested both; the bare form starts a session fine, so the examples are correct, just not obviously connected to what upload returns.
| Certificates are installed **after the app is installed and before your test starts**. Each certificate reports its own status in the **session logs** on the Automation dashboard, so you can see exactly which ones installed successfully. | ||
|
|
||
| :::info | ||
| If a certificate fails to install, your session **does not fail**. The session starts and your test runs, so you can decide whether the missing certificate affects the scenario you are testing. |
There was a problem hiding this comment.
This is not true for a total failure, and that is the case a customer is most likely to hit.
Tested on stage: a .pfx referenced with a wrong password fails the certificate stage and the session is refused — 3 of 3 attempts, HTTP 500, no session. That matches FR-A11 and Prajesh's confirmation: "if the pass is wrong the injection would fail and we would get lambda error."
What is true is partial failure: one good certificate plus one that cannot install starts normally, and the good one installs and is trusted (verified on stage).
Suggest splitting the two, e.g.:
If some of your certificates fail to install, the session still starts and your test runs; each certificate reports its own status. If none of them can be installed, the session is refused.
As written, a customer whose only certificate fails waits for a session that never arrives while the docs say it should start. Same wording on the manual page, line 131.
| Each certificate in the list shows the platforms it applies to, what it installs as (for example, **Client identity** for a `.pfx` bundle), and when it was uploaded. Use **Search certificates** to find a certificate quickly. | ||
|
|
||
| :::info | ||
| If a certificate fails to install, the session **still starts**. Each certificate reports its own status, so you can check which ones installed successfully before you begin testing. |
There was a problem hiding this comment.
Same as the automation page (line 306): true for a partial failure, not for a total one. If the only certificate cannot be installed the session is refused rather than starting — verified on stage with a wrong-password .pfx.
| - Certificates are delivered to the device as a **managed configuration profile**, installed and trusted without any manual step on the device. | ||
| - A `.mobileconfig` file keeps its own identifier and payload, so a profile that you have already validated in your own environment behaves the same way here. | ||
|
|
||
| To confirm that a profile is present, go to **Settings** > **General** > **VPN & Device Management** on the device during your session. |
There was a problem hiding this comment.
This sends customers to a screen where the certificate does not appear.
MDM-delivered certificates do not show as their own row under VPN & Device Management — they fold into the Enrollment Profile. We hit this during testing: the screen looked empty and it read as a failed install, when the certificate was present and trusted the whole time. It was visible under Settings > General > About > Certificate Trust Settings, toggle on and greyed out (greyed = MDM-enforced, which is the expected state).
Suggest pointing at Certificate Trust Settings, and noting that an empty VPN & Device Management screen is normal rather than a sign of failure. This will otherwise generate "my certificate didn't install" tickets for certificates that installed correctly.
| - A **CA certificate** is added to the device's user trust store, under a name derived from your filename. Existing trusted certificates on the device are not removed. | ||
| - A **PKCS#12 identity** is installed into the device keystore and then granted to the app under test. On Android, an app cannot access a key unless it has been granted access to it. | ||
|
|
||
| To confirm that a CA certificate is present, go to **Settings** > **Security** > **Encryption & credentials** > **Trusted credentials** > **User** on the device during your session. |
There was a problem hiding this comment.
Minor: this path is Pixel/AOSP wording. On Samsung it is Settings > Biometrics and security > Other security settings > User certificates (and the CA list is "Display trusted CA certificates").
Worth a parenthetical, since Samsung is a large share of the Android estate — we lost a run to exactly this wording difference.
| | **Device type** | Real devices only (`isRealMobile: true`) | | ||
| | **Platforms** | Android and iOS | | ||
| | **Session types** | App Automation, App Testing (Manual) | | ||
| | **Certificates per session** | Up to 3 | |
There was a problem hiding this comment.
The 3 per session limit is enforced per request, not per session.
The manual page's "Manage Certificates During a Test Session" section describes installing further certificates mid-session — so the two pages together describe a supported route to more than 3 on one device (3 at launch + 3 more in-session).
Either the limit should be described as per request, or the in-session install should be documented as counting toward the same 3.
|
|
||
| | Extension | What it is | Installs as | Platform | Password | | ||
| |---|---|---|---|---| | ||
| | `.crt` `.cer` | A CA or server certificate | Trusted CA certificate | Android, iOS | Not used | |
There was a problem hiding this comment.
Two additions worth considering for this table:
Formats. The API accepts seven extensions — .cer .crt .pem .der .pfx .p12 .mobileconfig — while the dashboard offers four. That is a deliberate split (Akshay: "FE will not cater this but will work with API"), but this is the API-facing page, so .pem, .der and .p12 arguably belong here, or a line saying they are API-only.
Expiry. An expired certificate is rejected at upload with a dated message ("expired on 1 Jan 2021. Upload a certificate that is still valid."). Not-yet-valid certificates are accepted. That is real behaviour customers will hit and it is not documented anywhere on either page.
|
|
||
| <RealDeviceTag value="Real Device" /> | ||
|
|
||
| Many apps connect to servers that use certificates issued by a private or corporate certificate authority. Some apps also pin a **self-signed certificate**, or present a **client certificate** to authenticate themselves before a server will respond. On a standard device, these connections fail because the device does not trust your organization's certificates. |
There was a problem hiding this comment.
acceptInsecureCerts is not mentioned on either page, and it shipped alongside customCertificates in this same ticket.
The two are easy to confuse and do very different things — customCertificates changes the device trust store and is real-device app-automation only; acceptInsecureCerts is a W3C WebDriver capability that only tells the browser context to proceed past an untrusted certificate, and touches no trust store.
A short section, or even a note saying which one to reach for, would head off customers picking the wrong one.
- Upload field is media_file, not file (both cURL examples and the request parameters table) - Upload response returns media_url (lt://MEDIA...), not media_id; corrected the example and the certificateId description - Clarify .pfx password: required at upload, optional in capabilities. Removes the contradiction with the tip below it and the limits table - Describe the 3-certificate limit as per session request / at launch, and note that further certificates can be installed in-session - Add a note distinguishing customCertificates from acceptInsecureCerts Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3 participants
No description provided.