1544933 - Certinomis: certificates for an unregistered domain, with unknown OCSP status

Reporter

Description

•

5 years ago

Attached file certinomis_unknown_ocsp.zip — Details

In February 2019, Certinomis issued 14 certificates for mediatheque-lecannet.fr, a domain which is not currently registered nor was registered at any point since January 2017 (the earliest data available from the .fr registry at https://opendata.afnic.fr/en/products-and-services/services/opendata-en.html):

I suspect that the intended DNS name was mediatheque.lecannet.fr, a domain which does exist.

Furthermore, Certinomis' OCSP responder is returning "unknown" for all of these certificates. I've attached a Zip file containing the responses.

Ryan Sleevi

Updated

•

5 years ago

Assignee: wthayer → marc.maitre

Status: UNCONFIRMED → ASSIGNED

Ever confirmed: true

Whiteboard: [ca-compliance]

Ryan Sleevi

Updated

•

5 years ago

Assignee: marc.maitre → francois.chassery

François CHASSERY

Assignee

Comment 1

•

5 years ago

Here is an incident report align to the mozilla template :

1/ How your CA first became aware of the problem.
After an Andrew Ayer's report

2/ A timeline of the actions your CA took in response.

18/02/2019 - 17h18 : request of a pre-certificate with a non registered TLD
18/02/2019 - 17h18 : request of a pre-certificate with a non registered TLD
18/02/2019 - 17h18 : request of a pre-certificate with a non registered TLD
18/02/2019 - 17h18 : request of a pre-certificate with a non registered TLD
19/02/2019 - 09h09 : request of a pre-certificate with a non registered TLD
19/02/2019 - 09h09 : request of a pre-certificate with a non registered TLD
19/02/2019 - 09h10 : request of a pre-certificate with a non registered TLD
19/02/2019 - 16h28 : request of a pre-certificate with a non registered TLD
20/02/2019 - 09h59 : request of a pre-certificate with a non registered TLD
20/02/2019 - 09h43 : request of a pre-certificate with a non registered TLD
26/02/2019 - 14h52 : request of a pre-certificate with a non registered TLD
27/02/2019 - 15h44 : request of a pre-certificate with a non registered TLD
27/02/2019 - 15h46 : request of a pre-certificate with a non registered TLD
27/02/2019 - 16h58 : request of a pre-certificate with a non registered TLD

3/ Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.
It is a single human error not a systemic issue that could reproduced in the same in other certificate request

4/ A summary of the problematic certificates.
14 pre-certificates with CN = mediatheque-lecannet.fr

No certificate has been issued (this is why the OCSP respond unknown)

5/ The complete certificate data for the problematic certificates.

6/ Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
human registration operator confused "mediatheque-lecannet.fr" and "mediatheque.lecannet.fr" and she check only that the domain name "lecannet.fr" belongs to the organisation "Commune Le Cannet". Her vigilance was lowered by the fact that this is an ancien client (2012) where stackeholders have personal certificates delivered after face to face control, which create a context of confidence.

7/ List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future.
We have developed a new function for registration that is based on method n°4 of §3.2.2.4 of CAB/F BR
Tests and integration of it is suspended until we have successed in our main priority (pre-issuance linting).
I would carefully announced an use in production for beginning of June for this new function.
A second registration method (n°6 of §3.2.2.4 of CAB.F BR) is going to be specified and developed to complete the method above ; the scope for this second method should be end of septembre.

Flags: needinfo?(francois.chassery)

Ryan Sleevi

Comment 2

•

5 years ago

(In reply to François CHASSERY from comment #1)

Here is an incident report align to the mozilla template :
3/ Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.
It is a single human error not a systemic issue that could reproduced in the same in other certificate request

Just to be clear: systems which enable human error, particularly multiple human errors, do represent systemic flaws. In this case, based on the fact that it was caused by human error, have you stopped issuance or instituted additional review practices so that you can be certain human error is no longer possible or likely? If so, when? If not, why?

4/ A summary of the problematic certificates.
14 pre-certificates with CN = mediatheque-lecannet.fr

No certificate has been issued (this is why the OCSP respond unknown)

Note that Mozilla Policy treats the issuance of a pre-certificate as a committment to issue an equivalent certificate. That is, the statement that no associated certificate was issued has no bearing or dispensation on the expectations of the CA in their fulfillment of services.

As a consequence, the expectation is that a response positively affirming these - and any other pre-certificates that do not comply with policy - are revoked, since there 'may' exist (in an unverifiable, to Mozilla, way) an equivalent certificate for that pre-certificate.

6/ Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
human registration operator confused "mediatheque-lecannet.fr" and "mediatheque.lecannet.fr" and she check only that the domain name "lecannet.fr" belongs to the organisation "Commune Le Cannet". Her vigilance was lowered by the fact that this is an ancien client (2012) where stackeholders have personal certificates delivered after face to face control, which create a context of confidence.

This highlights a systemic failure to validate the domain name. Please describe the current process Certinomis performs to validate the domain name, and what steps it has taken to ensure this method is robust in the face of human error?

Note: There's no technical requirement that you change the validation method itself (unless it's a non-permitted method), but a human control to enforce that the domain was appropriately validated, when it's trivial to have a technical control (and to be clear, this is separate and orthogonal from linting), highlights a serious and concerning matter. Much as it would be considered inappropriate to have CA representatives construct every certificate by hand, writing and computing the DER encoding themselves in hex, it should be seen as inappropriate and counter to well-understood best practice to allow the manual entering of domains without some systemic validation of the well-formedness of the domain and the association to domain-authorization information.

Understanding what the current practice is will help inform and englighten whether the proposed mitigations should be sufficient. As it stands, merely switching the validation method - or switching to pre-issuance linting - are not believed to address this issue, nor is it clear that the root cause has been identified by Certinomis.

François CHASSERY

Assignee

Comment 3

•

5 years ago

Dear Ryan

First, I apologize, but I am not certain, even after translation, to understand what this sentence means :
"As a consequence, the expectation is that a response positively affirming these - and any other pre-certificates that do not comply with policy - are revoked, since there 'may' exist (in an unverifiable, to Mozilla, way) an equivalent certificate for that pre-certificate."

Second, I am aware that pre-issuance linting wil not adress the present issue.
I mentionned it to explain that because of pre-issuance linting priority we give an additional deadline to the enforcing of systemic validation for domain registration.

Third, as I wanted to explain in point 7, we have undertaken since beginning of this year a stengthening of our RA software, to provide systemic domain validation in addtion to human control.
the firts step of it is now ready : we have a function implementing method n°4 of §3.2.2.4 of CAB/F BR. We still need to test it and install it on the production platform, but the soft is ready.
The second step will be to add a second automatism (method n°6) for giving a choice of method to client. Presently it has been planned for end of september.

Kind Regards,

François

Flags: needinfo?(francois.chassery)

Ryan Sleevi

Comment 4

•

5 years ago

(In reply to François CHASSERY from comment #3)

Dear Ryan

First, I apologize, but I am not certain, even after translation, to understand what this sentence means :
"As a consequence, the expectation is that a response positively affirming these - and any other pre-certificates that do not comply with policy - are revoked, since there 'may' exist (in an unverifiable, to Mozilla, way) an equivalent certificate for that pre-certificate."

Basically, by logging a certificate, a CA is promising that there is or will exist an equivalent certificate. Thus, it needs to be treated as if it was issued.

If you imagine the world before CT, there was no way to know what a CA had issued, unless you had the actual certificate. CT was meant to address this, by having CAs log their certificates. For technical reasons related to issuance, pre-certificates were introduced as a way to let a CA log the certificate before they gave it to the subscriber.

From external point of view, anyone looking at a CT log should and does expect that, for any precertificate, the CA has also issued an equivalent certificate. Thus, misissuing a precertificate is just as bad as misissuing a certificate.

There's no way for anyone not at Certinomis to "prove" that, for these certificates, you didn't actually issue the equivalent certificate. You might have actually issued them, and might just be misreading the logs. With CT, because the precertificate exists, you could use the actual certificate as well, if it did exist - and clients would treat it as logged - which is also why it's important to treat it as issued.

Third, as I wanted to explain in point 7, we have undertaken since beginning of this year a stengthening of our RA software, to provide systemic domain validation in addtion to human control.
the firts step of it is now ready : we have a function implementing method n°4 of §3.2.2.4 of CAB/F BR. We still need to test it and install it on the production platform, but the soft is ready.
The second step will be to add a second automatism (method n°6) for giving a choice of method to client. Presently it has been planned for end of september.

That's not clear what methods you presently use to validate domains. The reason I'm pushing on this point is that it's possible to implement 3.2.2.4.4 and 3.2.2.4.6 with the same flawed human practices, leading to this same issue. A more comprehensive explanation about what the current process is, and what the future process will be, helps make sure that end-to-end, the systemic risks of human factors in this critical function have been addressed. It's equally as important to understand the current practice, so that it's clear how the current practice complied with the Baseline Requirements, and where that compliance "wasn't enough" to prevent misissuance, so that we can work to address that going forward.

I realize in light of the mozilla dev-security-policy discussion right now, Certinomis has its hands full. However, having a holistic, detailed, technical explanation of both the present and the future flow is a way that Certinomis could demonstrate that the systemic patterns addressed in that thread have been or are being addressed, and future incidents are less likely.

Ryan Sleevi

Updated

•

5 years ago

Flags: needinfo?(francois.chassery)

François CHASSERY

Assignee

Comment 5

•

5 years ago

Dear Ryan,

Thank you for the explanation and the background of CT log.
I understand and do not discuss about the point that pre-certificate are as important and must be as true as real certificate.
In the present situation, I am wondering how to fix this event: since it is not possible to revoke a certificate that does not exist, how to indicate that the pre-certificate is not "valid" anymore?

To go further on third point and answer to your demand, I am presenting the present workflow and the future one:

PRESENT (recent changes are taken in account in what I explain below):

Creating the request
A representative of a client connect to our RA Front-Office (login +password)
At first order he needs to create an access account and describe his company.
If he has a CSR, he copy and paste it in the GUI, if not direct to next step
Then he describe the server identity (CN, SAN, state and town; in the RA Front-Office there is control that domain name are FQDN) and the identity of the responsible of the server
Afterwards, payment information.
At the end, the representative of the client obtain a PDF file that he shall print, sign and send to our RA team (no copy are accepted).
If it is a server that shall be recognised by French administration (main part of our server certificate sales), the representative of the client shall join a proof of incorporation (for a company) or a proof of election of the authority (for a local administration) or a proof of nomination (for a ministry or an agency) and a copy of ID Card or passport of every stakeholder (the legal representative of the organisation and the responsible of the server, as a minimum).
Controlling the request
When our RA team has received the request file,
First control is on the organisation:
For a server for "commercial" purpose we check in the national database "http://avis-situation-sirene.insee.fr/" that the organisation exists
For a server recognised by French administration, we check the documentation described above at the end of point 1
Second control is on server identity: the registration operator search with a "whois" to check that the domain name exist and that he belongs to the described organisation.
If the client is not the owner of the domain name, he shall supply us with a written and signed "domain name authorisation" from the owner
If the operator cannot find the requested information with "whois" he send an email on the five e-mail address corresponding to the method 4 of 3.2.2.4 and wait for a positive answer for producing the certificate.
Specific case: external RA for an organisation
For some important customer (big company or administration) we may create an external RA that have a delegation to validate some server certificate. This RA are restricted for specific domain name for a specific organisation.
The certificate that can be validated must be for a domain name or a subdomain of a domain name that has been previously controlled and validated by a Certinomis RA operator, with the same method described in point 2 above.
The company name O= must be the company to which the external RA operator belongs (every RA operators are identified with a certificate on smart card)
No domain name can be added by the external operator on their own.
Due to ineffective control of domain name as FQDN in these external RA they are presently disabled until pre-issuance linting will be operational.

SOON (development has been delivered and have to be tested)

Creating the request
Before creating a server certificate request, the representative of the client shall "add" the domain name to the account of its company.
If he does not, the entry of the request will be impossible
To proceed, he shall click on a specific button "add a domain name" and then enter its domain name.
The program will send an e-mail to the five required e-mail address (BR 3.2.2.4-4), containing a clickable URL.
When any of these will be clicked on, the domain name will be registered; the click shall occur within a thirty days period after sending.
Afterwards the representative of the client can create his certificate request with the same action as he uses to do now.
Controlling the request
No change (we are going to keep "Whois" manual procedure alive to control that the organisation described in the request is the owner of the domain name).
Specific case of the external RA
The method for adding a new domain name requires that an operator of the external RA will request to add it by using a specific button "add a domain name" and then enters its domain name
The RA will then send automatically an e-mail to the five required e-mail address, containing a clickable URL.
When any of these will be clicked on, the domain name will be registered; the click shall occur within a thirty days period after sending.
A notification is sent to Certinomis RA administrator that shall confirm the addition of this domain name in the RA after control of the belonging of it.
After this, the external RA operator can request certificates for this domain name and validate these directly.

LATER (development scheduled in road map but not yet started)

  An embodiment will be proposed in the Front-Office RA to give the opportunity to the client to add a specific piece of 
  information on its web site to prove the control of the domain name (BR 3.2.2.4-6), instead of sending e-mails.

I hope my explanation are clear enough, and if not I may provide you with some screen shots.
I confirm you that since last two months we are spending our energy to fix the problems revealed in Bugzilla reports, but I take it as "a blessing in disguise”, an hard time that will bring us to a more secure situation.

Kind Regards,

François

Flags: needinfo?(francois.chassery)

Ryan Sleevi

Comment 6

•

5 years ago

(In reply to François CHASSERY from comment #5)

Dear Ryan,

Thank you for the explanation and the background of CT log.
I understand and do not discuss about the point that pre-certificate are as important and must be as true as real certificate.
In the present situation, I am wondering how to fix this event: since it is not possible to revoke a certificate that does not exist, how to indicate that the pre-certificate is not "valid" anymore?

I think the interpretation is that by creating the pre-certificate, you 'should' have created all the record keeping for there being an equivalent certificate. That is, all of the audit records (showing how you validated), all of the records in your CA (e.g. that this serial number has been used), etc. It's especially important when considering duplicate serials.

You're not the first CA to find yourself in a situation where your system was not designed with CT as specced. For example, if you're making use of EJBCA, perhaps you can reach out to WISeKey, who ran into something similar in Bug 1540281. Considering that, from an RFC 5280 perspective, revocation is based on the tuple of (serial number, issuer), I suspect that most CA software will have a way to configure a given serial number from a particular issuer as revoked.

It would be useful to the community to share what approaches you end up taking, when you do find a solution.

PRESENT (recent changes are taken in account in what I explain below):

Thanks! I want to highlight that this level of detail is exactly what we look for from "good" incident reports. It provides the community an understanding of how things presently work - including related controls or protections - and then highlights where they went wrong and how they're changing. As you can see from my questions below, it also helps build understanding or highlight gaps that may exist.

Controlling the request
When our RA team has received the request file,
First control is on the organisation:
For a server for "commercial" purpose we check in the national database "http://avis-situation-sirene.insee.fr/" that the organisation exists
For a server recognised by French administration, we check the documentation described above at the end of point 1
Second control is on server identity: the registration operator search with a "whois" to check that the domain name exist and that he belongs to the described organisation.
If the client is not the owner of the domain name, he shall supply us with a written and signed "domain name authorisation" from the owner
If the operator cannot find the requested information with "whois" he send an email on the five e-mail address corresponding to the method 4 of 3.2.2.4 and wait for a positive answer for producing the certificate.

Thank you for this level of detail! It's a bit unclear the order of operations here, and this may highlight why the issuance challenges exist.

I suppose a few questions to help understand:

If the WHOIS information exists and matches the organization information in the national database, does that mean you issue the certificate?
If the WHOIS information exists and does not match the organization, is it correct that you then rely on the "domain authorization document" from the listed owner?
a) If so, what method(s) do you use to contact the owner to get the document? Or is it that the Applicant provides the authorization document?
If the WHOIS information does not exist, you then use the constructed email form of 3.2.2.4.4, correct?

SOON (development has been delivered and have to be tested)

Creating the request
Before creating a server certificate request, the representative of the client shall "add" the domain name to the account of its company.
If he does not, the entry of the request will be impossible
To proceed, he shall click on a specific button "add a domain name" and then enter its domain name.
The program will send an e-mail to the five required e-mail address (BR 3.2.2.4-4), containing a clickable URL.

Got it. Could you describe more how this has been implemented? For example, what happens if I enter in subdomain1.subdomain2.domain.example - how are the constructed emails determined and where are they sent?

Specific case of the external RA
...
After this, the external RA operator can request certificates for this domain name and validate these directly.

Great! If I had domain.example, what control does the RA operator have for subdomain.domain.example ?

Flags: needinfo?(francois.chassery)

François CHASSERY

Assignee

Comment 7

•

5 years ago

Dear Ryan,

Please find below some precision that you wish to get.
I keep in mind your suggestion about revocation but we need to investigate it with EJBCA support.

It's a bit unclear the order of operations here

The operations are done in the same order that I have explained.

If the WHOIS information exists and matches the organization information in the national database, does that mean you issue the certificate?

The WHOIS information allows us to find the coordinate to contact the Domain Name Registrant, and to phone him to confirm he authorizes the issuance of a certificate.

If the WHOIS information exists and does not match the organization, is it correct that you then rely on the "domain authorization document" from the listed owner?
a) If so, what method(s) do you use to contact the owner to get the document?
b) Or is it that the Applicant provides the authorization document?

