Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Ben Wilson via dev-security-policy]

On March 10, 2021, we began the public discussion period [Step 4 of the
Mozilla Root Store CA Application Process
] for ANF’s inclusion
request.

One commenter recounted some of ANF's certificate misissuance events and
expressed concern that CAs trusted in the Mozilla program must provide
"assurance to its users that they won't be harmed by the CA" and "a CA
which has lax technical controls, a poor understanding of PKI, and an
inability to learn from and improve when mistakes are made is at heightened
risk of exploitation by malicious actors that would harm Mozilla users."  ANF
responded

that it fully understood the context and seriousness of such matters.  This
was followed with additional concerns expressed by the commenter
,
and additional responses from ANF

.

Another community member asked about ANF's explanations of its domain
validation procedures and possible gaps / insecure implementations in those
domain validation processes.  ANF responded

to those questions and provided clarifications about its use of additional
mechanisms to address those potential gaps, including CAPTCHA, email
address construction, and use of random values.

Based on this review of the public discussion, I do not believe there are
any open action items for ANF to complete under Steps 5-8 of the
application process.

This is notice that I am closing the public discussion period [Step 9] and
that it is Mozilla’s intent to approve ANF’s request for inclusion [Step
10].

This begins a 7-day “last call” period (through April 8, 2021) for any
final objections.

Thanks,

Ben

On Wed, Mar 17, 2021 at 12:45 PM Pablo Díaz via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > - Sending a link that must be accessed to approved is known-insecure, as
> > automated mail scanning software may automatically dereference links in
> > e-mail (in order to do content inspection). Confirm/Reject buttons alone
> > shouldn't be seen as sufficient to mitigate this, as that may vary based
> on
> > how the crawler works. Requiring explicit entry of the random value is a
> > necessary "human" measure (aka similar to a CAPTCHA)
>
> We do actually have a CAPTCHA above the [CONFIRM] / [REJECT] buttons,
> which must be filled before proceeding. Is this not considered sufficient?
> I wonder because I have recently seen this same email DCV method process
> in other CAs (link that must be accessed to approve), and no captcha nor
> explicit entry of the random value is required; just “approve” button (not
> even “reject”).
> If it was deemed necessary, instead of including the RV in the link, we
> could include the RV in the email, and require the applicant explicitly
> enter this RV in the webpage.
>
> > - You haven't described how the email address is constructed for these
> > cases. The BRs only permit you to reuse the Random Value for 3.2.2.4.2,
> and
> > if and only if the domain contact is the same for all of the requested
> > domains. If, for example, you're using 3.2.2.4.4 (your #1 example), it
> > would be inappropriate if hostm...@apex1.example could approve a
> request
> > for apex2.example, yet, as currently described, that seems to be
> possible,
> > in that both hostm...@apex1.example and hostm...@apex2.example will
> > receive the same Request ID to approve/reject the request.
>
> For *each* of the domains to be included in the certificate, a email for
> DCV purpose has to be chosen from the ones the system automatically lists:
> 1) Constructed emails, using admin@, administrator@, webmaster@,
> hostmaster@, or postmaster@ + apex domain. (method 3.2.2.4.4)
> 2) Result of the WHOIS lookup previously made, for the “technical
> contact”, or “administrative contact” (method 3.2.2.4.2). The WHOIS lookup
> is performed automatically by making a query to the whois service
> corresponding to the tld. This method can only be used when there is public
> information available and the registrar/WHOIS provider has not masked it,
> otherwise, this option is not available.
>
> We do not reuse the Random Value. Each DCV email receives an independent
> email with a unique RV.
>
> Following your example, let the domains be apex1.example, apex2.example,
> and apex3.example. It would show 3 dropdown lists (one for each domain)
> with the emails to choose form:
> · apex1.example:   acceptable emails as listed above. - e.g. Chosen email
> is hostmaster @apex1.example
> · apex2.example:   acceptable emails as listed above. - e.g. Chosen email
> is admin @apex2.example
> · apex3.example:   acceptable emails as listed above. - e.g. Chosen email
> is webmaster 

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Pablo Díaz via dev-security-policy]

