Symptom fingerprint
- DocuSign banner: "Certificate is not trusted by DocuSign"
- Signing dialog accepts the certificate but envelope rejects post-submit
- Same certificate validates fine in Acrobat or Word
Why this happens
DocuSign accepts certificates whose issuer chain terminates at a root on its trust list. If your CA is private, or if a recent issuance changed the intermediate, the chain can break in two ways: missing intermediate in the user's exported PFX, or a root that DocuSign does not honour for the signing flow being used.
Diagnostic workflow
Step 1. Export the end-entity certificate and inspect it
From the signer's machine, export the public certificate (not the PFX). On Windows, use certmgr.msc → Personal → Certificates. On macOS, use Keychain Access → Login → My Certificates → Export.
Step 2. Validate the chain locally
certutil -verify -urlfetch user.cerConfirms every intermediate resolves and that revocation endpoints (OCSP / CRL) are reachable. Any line beginning with ERROR identifies the broken link.
macOS equivalent: openssl verify -CAfile chain.pem user.pem
Step 3. Compare chain against DocuSign's accepted issuers
The leaf must terminate at a root accepted for the specific DocuSign flow (eSign, Standards-Based Signing, or Identify). Standards-Based Signing in particular requires AATL alignment.
Step 4. Rebuild the PFX with full chain
openssl pkcs12 -export -in user.pem -inkey user.key -certfile chain.pem -out user-full.pfxMost "not trusted" cases resolve at this step: the original PFX was exported without intermediates. The rebuilt bundle presents the complete chain to DocuSign.
Step 5. Re-import and retest
Remove the old certificate from Personal store, import the rebuilt PFX, and re-submit a test envelope. If the failure persists, escalate to the CA — the root may not be DocuSign-accepted.
Need this run live?
A consultant can drive the workflow end-to-end on a screen-shared Zoom session and produce a written remediation report you can share with IT or the issuing CA.
Windows vs. macOS differences
Windows 10 / 11
- Trust store lives in CAPI;
certutil -verifystore Rootconfirms roots. - Edge and Chrome consume the same store; Firefox uses NSS.
- WSUS-managed machines may receive different root sets.
macOS Sonoma / Sequoia
- Trust lives in the System keychain; Safari uses it natively.
- Firefox on macOS still uses NSS — verify there separately.
- CryptoTokenKit affects hardware-backed identities.
Browser-specific notes
- Edge / Chrome: consume OS trust; clear cached client cert with
chrome://restartafter re-import. - Firefox: independent NSS store; intermediates must be added under Preferences → Privacy & Security → View Certificates.
- Safari: uses macOS keychain; ensure trust settings are not overridden per-user.
Frequently asked
Why does DocuSign say my certificate is not trusted?
DocuSign validates the entire chain from your end-entity certificate up to a root it trusts. Most 'not trusted' messages mean one or more intermediate certificates are missing from the local trust store, or that the root is not on DocuSign's accepted-issuer list.
Does reinstalling DocuSign fix this?
No. The issue is in the operating system's trust store or in the certificate chain bundled with the signing identity — reinstalling DocuSign does not modify either.
Will updating Windows or macOS help?
Sometimes. Cumulative trust-store updates can ship a missing root, but they will not deliver private intermediates. A diagnostic confirms which case applies before any change is made.
Can you do this without remote access?
Yes. Sessions are screen-shared with you in control. We never take exclusive remote control, and no credentials are transmitted to us.