The applicant provides the document and we inquire on the relationship with the owner (mother company/subsidiary/subcontractor).
The authorisation document shall be signed in original on letterhead of the owner and /or wear the company stamp of the owner.
Generally this situation happens to us with domains used by our mother company in the frame of a contract larger than only web site operating (i.e. domain name authorisation is necessary to the execution of the main contract, which reinforced the value of the document domain name authorisation).

If the WHOIS information does not exist, you then use the constructed email form of 3.2.2.4.4, correct?

Yes

Got it. Could you describe more how this has been implemented? For example, what happens if I enter in subdomain1.subdomain2.domain.example - how are the constructed emails determined and where are they sent?

The first implementation is somewhat coarse and we intend to refine it later.
In your example three e-mails address will be proposed
"webmaster@ subdomain1.subdomain2.domain.example",
"admin@subdomain1.subdomain2.domain.example",
"administrator@ subdomain1.subdomain2.domain.example",
each one preceded by a tick box to give the applicant the possibility of unselect one or more address, and with a button on the web page to initiate the sending of the e-mail.

Great! If I had domain.example, what control does the RA operator have for subdomain.domain.example ?

Two level of answer:

The Certinomis RA operator shall check that the external RA organisation is the owner of “subdomain1.subdomain2.domain.example” or have a regular domain name authorisation, just like he would do for a unitary request our main RA Certinomis.
The external RA operator shall check whether “subdomain1.subdomain2.domain.example” looks like a regular FQDN.