> - Sending a link that must be accessed to approved is known-insecure, as 
> automated mail scanning software may automatically dereference links in 
> e-mail (in order to do content inspection). Confirm/Reject buttons alone 
> shouldn't be seen as sufficient to mitigate this, as that may vary based on 
> how the crawler works. Requiring explicit entry of the random value is a 
> necessary "human" measure (aka similar to a CAPTCHA) 

We do actually have a CAPTCHA above the [CONFIRM] / [REJECT] buttons, which 
must be filled before proceeding. Is this not considered sufficient? 
I wonder because I have recently seen this same email DCV method process in 
other CAs (link that must be accessed to approve), and no captcha nor explicit 
entry of the random value is required; just “approve” button (not even 
“reject”). 
If it was deemed necessary, instead of including the RV in the link, we could 
include the RV in the email, and require the applicant explicitly enter this RV 
in the webpage.

> - You haven't described how the email address is constructed for these 
> cases. The BRs only permit you to reuse the Random Value for 3.2.2.4.2, and 
> if and only if the domain contact is the same for all of the requested 
> domains. If, for example, you're using 3.2.2.4.4 (your #1 example), it 
> would be inappropriate if hostm...@apex1.example could approve a request 
> for apex2.example, yet, as currently described, that seems to be possible, 
> in that both hostm...@apex1.example and hostm...@apex2.example will 
> receive the same Request ID to approve/reject the request. 

For *each* of the domains to be included in the certificate, a email for DCV 
purpose has to be chosen from the ones the system automatically lists:
1) Constructed emails, using admin@, administrator@, webmaster@, hostmaster@, 
or postmaster@ + apex domain. (method 3.2.2.4.4)
2) Result of the WHOIS lookup previously made, for the “technical contact”, or 
“administrative contact” (method 3.2.2.4.2). The WHOIS lookup is performed 
automatically by making a query to the whois service corresponding to the tld. 
This method can only be used when there is public information available and the 
registrar/WHOIS provider has not masked it, otherwise, this option is not 
available. 

We do not reuse the Random Value. Each DCV email receives an independent email 
with a unique RV. 

Following your example, let the domains be apex1.example, apex2.example, and 
apex3.example. It would show 3 dropdown lists (one for each domain) with the 
emails to choose form:
· apex1.example:   acceptable emails as listed above. - e.g. Chosen email is 
hostmaster @apex1.example
· apex2.example:   acceptable emails as listed above. - e.g. Chosen email is 
admin @apex2.example
· apex3.example:   acceptable emails as listed above. - e.g. Chosen email is 
webmaster @apex3.example
3 emails would be sent: 
· To hostmaster @apex1.example - containing request ID (or "order ID"), unique 
RV and download link for program.
· To admin @apex2.example - containing a link with a RV unique to this domain.
· To webmaster @apex3.example - containing a link with a RV unique to this 
domain.

In NO case apex1.example receives the same random value as apex2.example. So 
hostm…@apex1.example could not approve a request for apex2.example or 
apex3.example. 

Maybe the term “request ID” was what caused confusion. It refers to an 
identifier of the certificate request itself (maybe I should have called it 
“order ID”), not the RV. 

We are working on supporting other DCV methods in the near future (by April), 
specifically .13, .14. since are the most similar and easier to integrate in 
our current system. Also studying the option of integrating method .7.

Regards,
Pablo

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 16, 2021 at 6:02 PM Pablo Díaz via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Said "additional" confirmation email, addressed to the domain
> administrator, informs them that [Applicant Data] has requested an SSL
> certificate for their domain [Domain] by [Request ID] request, and
> instructs them to access a link (valid for 29 days, the email indicates the
> expiration date) where they can manually confirm or reject the request by
> clicking Confirm/Reject buttons.


Can you describe more here?

There are gaps here which seem to allow any number of insecure
implementations.

