Re: [EXTERNAL] Re: INC8119596 Other | Entrust Certs and DHS
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. > 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 > > *Sent:* Saturday, November 23, 2019 7:24 PM > > *To:* O'Donnell, Derek > > *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/Cer
RE: [EXTERNAL] Re: INC8119596 Other | Entrust Certs and DHS
Peter, 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?? Regards, Jim Bowen (Contractor) Trusted Internet Connection (TIC) Gateway Operations Lead Veterans Affairs Network Security Operations Center (VA NSOC) 221 Butler Street | Building 511 | Martinsburg, WV 25405 304-262-7745 (Office) | 571-439-4434 (Mobile) Confidentiality Note: This e-mail is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Dissemination, distribution, or copying of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail in error, please notify the sender by reply e-mail, and destroy the original message and all copies. From: Peter Bowen Sent: Saturday, November 23, 2019 7:24 PM To: O'Donnell, Derek Cc: dev-security-policy@lists.mozilla.org; Bowen, James E. 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 mailto: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 <https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt> 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 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [EXTERNAL] Re: INC8119596 Other | Entrust Certs and DHS
On Mon, Nov 25, 2019 at 7:10 AM Bowen, James E. 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 > *Sent:* Saturday, November 23, 2019 7:24 PM > *To:* O'Donnell, Derek > *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
RE: [EXTERNAL] Re: INC8119596 Other | Entrust Certs and DHS
Hi Peter – Thank you for responding to our inquiry. Unfortunately, this particular customer has specifically chosen to use this type of certificate for a few years as they feel it provides better security. Trying to get them to move to a commercial certificate available to the Public would not work for them. The next course of action may be to speak with DHS about this and seeing what they say. Again, thank you for the response on this as it does provide some more insight into this situation. Please enjoy the rest of your weekend. Respectfully, Derek O’Donnell (Contractor) NOC Gateway Operations – QuarterLine Infrastructure Operations (IO) IT Operations and Services (ITOPS), Office of Information and Technology (OIT) Office (304) 262-5282 T-S From: Peter Bowen Sent: Saturday, November 23, 2019 7:24 PM To: O'Donnell, Derek Cc: dev-security-policy@lists.mozilla.org; Bowen, James E. 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 mailto: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 <https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt> 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 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