Kind Regards,

François

Flags: needinfo?(francois.chassery)

Ryan Sleevi

Comment 8

•

5 years ago

(In reply to François CHASSERY from comment #7)

If the WHOIS information exists and matches the organization information in the national database, does that mean you issue the certificate?

The WHOIS information allows us to find the coordinate to contact the Domain Name Registrant, and to phone him to confirm he authorizes the issuance of a certificate.

If the WHOIS information exists and does not match the organization, is it correct that you then rely on the "domain authorization document" from the listed owner?
a) If so, what method(s) do you use to contact the owner to get the document?
b) Or is it that the Applicant provides the authorization document?

The applicant provides the document and we inquire on the relationship with the owner (mother company/subsidiary/subcontractor).
The authorisation document shall be signed in original on letterhead of the owner and /or wear the company stamp of the owner.
Generally this situation happens to us with domains used by our mother company in the frame of a contract larger than only web site operating (i.e. domain name authorisation is necessary to the execution of the main contract, which reinforced the value of the document domain name authorisation).

Thanks François.

At question here is that, based on the description, it's unclear whether this current validation method complies with the BRs. Your description of the use of WHOIS in response to #1 appears to be method 3.2.2.4.3 - Phone Contact with Domain Contact. However, in describing #2, it appears to be the (now-forbidden) 3.2.2.4.5, which has been forbidden since August 1, 2018.

