Subject: NSS trust-store modification by official FINA Linux certificate client package
Dear Mozilla Security Policy Community, I am writing to ask whether the following behavior is considered acceptable from a Mozilla/NSS trust-store governance and transparency perspective. This is not a report about a newly mis-issued TLS certificate, and I am not claiming malicious intent. The issue concerns local NSS certificate database modification by official Linux client software distributed for use with FINA digital certificates / signature services in Croatia. The concern is that this is not merely optional third-party desktop software. The package is distributed through the official FINA/RDC software path and appears to be part of the practical workflow required for using FINA certificates/signature services on Linux. ## Package artifact Package analyzed: SignErgyFina_v3.21.003.deb Package SHA-256: e0a71eee1eda124378015b672a9c0e0a135c4f9c7a23e7d26697eb5bcc3ebea6 Official downloaded ZIP SHA-256: 6b4b975987f88393295d7793953ab5ed4f5c2db9a7d090c45a2db30cf1f465cf The .deb extracted from the official FINA/RDC Linux ZIP and an independently preserved analyzed .deb matched byte-for-byte. ## Summary of observed behavior Static inspection of the Debian package maintainer scripts shows that the postinst script searches broadly from the filesystem root for NSS certificate databases, including: cert8.db cert9.db It then uses certutil -A to add the following certificates into discovered NSS databases: AssecoSEEHR_AuthIssuingCA2 AssecoSEEHR_RootCA2 Observed trust flags were: CT,C,C The package also copies certificate/configuration/library files into system locations, including: /usr/share/ca-certificates/extra/AssecoSEEHR_AuthIssuingCA2.cer /usr/share/ca-certificates/AssecoSEEHR_RootCA2.cer /etc/eToken.conf /usr/lib/libWebSecTechDll.so The installer also extracts a bundled Java runtime archive, jre.tar.gz, into: /usr/bin and appends a URI handler entry to: /usr/share/applications/defaults.list The package removal script does not appear to fully undo several of these changes. Cleanup lines related to certificates, /usr/bin/JRE, and libWebSecTechDll.so appear to be commented out. ## Disposable VM reproduction I reproduced the behavior in a disposable Ubuntu VM using QEMU. The package installed and purged successfully when expected desktop tooling was present. After installation, the following NSS entries appeared: AssecoSEEHR_AuthIssuingCA2 CT,C,C AssecoSEEHR_RootCA2 CT,C,C These entries were observed in NSS databases under: /root/.pki/nssdb /root/.mozilla/firefox/test.default /root/.thunderbird/test.default-release After package purge, the same NSS certificate entries remained present in those NSS databases. After package purge, the following system files also remained: /usr/share/ca-certificates/extra/AssecoSEEHR_AuthIssuingCA2.cer /usr/share/ca-certificates/AssecoSEEHR_RootCA2.cer /etc/eToken.conf /usr/lib/libWebSecTechDll.so ## Documentation transparency concern I searched the available user-facing documentation for terms including: certutil trust store Thunderbird ca-certificates eToken.conf libWebSecTechDll /usr/share /etc /usr/lib I did not find clear disclosure describing the specific installer behavior of modifying NSS databases, browser/mail-style trust stores, system CA certificate paths, /etc/eToken.conf, or /usr/lib/libWebSecTechDll.so. General documentation about certificate use or manual certificate import is not equivalent to an installer automatically modifying local NSS certificate databases. ## Why I believe this is relevant here I understand that local certificate import does not require Mozilla root-store approval, and I am not claiming that this is the same as inclusion in Mozilla’s built-in root store. The concern is narrower: Official/required certificate client software appears to programmatically modify local NSS certificate databases used by Firefox/Thunderbird-style profiles, outside Mozilla’s built-in default root-store path, through a broad filesystem search, without clear user-facing disclosure, and without complete rollback after package purge. The specific question I would like to raise is: Is this considered acceptable behavior for official CA/QTSP-related client software: using Debian maintainer scripts to search for NSS databases, add CA certificates with certutil -A, and leave those trust entries after package purge, where the affected trust-store behavior is not clearly disclosed to the user? I have preserved the official archive, package hashes, extracted maintainer scripts, documentation search results, and disposable-VM before/after/purge logs. Report archive SHA-256: 421241dd4e2b1420776de674a05dc5af7892fc9737162057833a5d1eb241d8ca I can provide a smaller redacted evidence bundle or specific excerpts if that is useful, but I did not want to send large attachments to the list. I would appreciate guidance from the community and Mozilla Root Program Managers on whether this behavior is in scope for Mozilla/NSS trust-store governance discussion, and whether there is a recommended reporting path for this type of local NSS trust-store modification by official certificate client software. Sincerely, Independent Security Researcher Sent with [Proton Mail](https://proton.me/mail/home) secure email. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/3HJ6f9KZNCRHPI5a5VjY65oy6LqN9qdLoA5x3_5ubo6nwzou8nSCeE3VEnfpoJVl2XDWbJEAwzLHxGnNjebZmfs2pGbHGHohQQGQzRUM5Pw%3D%40proton.me.
