Yeah, there's something amiss with how you're analyzing the issue here - whether an entrust.com or entrust.net domain is in use shouldn't matter.
More generally, Mozilla is unlikely to add any root certificates whose expected uses don't contain a significant public-facing component. The root store is about public trust, not easing internal enterprise IT operations. DHS relies on the Mozilla root store for their scans because they only scan internet-accessible systems, which they generally assume should be using publicly trusted certificates. (I used to work closely with this team when I worked for GSA, and created GSA's own HTTPS scanning system that formed the initial basis for DHS' scans.) There's no rule saying VA can't run a staff-facing system that is also internet-accessible - in fact, it'd be great to hear that the VA is moving away from relying on an intranet as a security boundary. But either way, if the system in question is exclusively used by laptops and devices which can reliably be expected to have the relevant certificate installed, and there are no users who you're forcing to click through certificate warnings to use the service, you could make an argument to DHS that you're compliant with the relevant directives. But there are many federal services that try to use a non-publicly trusted certificate for services which have a slice of public users, and federal IT shops frequently make incorrect assumptions about how reliably custom root certificates are installed on devices that have to use that service. Because of this, agencies usually can't be trusted to self-attest that no public users are affected by the use of a non-publicly trusted certificate. DHS' scans are optimized to protect the public users of federal services. So if I was DHS, I would ask you to prove that by using HSTS preloading for the relevant second-level domain, which blocks users from clicking through certificate warnings. (Dynamic HSTS won't be good enough, because the server-delivered HSTS policy would never be trusted by affected clients.) If you're talking about va.gov, that second-level domain has so many subdomains that it may be challenging to establish an HSTS preload policy, since it would enforce HTTPS strictly for every single va.gov subdomain. If that's not feasible, then I would strongly recommend VA use a publicly trusted certificate for the affected service - I don't think VA's sense that their government certs are more trustworthy than public certs is accurate. VA is likely already dependent on the security of public CAs for most or all of its public web services already, since anyone who gets a publicly trusted cert for a va.gov hostname can use it to intercept traffic to that service, whether or not the VA CIO has chosen to use a publicly trusted certificate themselves. On Mon, Nov 25, 2019 at 1:29 PM Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Nov 25, 2019 at 7:10 AM Bowen, James E. <james.bo...@va.gov> > wrote: > > > DHS is only using Mozilla’s trust store for determining trust. They are > > not using a government-based trust store. > > > > > > > > We talked to Entrust last week. Entrust was creating certificates with “ > > entrust.net” as the old way. Recently, Entrust has been generating > > certificates with “entrust.com” as their current and preferred method. > > > > > > > > We want to get the entrust.com domain added to Mozilla’s trust store, so > > DHS scans don’t come back with false positives. What is the process of > > getting entrust.com added to Mozilla’s trust base?? > > > > The Mozilla trust list is not based on domains, rather it is based on > specific CAs which is identified by the Issuer Name + Public key. Mozilla > (and presumably DHS) do follow chains of certificates, so if the direct > issuer is certified by a trusted CA, then the certificate is trusted. > > If you provide the full issuer name for the certificate you are referring > to, then it might be possible to determine if you are actually on a > government-only certificate or if you have some other issue. > > Thanks, > Peter > > > > > > > > > > > > > > *From:* Peter Bowen <pzbo...@gmail.com> > > *Sent:* Saturday, November 23, 2019 7:24 PM > > *To:* O'Donnell, Derek <Derek.O'donn...@va.gov> > > *Cc:* dev-security-policy@lists.mozilla.org; Bowen, James E. < > > james.bo...@va.gov> > > *Subject:* [EXTERNAL] Re: INC8119596 Other | Entrust Certs and DHS > > > > > > > > On Sat, Nov 23, 2019 at 1:08 PM O'Donnell, Derek via dev-security-policy > < > > dev-security-policy@lists.mozilla.org> wrote: > > > > We have a customer at the VA who uses an Entrust root: > > Issuer Entrust > > > > AIA: > > > http://nfitestweb.managed.entrust.com/AIA/CertsIssuedToNFIMediumSSPCA.p7c > > > > They are repeatedly flagged by DHS for not using a trusted certificate > and > > using a self-signed certificate. DHS uses Mozilla Trust Store. > > > > Taking a look at the following file: > > > > > https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/bu > > iltins/certdata.txt, we can see that everything pertaining to Entrust end > > in > > .NET. > > > > The Entrust CA our customer uses ends in .COM. Both extensions are the > > same > > thing. How can we have the .COM certificate added Globally to Mozilla's > > Trust Store? This will resolve the issues being reported by DHS for us. > > Any help on this would be greatly appreciated. > > > > > > > > Hi Derek, > > > > > > > > Entrust Datacard runs a number of different CAs. The various CAs are > > intended for various purposes. > > > > > > > > The CA you are using is intended for government-only applications. The > > CAs that are included in the Mozilla Trust Store are intended for citizen > > or business-facing applications. It sounds like DHS is recommending that > > you use a certificate that is designed for citizen or business-facing > > applications. I would talk to Entrust Datacard or another CA in the > > Mozilla Trust Store to see about getting a new certificate. > > > > > > > > Thanks, > > > > Peter > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Eric Mill 617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