My questions were an attempt to ensure a proper understanding of the validation procedures and practices, as the initial description (and this subsequent clarification) sounds as if it's describing something BR-incompatible.

Great! If I had domain.example, what control does the RA operator have for subdomain.domain.example ?

Two level of answer:

The Certinomis RA operator shall check that the external RA organisation is the owner of “subdomain1.subdomain2.domain.example” or have a regular domain name authorisation, just like he would do for a unitary request our main RA Certinomis.

The external RA operator shall check whether “subdomain1.subdomain2.domain.example” looks like a regular FQDN.

Just to clarify: It sounds as if the Certinomis RA operations are manual controls, is that correct? That is, that the RA is not authorized for domain.example and technical controls ensure all certificates are well-formed FQDNs that are subdomains of domain.example, but rather, the Certinomis RA visually confirms this, and the external RA is responsible for ensuring well-formedness?

Ryan Sleevi

Updated

•

5 years ago

Flags: needinfo?(francois.chassery)

François CHASSERY

Assignee

Comment 9

•

5 years ago

Dear Ryan,

Your description of the use of WHOIS in response to #1 appears to be method 3.2.2.4.3 - Phone Contact with Domain Contact. However, in describing #2, it appears to be the (now-forbidden) 3.2.2.4.5, which has been forbidden since August 1, 2018.

