Why does certutil -dspublish -f rootcacert.cer RootCA make the HTTPS site trusted on a domain-joined Windows client, but not on a Linux client?
Publishing the root certificate into Active Directory lets Group Policy push it into every domain member's trusted root store; the Linux client is not in the domain, so the root never reaches its trust store.
The offline root CA is not joined to the domain, so AD knows nothing about it at first. certutil -dspublish … RootCA writes the root certificate into AD's configuration partition (the Certification Authorities container). Domain members pull that container during Group Policy processing and add the certificate to their Trusted Root Certification Authorities store, which is why the lab asks for a client restart or new logon. From then on Windows can build the chain web server certificate, then CKTECK CA, then the root, and Edge shows the site as secure.
The Debian client never sees AD. Its trust store is /etc/ssl/certs (built from Mozilla's public CA list by ca-certificates), plus each browser's own store. A private company root is not in there, so the chain ends at an unknown root and the browser warns. To fix it, copy the root certificate to /usr/local/share/ca-certificates/ and run update-ca-certificates (Firefox may need it imported separately).
The general lesson: a certificate is only "trusted" relative to a trust store, and a private PKI has to distribute its root to every client itself.
Go deeper:
Microsoft Learn: certutil — the -dspublishverb and itsRootCA,SubCAandNTAuthCAtargets.- Wikipedia: Root certificate — what a trust anchor is and how it gets into a store.