For example:
- Sending a link that must be accessed to approved is known-insecure, as
automated mail scanning software may automatically dereference links in
e-mail (in order to do content inspection). Confirm/Reject buttons alone
shouldn't be seen as sufficient to mitigate this, as that may vary based on
how the crawler works. Requiring explicit entry of the random value is a
necessary "human" measure (aka similar to a CAPTCHA)
- You haven't described how the email address is constructed for these
cases. The BRs only permit you to reuse the Random Value for 3.2.2.4.2, and
if and only if the domain contact is the same for all of the requested
domains. If, for example, you're using 3.2.2.4.4 (your #1 example), it
would be inappropriate if hostmaster@apex1.example could approve a request
for apex2.example, yet, as currently described, that seems to be possible,
in that both hostmaster@apex1.example and hostmaster@apex2.example will
receive the same Request ID to approve/reject the request.

The reliance on 3.2.2.4.2 is also known to be dangerous (in that it relies
on human inspection or OCR of otherwise unstructured text), which is why
it's discouraged compared to other methods (like .7, .19, or .20, and if
using e-mail, .13, .14). It's unclear how you extract the emails from the
WHOIS results that you provide, and whether that's something the IRM
performs or whether that's somehow programmatically driven.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Pablo Díaz via dev-security-policy]

> The reason we reject human error as a root cause, which you don't seem 
> to understand because you mention the engineers, is that failures are 
> NOT the fault of humans who make mistakes. They're the fault of the 
> system which failed to prevent the mistakes. 
> The mention of the engineers, coupled with the note in the incident 
> report about "Disciplinary Measures and Sanctions", suggests that ANF 
> intends to use the threat of punishment to try to prevent mistakes. 

I believe that you have overlooked many of the reinforcement measures that I 
indicated in my previous email for the sake of your final conclusion. Measures 
that show that in ANF AC, we work so that our systems avoid the errors that 
humans could make, and that these would prevent errors that other included CAs 
have made (I gave some examples).

I pointed out several automated measures, however, the conclusion you reach is 
that we "intend to use the threat of punishment to try to prevent mistakes”...

The existence of said document “Disciplinary Measures and Sanctions” is not 
“threat of punishment”, it is a normative and legal obligation, by ETSI EN 319 
401, whose REQ-7.2-05 indicates “Appropriate disciplinary sanctions shall be 
applied to personnel violating TSP's policies or procedures”; which refers to 
clause 7.2.3 of ISO/IEC 27002:2013 for guidance: "There should be a formal and 
communicated disciplinary process in place to take action against employees who 
have committed an information security breach."

Your interpretation that a “Disciplinary Measures and Sanctions” Policy is 
intended to intimidate our staff is far from reality. Contrary to that, this 
documented processes in an organization are intended to avoid arbitrariness and 
guarantee a unified criterion, which is known throughout the organization.
_

Regarding Domain Control Validation, I apologize for trying to be brief in my 
previous answer. I will go into more detail, so that it can be understood how 
ANF AC proceeds to validate the requests:

At the time of request, when indicating the domain or domains to be included in 
the certificate, the automated checks described in my previous email are 
performed (regarding correct format, posible errors, CAA Records, Google Safe 
Browsing list, ANF AC blocklist) to prevent an “invalid” request from 
proceeding. Because, it makes no sense to allow a request for an invalid domain 
to proceed, or for a domain with CAA RR containing unknown property tags with 
the Critical bit set, or with “issue” or “issuewild” that does not authorize 
issuance by ANF AC. Here, also a WHOIS lookup is made.

It is important, for the explanation further below, to indicate that in the 
request we also require the applicant's phone number.

Next, for each of the domains to be included, a drop-down email list is shown 
with the following options to choose from:
1) Constructed emails, using 'admin', 'administrator', 'webmaster', 
'hostmaster', or 'postmaster' + @ + apex domain (which would be method 
3.2.2.4.4)
2) Result of the WHOIS lookup previously made, for the “technical contact”, or 
“administrative contact” (which would be method 3.2.2.4.2). This is in case the 
content of said contact is in email format. If the content is protected by 
privacy it is not listed.