Thank you for the explanation, method 3.2.2.5 will no longer be used: the team has been informed and the procedures are going to be adapted.
We have extracted every certificates issued since August 1, 2018 to check which may have been issued following 3.2.2.4.5.
And if any they will be controlled again with method 3.2.2.4.

Just to clarify: It sounds as if the Certinomis RA operations are manual controls, is that correct? That is, that the RA is not authorized for domain.example and technical controls ensure all certificates are well-formed FQDNs that are subdomains of domain.example, but rather, the Certinomis RA visually confirms this, and the external RA is responsible for ensuring well-formedness?

The order of operation is as follow:

Requesting addition of the domain name in the GUI
Sending an e-mail with a clickable URL by the RA Software to the three "predetermined" addresses
Click on the URL by one of the three recipient within 30 days
Control of the owner of the domain name manually by a Certinomis human operator

I understand that #4 is not mandatory in regards of BR since performing #1 to #3 is an authorised validation method, but #4 seems useful to us for other purposes. And to make it clear, in any way it will be possible for our operators to proceed to #4 if #1 to #3 have not be performed previously.

Kind Regards,

François

Flags: needinfo?(francois.chassery)

Wayne Thayer

Comment 10

•

5 years ago

Thank you for the explanation, method 3.2.2.5 will no longer be used: the team has been informed and the procedures are going to be adapted.
We have extracted every certificates issued since August 1, 2018 to check which may have been issued following 3.2.2.4.5.
And if any they will be controlled again with method 3.2.2.4.

