Does Ubuntu have an authoritative finite list of TLS certificate trust backends used by applications?

I am trying to understand Ubuntu’s TLS certificate trust architecture at a general level.

By “trust backend” I mean the mechanism or certificate store an application uses to decide whether a server TLS certificate chains to a trusted CA.

I have encountered several mechanisms on Ubuntu, including:

  • the Ubuntu system CA store (/etc/ssl/certs, ca-certificates)

  • NSS certificate databases

  • Firefox/Mozilla profile or policy-based certificate handling

  • p11-kit / PKCS#11 trust

  • Java cacerts / Java KeyStores

  • application-bundled or private/custom CA stores

I am not assuming that these are six completely independent backend technologies; some may overlap or be management/isolation layers around another backend.

My questions are:

  1. Does Ubuntu define a finite, authoritative number of TLS certificate trust backends?

  2. Is the list above exhaustive, or can applications use additional/custom trust mechanisms?

  3. Should Snap and Flatpak be counted as separate trust backends, or are they isolation environments that can contain private instances of an existing backend such as NSS?

  4. Is Mozilla/Firefox technically a separate backend, or mainly an NSS-based store with Mozilla-specific profile/policy management?

I am especially interested in answers backed by Ubuntu documentation, upstream documentation, or source code.

I just did one as it’s a very broad topic.

  1. To my knowledge limiting the amount of authoritative point of truths which get verified, goes against the principle how CA’s function and why a good number of them exist in the first place.
    This has to do with the fact client side (us) has to trust the CA’s is acting in best faith and is not compromised.
    This exchange is almost purely based on trust which is a very fickle concept in security.

    So the best way to increase certainty in trust is to have not a single authoritative source but enough authoritative sources in agreeing even statistic anomaly’s and single compromised sources have no impact and don’t erode the certainty of the trust.
    It is a very common happening a CA gets compromised but the fact we have 20 other keeping agreeing they can take collective action to exclude the compromised CA until it’s deemed thrust wordy again.
    It has also happend multiple times a CA is acting is bad fait for extended time like a government trying to attack the trust and they got barred permanently.

    So there is probably a practical limit in how many you can store on a file system but there is no good excuse to define one.