In the case of single-domain, when formalizing the request, two codes are sent 
via:
- Request confirmation email: Contains the request ID (numeric), a random 
alphanumeric code valid for 29 days, and a download link for “ANF Certificate 
Manager” program.
- SMS: Random code (code 2).

In “ANF Certificate Manager” the applicant must enter the request ID, the email 
code and the SMS code. The program then shows all the request information 
(applicant info, data of the subject, DNS to include in SAN…) and the applicant 
must give confirmation. Said request is then sent to ANF AC in order to 
validate the rest of the documentation (explained further below), and proceed, 
if favorable, to the issuance of the certificate.

NOTE: "ANF Certificate Manager" is a client desktop program that incorporates a 
tool so that the applicant can generate their key pair on their Windows PC. 
This makes it easier for the client to later download the issued certificate, 
and export to pfx if needed. Here I want to clarify that in NO case ANF AC 
generates the keys and returns them to the program, it is the program tool that 
generates the keys on the applicant's PC. (as I saw it was discussed at 
https://archive.cabforum.org/pipermail/servercert-wg/2020-May/001949.html). We 
also allow the option for the user to provide CSR that was generated by their 
preferred means.

In case of multi-domain, it does not make sense to send N emails with 
instructions to download the program, since it only needs to be downloaded 1 
time. Therefore, what the system does is: send the request confirmation email 
to one of the emails, and send an 

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Andrew Ayer via dev-security-policy]

On Fri, 12 Mar 2021 04:57:56 -0800 (PST)
Pablo D__az via dev-security-policy
 wrote:

> [...]
>
> I completely agree that "Human error" is not an acceptable analysis,
> and "training improvement" is not the optimal solution.  We have
> worked to apply as many automatic controls as possible to reduce any
> possible human error to a minimum, and the team of engineers who made
> those mistakes at that time are no longer in our organization.

The fact that this team of engineers is no longer in your organization
doesn't address the concerns; if anything, it raises more concerns.
The reason we reject human error as a root cause, which you don't seem
to understand because you mention the engineers, is that failures are
NOT the fault of humans who make mistakes.  They're the fault of the
system which failed to prevent the mistakes.

The mention of the engineers, coupled with the note in the incident
report about "Disciplinary Measures and Sanctions", suggests that ANF
intends to use the threat of punishment to try to prevent mistakes.
Meanwhile, ANF is still relying on error-prone manual domain
validation, as we shall see below.

> [...]
>
> Regarding domain validation, we are able to use the BR methods
> (3.2.2.4.2), (3.2.2.4.4) or (3.2.2.4.15). Measures have been applied
> to ensure that domain validation is not skipped:
> * In the request
> process, emails built using 'admin', 'administrator', 'webmaster',
> 'hostmaster', or 'postmaster' + @ + apex domain are automatically
> listed. The random request confirmation code will be automatically
> sent to this email. 

What is the process for verifying that the applicant knows the correct
Random Value?

> * In case of being multidomain, one of them is
> chosen to send the confirmation code and the rest, each one will be
> manually validated in the validation process (which also includes
> verification of documentation and other data) by our IRM staff
> (Issuance Reports Managers) 

This alone should be grounds for rejecting the application, and shows
that your above claim that ANF has applied "as many automatic controls
as possible" is false.  We've repeatedly seen how error-prone manual
domain validation processes are.  CAs, especially those who have a
history of failure, should not be issuing certificates using manual
domain validation.

> * Before confirming the issuance order,
> the IRM staff must indicate, for EACH domain, which domain validation
> method (of those indicated in ANF AC CP) was used, with current BR
> version number and attach files that provide evidence for this.
> Othewise it cannot proceed with issuance.

In an automated system, it's unnecessary for staff to manually indicate
this, as the system knows which domain validation method was used.
What is the process for ensuring that staff do not report the incorrect
validation method, or report that domain validation was completed when
it really wasn't?

> In addition to this, we have automatic pre-issuance lint using
> cablint, x509lint and zlint.

