DigiDoc4 does not detect ID-card token on Linux despite working PC/SC and OpenSC PKCS#11 layer (ACS ACR38U)

[igor-luhan]

Summary

DigiDoc4 client shows "No card in card reader; check if ID-card is inserted correctly" and cannot detect an inserted Estonian ID-card, even though the card is fully readable at the PC/SC and OpenSC/PKCS#11 level. Tested with two physical readers of the same model — same result on both.

Environment

• OS: Ubuntu 24.04 (noble), amd64
• qdigidoc4: 4.10.0.5402-2404 (also reproduced after full purge + reinstall from RIA repo, latest candidate 4.11.0.5421-2404)
• libdigidocpp: 4.4.0.8411-2404
• opensc / opensc-pkcs11: 0.27.1-0RIA2
• Reader: ACS ACR38U-CCID (00 00) — tried two separate units of this same model, identical behavior
• Card: Estonian ID-card, IDEMIA-issued, ATR 3B DB 96 00 80 B1 FE 45 1F 83 00 12 23 3F 53 65 49 44 0F 90 00 F1 (matches the app's own IDEMIACard::ATR_COSMO8 pattern, so the card type is recognized as supported)

Steps to reproduce

1. Insert the ID-card into the reader.
2. Open qdigidoc4, go to "My eID" or try to sign a document.
3. App shows "No card in card reader; check if ID-card is inserted correctly" / "Connect the card reader to your computer and insert your ID-card into the reader".

Expected behavior

Card and certificates should be detected and available for signing.

Diagnostics already performed (all point to the app, not the OS/driver stack)

• pcsc_scan: reader and card detected correctly, ATR decodes as "Estonia ID-card (eID)".
• pkcs11-tool --module /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -L: lists all 4 slots correctly with token label LUHAN,IGOR,35605030197 (PIN1/PIN2), manufacturer IDEMIA.
• pkcs15-tool --list-certificates: successfully reads both certificates (Isikutuvastus and Allkirjastamine) directly from the chip.
• Confirmed opensc-pkcs11.so is not registered in the ldconfig cache (bare filename lookup fails); worked around by setting an explicit full path in /etc/digidocpp/digidocpp.conf:

  <param name="pkcs11.driver.path" lock="false">/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so</param>
  

  After this change, qdigidoc4's console output confirms the module loads ("opensc-pkcs11.so" loaded library, and C_GetInfo output showing OpenSC Project (2.20) / OpenSC smartcard framework (0.27)), and the reader is now shown in the app — but the card itself is still reported as absent.
• digidocpp.log at debug level (log.level=4) shows nothing beyond routine TSL loading; no PKCS#11/card-related entries at all, even while reproducing the failure.
• QT_LOGGING_RULES="*=true" verbose run: only one app-level log line appears, qdigidoc4.QSigner: Card change detected, with no further detail about why the token is then treated as absent. (Note: the app also prints repeated "Unimplemented code." to stdout, but this turned out to be unrelated Qt/AT-SPI accessibility-bridge noise triggered by the verbose logging flag itself, not a PKCS#11 error — it appears interleaved with mouse-motion/window-paint events, not card/token operations.)
• Full purge (apt purge qdigidoc4 libdigidocpp-common libdigidocpp-dev libdigidocpp-tools libdigidocpp1) + deletion of /etc/digidocpp, ~/.config/RIA, ~/.digidocpp + reinstall from the RIA repo (now on 4.11.0.5421-2404): no change in behavior.
• Tried a second reader unit of the identical ACS ACR38U-CCID model: identical failure.

Conclusion

Everything below the application (pcscd, OpenSC, PKCS#11 module, the card itself) works correctly and can read both certificates. qdigidoc4 detects a "card change" event but then silently concludes no card/token is present, with no diagnostic output explaining why.
[

](url)

[metsma]

Can you send SettingsDialog diagnostic output? you can remove personal code from output.

[igor-luhan]

qdigidoc4_4.11.0.5421_diagnostics.txt

[metsma]

Can you enable opensc log and post this?

[igor-luhan]

opensc_debug.log

[metsma]

This is intresting:
qt.tlsbackend.ossl: Incompatible version of OpenSSL (built with OpenSSL >= 3.x, runtime version is < 3.x)
Ubuntu 24.04 ships OpenSSL 3.0 and I see you have Qt 6.4.2 and this seems also correct.

[igor-luhan]

Root cause: System has two OpenSSL installations side by side — the system package (3.0.13) and a locally-built legacy copy (1.1.1) registered in /usr/local/ssl/lib via ldconfig. The qdigidoc4 binary itself links correctly against the system libssl.so.3 (confirmed via ldd, matches OpenSSL version: 3.0.13 reported by digidocpp in the log). However, Qt's TLS backend plugin (qopensslbackend) loads OpenSSL dynamically via dlopen() rather than static linking, and picks up the older 1.1.1 .so from /usr/local/ssl/lib since it appears earlier in the ldconfig search path.

Impact: This only affects Qt's own network stack (QNetworkAccessManager), not digidocpp/OpenSC, which call OpenSSL directly. It did not appear to affect card detection or certificate reading in this environment — likely an environment-specific artifact of a local OpenSSL 1.1 build on this machine, not a qdigidoc4/digidocpp bug per se.

[metsma]

Now when fixed does diagnostics show something better here:

Libraries:
QT (6.4.2)
OpenSSL build ()
OpenSSL current ()

[igor-luhan]

However I removed old SSL (/usr/local/ssl/lib) and now DigiDoc4 works.

[metsma]

I just want know maybe we can generate some kind error in digidoc next time

[igor-luhan]

Thanks for flagging this — I'm happy to help dig further, but I don't quite follow what you're asking here. Could you clarify what you'd like me to check or provide? For example:

Are the empty OpenSSL build () / OpenSSL current () fields from qdigidoc4's own diagnostics screen (Help → Diagnostics), or from somewhere else?
Is this a regression compared to before the ld.so.conf fix, or was it already like this?
What specifically would you like me to run/check next?

Happy to gather whatever logs or command output would help once I understand what you're looking for.

[metsma]

Can you paste these lines now from diagnostics, did the output change when you fixed it?

[igor-luhan]

Yes, the output changed after the fix. Before, both fields were empty:

OpenSSL build ()
OpenSSL current ()

After removing the stray /usr/local/ssl/lib OpenSSL 1.1.1 path from ldconfig (registered via /etc/ld.so.conf.d/openssl-1.1.1k.conf, a leftover from an old manual OpenSSL build), the diagnostics now show:

QT (6.4.2)
OpenSSL build (OpenSSL 3.0.13 30 Jan 2024)
OpenSSL current (OpenSSL 3.0.13 30 Jan 2024)

So Qt's TLS backend now correctly detects OpenSSL 3.0.13, matching what digidocpp itself reports. This confirms the earlier qt.tlsbackend.ossl: Incompatible version warning and the empty version fields were both caused by the conflicting local OpenSSL 1.1.1 installation on this machine, not a qdigidoc4 bug. The original card-detection issue was separately traced to the app window opening on a secondary display that wasn't visible — no qdigidoc4/digidocpp issue after all.

[igor-luhan]

Sorry for this sentence: "The original card-detection issue was separately traced to the app window opening on a secondary display that wasn't visible — no qdigidoc4/digidocpp issue after all.". It is not related to our case.