NSS trust-store modification by official FINA Linux certificate client package

[certifikati]

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 secure email.