While this is good practice for ensuring that RFC 5280-violating certificates
are not issued, it does not prevent certificates from being issued without
proper domain validation, so it's not responsive to the core concern of
ANF's failure to perform domain validation.

Although this response does highlight some good practices that ANF has
adopted, like preissuance linting and subscribing to the CA-related
components in Bugzilla, it ultimately reinforces the core concerns I
raised in my original post: the reliance on manual domain validation,
and an incident response philosophy that blames humans instead of
addressing root causes.

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Pablo Díaz via dev-security-policy]

Hello Andrew,

I am very aware that in the past the CA has made errors and misissuance, I 
fully understand the context and the seriousness of the matter. As CA we 
understand that it makes no sense to rely on "nothing serious ever happened", 
and the correct thing is to assume the importance of these errors, give 
explanations to the community and act to prevent them from happening again.

It is my purpose to gain the confidence of the community in ANF Autoridad de 
Certificación (ANF AC) and guarantee the operation of the CA in compliance, 
that is why I would like to take your intervention as an opportunity to give 
the pertinent explanations, comment on the substantial improvements applied in 
our PKI since then, and clarify those past bugs that remain confusing.

I completely agree that "Human error" is not an acceptable analysis, and 
"training improvement" is not the optimal solution.  We have worked to apply as 
many automatic controls as possible to reduce any possible human error to a 
minimum, and the team of engineers who made those mistakes at that time are no 
longer in our organization. ANF AC made a profound change, both in human and 
technical resources.

We reviewed pretty much all the resources provided by Mozilla regarding 
frequent incidents and misissuances and the wiki pages dedicated to grouping 
incidents of specific CAs (which in many cases have led to their distrust), and 
finally we have established multiple automatic controls both in processing the 
request as in the moments prior to issuance. These controls, already applied 
and fully automatic, are as follows.

Regarding the domain:
• Automatic validation of the TLD is performed against IANNA’s Root Zone 
Database https://www.iana.org/domains/root/db to avoid Internal Names (BR 
7.1.4.2.1)
• The FQDN must comply the “preferred name syntax” in RFC1034 modified by 
RFC1123. 
• Domain and subdomain can only start with a letter or digit, end with a letter 
or digit. The only interior characters accepted are letters, digits and hyphen 
(so not underscore “_” - BR 7.1.4.2.1, or spaces “ “).
• Duplicate entries are not allowed (as we saw it happened at: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1357067)
• Double automatic verification of CAA Records, at the time of formalization of 
the request and prior to the issuance.
• Automatic check against Google Safe Browsing List (GSB)
• Show warning and set aside for manual review in case of repeating 2 times a 
TLD registered by IANNA (com.com, net.net ...) (as we saw the case of 
suspicious com.com certificate: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1672409)
• In the case of Wildcard, both verification of the correct position of the 
asterisk (*) and suitability for the requested profile.
• If it contains more than 4 consonants in a row, which is unusual, shows a 
warning of potential typo is displayed.

Regarding the data of the subject, among others:
• To avoid typos of "geographic errors", we have standardized the values of 
stateOrProvinceName and localityName (locality whenever possible, given the 
magnitude) fields for Spain, and the countries of our main clients, using both 
official data and examples of certificates issued by other local CAs in those 
countries. This is also applied, in case of EV, to 
jurisdictionStateOrProvinceName and jurisdictionLocalityName fields.
• In the case of countryName being Spain, our main market, we have established 
automatic controls regarding the VAT number format (NIF), and a direct and 
automatic query to the official Spanish records to obtain the organization name 
as it is officially registered.
• In the case of countryName being Spain, automatic assignment of 
CategoryBusiness according to the VAT number format (to avoid incidents like 
this we saw here https://bugzilla.mozilla.org/show_bug.cgi?id=1600114). The 
first letter of VAT numbers in Spain indicates the legal type of the 
organization, so its easy to automate this classification. 

Regarding domain validation, we are able to use the BR methods (3.2.2.4.2), 
(3.2.2.4.4) or (3.2.2.4.15). Measures have been applied to ensure that domain 
validation is not skipped:
• In the request process, emails built using 'admin', 'administrator', 
'webmaster', 'hostmaster', or 'postmaster' + @ + apex domain are automatically 
listed. The random request confirmation code will be automatically sent to this 
email.
• In case of being multidomain, one of them is chosen to send the confirmation 
code and the rest, each one will be manually validated in the validation 
process (which also includes verification of documentation and other data) by 
our IRM staff (Issuance Reports Managers)
• Before confirming the issuance order, the IRM staff must indicate, for EACH 
domain, which domain validation method (of those indicated in ANF AC CP) was 
used, with current BR version number and attach files that provide evidence for 
this. Othewise it cannot proceed with issuance.

In addition to this, 

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Andrew Ayer via dev-security-policy]

