Platform Science · SRE · Change assessment
FMCSA ELD Web Service Certificate Renewal
None of our three FMCSA submission clients pins the server certificate or uses a hand-curated truststore, so all three fall under FMCSA's "Standard Client Implementations" case. Certificate Transparency logs show the likely replacement certificates were already issued in September 2026 by the same intermediate CA we validate against today.
The one recommendation: watch FMCSA submission errors on cutover day. The same certificate family was involved in FMCSA's March 2026 rollout problems (ICC-722).
The FMCSA notice
FMCSA will renew the TLS server certificate for the ELD Output File Submission Web Service (eldws.fmcsa.dot.gov) on October 28, 2026, under the same public CA hierarchy as the current certificate.
| Client type | FMCSA guidance | Applies to us? |
|---|---|---|
| Standard: OS root store or default TLS library trust | No action required | Yes, all three |
| Pinning of the leaf certificate, public key or serial | Update the pin before cutover | No |
| Custom keystore or truststore of hand-picked server certs | Import the issuing CA before cutover | No |
Systems in scope
Three clients submit USA ELD output files to FMCSA's SOAP endpoint. Each authenticates with mutual TLS (our PS5000 client certificate) and validates FMCSA's server certificate against a standard root store.
eld-transfer and asclepius-pdf are PS services (PS Enterprise / PS HOS); eFS is the Trimble-acquired PS Plus product, owned by the Sticks team. Submission happens only for USA, type=output, transfer_method=web requests; email and Canadian transfers do not touch this endpoint.
Code review findings
All three clients send our own client certificate for mutual TLS and leave server-certificate validation to the platform default. None pins a certificate or supplies its own CA list.
| Client | Code location | Server-cert validation | Pinning / custom truststore |
|---|---|---|---|
eld-transferNode 20.19.3 ( node:20.19.3-alpine) | pltsci-asclepius@eld-transfer-main: packages/eld-transfer/src/eldTransferCompiledHosReportSnapshoter.ts:644 | soap package ClientSSLSecurity(key, cert), no ca argument, so Node's bundled public root store is used | None |
asclepius-pdfNode 18 ( node:18-alpine3.18) | pltsci-asclepius@orion-main: packages/asclepius-pdf/Snapshoter/CompiledHosReportSnapshoter.ts:477 | Same pattern as eld-transfer | None |
| eFS / PS Plus .NET Framework 4.7.2, WCF | PeopleNet/compliance.legacy.efleet-host: ELDDataFileWebSubmitter.cs, ELDDataFileSubmissionClient/app.config | wsHttpBinding, transport security with a client certificate only; Windows root store decides trust | None no endpoint <identity>, no ServerCertificateValidationCallback on this path |
How we checked:
- Searched both asclepius branches for
rejectUnauthorized,checkServerIdentity,NODE_EXTRA_CA_CERTS,NODE_TLS_REJECT_UNAUTHORIZED,--use-openssl-caand fingerprint matching. The only hit isrejectUnauthorized: falseinentity-state-search/seedHeartbeatDocs.ts, an Elasticsearch seed script unrelated to FMCSA. - Searched efleet-host for WCF server-identity settings and certificate validation callbacks. The one callback found, in
NavmanServerNetworkModule/SendMessageManager.cs, belongs to a separate Navman messaging module, not the FMCSA client. - Not reviewed: the
eld-transferHelm values ondeploy-eld-transfer-main, which could in principle setNODE_EXTRA_CA_CERTS. An extra-CA variable only adds trust, so it could not cause a failure.
Current endpoint certificate
The certificate served today expires November 10, 2026, so October 28 is a routine early renewal. The server sends the full chain, and it validates (Verify return code: 0).
| Position | Subject | Issuer | Valid |
|---|---|---|---|
| Leaf | prd-eld-2025.fmcsa.dot.govSANs: eld.fmcsa.dot.gov, eldws.fmcsa.dot.gov | Entrust OV TLS Issuing RSA CA 2 | 2025-11-10 to 2026-11-10 |
| Intermediate | Entrust OV TLS Issuing RSA CA 2 | Sectigo Public Server Authentication Root R46 | 2024-12-11 to 2027-12-10 |
| Root | Sectigo Public Server Authentication Root R46 | Self-signed, in client trust stores | — |
Observed with openssl s_client -connect eldws.fmcsa.dot.gov:443 -showcerts on 2026-10-23. This certificate has been live since roughly November 2025 and our clients submit against it routinely, so the Sectigo R46 root is already trusted by each of them. Today's error rates were not re-checked for this assessment.
Certificate Transparency evidence
Two certificates already cover eldws.fmcsa.dot.gov, both issued in September 2026 by Entrust OV TLS Issuing RSA CA 2, the intermediate in today's chain. One of them is most likely what goes live on October 28.
| Issued | Expires | Common Name | Issuer | SANs |
|---|---|---|---|---|
| 2026-09-18 | 2027-04-04 | prod-external-2026.dot.gov | Entrust OV TLS Issuing RSA CA 2 | 57 |
| 2026-09-09 | 2027-03-26 | prod-external2-2026.fmcsa.dot.gov | Entrust OV TLS Issuing RSA CA 2 | 56 |
- No new certificates in the last 14 days. No
prd-eld-2026-style ELD-only certificate has been issued. - The Common Name will probably change from the ELD-specific
prd-eld-2025.fmcsa.dot.govto a shared certificate covering about 57 FMCSA/DOT hostnames. No impact for us: none of our clients pins, and hostname checks match on the SAN list, which includeseldws. - Re-check before cutover with
zsh scripts/fmcsa/fmcsa-ct-check.sh --days 14(sre-toolkit). A new certificate from a different issuer would invalidate the "same hierarchy" premise.
Sources: crt.sh for fmcsa.dot.gov and crt.sh for eldws.fmcsa.dot.gov, queried 2026-10-23.
Risks
The main risk is on FMCSA's side, not ours: a rollout fault there would hit every ELD vendor, us included, regardless of client configuration.
| Risk | Likelihood | Impact | Basis |
|---|---|---|---|
| FMCSA rollout fault (wrong or expired cert served, broken chain, connection resets) | Low to medium | USA roadside web transfers fail; asclepius-pdf has no retry, eld-transfer retries 3 times | March 2026 (ICC-722): FMCSA deployed prod-external-2026.dot.gov and we saw certificate has expired across 12 tenants within an hour, then sustained read ECONNRESET |
| New certificate chains to a root missing from an old client image | Low | Affected service cannot validate FMCSA | FMCSA states the same hierarchy; CT shows the same intermediate. The Node 18 image on asclepius-pdf is the oldest trust store in scope |
| Our own client certificate (PS5000) expires | Not this event | All submissions fail | Expires 2027-05-10; unrelated to this renewal but worth tracking |
Recommended actions
No code or configuration changes are needed. What remains is a pre-cutover check and cutover-day monitoring.
- Re-run the CT check and confirm any new
eldwscertificate is issued by Entrust OV TLS Issuing RSA CA 2 — SRE, by Oct 27, 2026 - On cutover day, confirm the served certificate changed:
openssl s_client -connect eldws.fmcsa.dot.gov:443 -servername eldws.fmcsa.dot.gov -showcerts— SRE, Oct 28, 2026 - Watch PS submission errors (
eld-transfer,asclepius-pdf) forcertificate has expired,unable to verify the first certificate,UNABLE_TO_GET_ISSUER_CERT,read ECONNRESET— SRE, through Oct 29, 2026 - Ask the eFS owners (Sticks team) to watch
service:eFleetSuiteDataFile *Could not establish trust*in Datadog's TTM org — SRE to notify, Oct 28, 2026 - Fix
fmcsa-ct-check.sh(crt.sh JSON with escaped newlines crashed the parser) — done in sre-toolkit
If errors appear, escalate per the sre-toolkit FMCSA escalation path (docs/fmcsa-eld-submission.md). In March, escalation through a large carrier's FMCSA contact got a same-day fix; direct FMCSA support took days.
Open questions for review
- Does FMCSA's notice give a cutover time of day? It names only October 28, which sets the monitoring window.
- Are any other PS or Trimble-acquired ELD products submitting to
eldws.fmcsa.dot.govbeyond the three reviewed here? - Should cutover-day monitoring be a scheduled check or a manual watch by the on-call engineer?
- Do we want a standing freshness monitor on FMCSA submission success rate, so an FMCSA-side fault alerts us before customers report it?