The continued use of 3.2.2.4.5 after August 1, 2018 is a new incident that is quite serious and significantly different from this one. I have created bug 1547072 for this new incident.

Franck Leroy

Comment 11

•

5 years ago

Hi,

I'm no more part of Certinomis CA, so I write this comment during the weekend on my personnal time.

I think there is a misunderstanding; the validation process described by François is only applicable to French RGS server certificates with "clientAuth" key usage (so not under BR rules).

For PTC (i.e. with "serverAuth" key usage) on 1st August 2018 the only validation methods that shall be applied by RA operators are the well-known phone call process and the email validation to the addresses defined in the BR (webmaster@ admin@...).

Theses two validation methods were manual ones so subject to human errors.
Before I left there was some developpement to allow the applicant to validate the domains before filling any application forms.

This new automated validation feature were to be available by the end of 2018.

I understand that this new feature has been developped and not yet used in production, and that a human validation error has been made by an RA operator confused by the fact that the organisation was "COMMUNE LE CANNET" and by the fact that the applicant made also an error in the CSR containing a '-' instead of a '.' to separate the domain name in the FQDN (mediatheque-lecannet.fr instead of mediatheque.lecannet.fr).

Hope this helps.
Franck

François CHASSERY

Assignee

Comment 12

•

5 years ago

Hello,
I confirm that Franck’s memory is more precise than my investigations had been:
I have actually described the procedure for client server certificates instead of the one for SSL server certificates.
We no longer use the "domain name authorisation" procedure for SSL servers since August 1, 2018 and we will no longer use the "phone call" procedure for those servers after June 1, 2019.
Kind Regards,

François

Flags: needinfo?(francois.chassery)

Ryan Sleevi

Comment 13

•

5 years ago

Thanks.

To avoid too much confusion of issues, I'll continue the conversation originally started in Comment #6 over in Bug 1547072 - that is, understanding the process of validating domains.

As it remains on this issue, it's been nearly three weeks since this incident was reported, and these certificates are still not responding revoked. As noted (e.g. in Bug 1540281), other CAs have been able to promptly respond to this and ensure the proper status is present.

Wayne Thayer

Comment 14

•

5 years ago

The Certinomis Root CA is being removed from the Mozilla root store in bug 1552374, so I am resolving this bug. Additional comments that may be useful when considering any future application by Certinomis are welcome.

Status: ASSIGNED → RESOLVED

Closed: 5 years ago

Flags: needinfo?(francois.chassery)

Resolution: --- → FIXED

Nobody; OK to take it and work on it

Updated

•

1 year ago

Product: NSS → CA Program

David Lawrence [:dkl]

Updated

•

1 year ago

Whiteboard: [ca-compliance] → [ca-compliance] [ocsp-failure] [ov-misissuance]