On Wed, 10 Mar 2021 13:43:55 -0700
Ben Wilson via dev-security-policy
 wrote:

> This is to announce the beginning of the public discussion phase of
> the Mozilla root CA inclusion process for the ANF Secure Server Root
> CA.

I'd like to draw attention to the first misissuance mentioned
in  and
.
Although this misissuance occurred under ANF's old hierarchy, that
hierarchy is/was trusted by Apple and Microsoft, and ANF was requesting
its inclusion in Mozilla, so the incident is relevant to understanding
how ANF operates a publicly-trusted certificate authority.

In 2019, ANF issued a server certificate

with a DNS name of cdcdcd.  Obviously, they could not have possibly
validated domain control of this hostname, which is a serious failure
considering that domain validation is the most important task a
CA performs.  However, their incident report doesn't mention domain
validation at all.  They blamed the incident on human error by "junior
engineers" and their resolution was to implement a blocklist of words
that indicate a test certificate ("Test", "Testing", "Prueba"), provide
more training for junior engineers, and update their "Disciplinary
Measures and Sanctions document, in order to have this resources
available in case of infringement".  None of these resolutions address
the root failure to perform domain validation.  Had this incident
report been written several years earlier, it may have been excusable,
but by 2019 it was very clear to anyone following mdsp and CA incidents
that "human error" is not acceptable analysis and training is not an
adequate resolution.

Additionally, their incident report shows some pretty concerning
misunderstandings of PKI and the BRs:

1. A belief that the CABF's Test Certificate extension OID is meant for
testing their CA rather than a (now forbidden) domain validation method.

2. A belief that the CABF's Test Certificate extension OID is to be put
in the certificate policy extension rather than used as the ID for a
poison extension.

3. A conflation of the subject serial number and the certificate serial
number, stating that the subject serial number must contain 64 bits of
entropy.

Finally, note that the new hierarchy has issued zero end-entity
certificates known to CT, so the fact that the new hierarchy hasn't
misissued any certificates doesn't speak to the competence of ANF.
On the other hand, the history of misissuance in the old hierarchy,
ANF's misunderstandings of PKI, and the incredibly poor incident report
speak very poorly to ANF's competence and trustworthiness.  There is
no indication that they've corrected the root cause of their failure to
perform domain validation, and no reason to believe that their
compliance problems won't reoccur under their new hierarchy.

When Mozilla trusts a CA, Mozilla is giving an assurance to its users
that they won't be harmed by the CA.  A CA which has lax technical
controls, a poor understanding of PKI, and an inability to learn from
and improve when mistakes are made is at heightened risk of
exploitation by malicious actors that would harm Mozilla users.  I do
not believe Mozilla can give assurance to their users that ANF is safe.
Therefore, this application should be rejected.

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Ben Wilson via dev-security-policy]

Here you go:

https://testvalidsslev.anf.es
https://testrevokedsslev.anf.es
https://testexpiredsslev.anf.es

On Thu, Mar 11, 2021 at 6:38 AM Andrey West Siberia via dev-security-policy
 wrote:

> Hello,
> I can't find the test URIs for this root certificate...
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Andrey West Siberia via dev-security-policy]

Hello,
I can't find the test URIs for this root certificate...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy