It seems there’s some enhanced security in place that makes TLS certificate installation work differently to regular Linux VMs.
One of the things I noticed is default DNS resolution in Firefox uses Firefox DNS, so internal domains can’t be queried, which results in valid internal TLS certs being recognized as invalid.
But even after changing DNS to internal DNS, I still get the same problem in Firefox. I also tried disabling “Query OCSP”, that didn’t help either.
Then I imported my root CA in the browser, but even that didn’t help.
What else can be tried (short of importing each certificate individually)?
P.S. My VM is using 10.139.1.[1,2], and dom0 configuration is using actual internal servers. I wonder if I should change DNS in the VM to go directly to my internal DNS servers. Inside of the VM, internal resolution for internal hostnames does presently work. I also added several of the TLS hosts to /etc/hosts.
Also what is your actual issue?
because you talk about DNS, and certificate store. While these two things have nothing to do with each other.
DNS might have involved in the certificate checks done by the browser. - but that’s a different story. If you have such issue, you might need to share:
Also not clear if you Qubes VM is the client who runs the browser? or the server who host the website? or booth?
if you web server is in your LAN, the the Qubes internal DNS, and IPs are not play any role, as you netvm will NAT these to you (qubes) external IP - which is internal to your LAN
Qubes internal DNS only forwarding your request to your real external DNS server. Which again: can be internal to your LAN, but also can be on the internet…
Internal CA on Class C LAN with internal TLD and functioning internal DNS servers
Qubes dom0 configured to use internal DNS servers
Individual qubes configured to use Qubes-internal DNS proxy (default)
CA root cert is in /etc/ssl/private/rootA_ca.crt on each individual (guest) qube and also copied to /usr/lib/mozilla/certificates
Guest qubes can resolve internal hosts on LAN which means DNS resolution works
Inside of guest qubes, curl https://lanhost works (index.html accessed, no issue with DNS resolution and no issue with TLS), and Firefox can get to https://lanhost, but it warns about untrusted certificate (SEC_ERROR_UNKNOWN_ISSUER in FF)
That setup works fine on my other Linux OS outside of Qubes environment for both curl and FF. I know the former uses OS cert store and the latter its own, and I haven’t started comparing the latter yet, I only know that the path from the Mozilla page doesn’t seem to work in qubes.
By default a valid TLS cert was issued to host.tld won’t work if DNS (or other) name resolution isn’t functioning correctly. Try setting FF DNS over HTTPS to Max Protection and see if it resolves anything on your LAN.
Anyway, the problem seems related to FF not picking up root CA from those locations in the linked Mozilla KB, so I was just wondering if there’s some config option or enhanced security setting which requires special steps.
In the worst case I can manually import Root CA and cert chain for each host using FF (Settings > Certificates > View Certificates).
Unfortunately it’s Debian 12, but thanks for the link. I searched for the Debian equivalent and rediscovered cert9.db which on this qube is /home/user/.pki/nssdb/cert9.db and there’s another one in /rw/... (the rest is the same, as this qube persists changes in home).
I think I could edit that file with certutil to import Root CA, but I don’t have many VMs so what the hell - I just imported Root CA into Firefox manually in Authorities tab for certificates and now LAN hosts’ TLS certs are shown as trusted.
I use Ubuntu elsewhere and I can’t recall how I did it there. Perhaps I also manually imported Root CA through FF Settings.
