Skip to content

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

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

Description

@igor-luhan
igor-luhan
opened on Aug 20, 2026

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.
[

Image Image

](url)

Activity

  1. metsma commented on Aug 24, 2026

    @metsma
    metsma
    on Aug 24, 2026
    Contributor

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

  2. igor-luhan commented on Aug 24, 2026

    @igor-luhan
    igor-luhan
    on Aug 24, 2026
    Author

    qdigidoc4_4.11.0.5421_diagnostics.txt

  3. metsma commented on Aug 24, 2026

    @metsma
    metsma
    on Aug 24, 2026
    Contributor

    Can you enable opensc log and post this?

  4. igor-luhan commented on Aug 24, 2026

    @igor-luhan
    igor-luhan
    on Aug 24, 2026
    Author

    opensc_debug.log

  5. metsma commented on Aug 24, 2026

    @metsma
    metsma
    on Aug 24, 2026
    Contributor

    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.

  6. igor-luhan commented on Aug 24, 2026

    @igor-luhan
    igor-luhan
    on Aug 24, 2026
    Author

    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.

  7. metsma commented on Aug 24, 2026

    @metsma
    metsma
    on Aug 24, 2026
    Contributor

    Now when fixed does diagnostics show something better here:

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

  8. igor-luhan commented on Aug 24, 2026

    @igor-luhan
    igor-luhan
    on Aug 24, 2026
    Author

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

  9. metsma commented on Aug 24, 2026

    @metsma
    metsma
    on Aug 24, 2026
    Contributor

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

  10. igor-luhan commented on Aug 24, 2026

    @igor-luhan
    igor-luhan
    on Aug 24, 2026
    Author

    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.

  11. metsma commented on Aug 24, 2026

    @metsma
    metsma
    on Aug 24, 2026
    Contributor

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

  12. igor-luhan commented on Aug 24, 2026

    @igor-luhan
    igor-luhan
    on Aug 24, 2026
    Author

    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.

  13. igor-luhan commented on Aug 24, 2026

    @igor-luhan
    igor-luhan
    on Aug 24, 2026
    Author

    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.

  14. metsma
    added a commit that references this issue on Sep 15, 2026

    Show SSL warning when Qt does not have working TLS plugin

    d7663bf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions