1495524 - Certinomis: Unqualified Domain Name in SAN

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Certinomis issued the following precertificate with a SAN of 'www':

https://crt.sh/?id=791668291&opt=cablint

The precertificate is revoked, but no incident report has yet been filed.


Please provide an incident report for this problem, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
The incident report should be posted to the mozilla.dev.security.policy forum and added to this bug. The report should include an explanation of why this incident was not promptly reported to Mozilla.

Comment 1

[Franck Leroy]

Hello

Here is an incident report align the mozilla template :

1/ How your CA first became aware of the problem.
During the validation of a TLS certificate (PTC) on 2018-09-27  15:16:39 UTC	

2/ A timeline of the actions your CA took in response.
2018-09-27  15:16:39 UTC	: human error in validation the certificate application
2018-09-27  15:19:49 UTC	: revocation of the invalid certificate

3/ Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.
It is a human error, not a systemic one.

4/ A summary of the problematic certificates. 
One certificate : www.aboxnote.com

5/ The complete certificate data for the problematic certificates.

https://crt.sh/?id=791668291&opt=cablint

6/ Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The operator made a mistake in the TLS certificate application.
The operator noticed that the SAN "www" was incomplete and that the need of the customer was to have both "aboxnote.com" and "www.aboxnote.com", but the operator miscliked on the validate button.
So the operator did not send the certificate to the customer, and immediatly asked for a revocation.

7/ List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future.
The GUI used by operators is the same for PTC and non PTC, so it is technically possible to validate an certificate application with unqualified domain names.
A enhancement will be added in the GUI in order to forbib validation of non qualified domain names for PTC (this feature allready exist in some parts of the software but not in the validation page).
A new version of our validation tool is planned for the end of the year.


The incident was not reported because the operator did not reported it to the manager.
The operator did not reported it because the certificate was not sent to the customer, and because the certificate has been immediatly revoked.
Taking into account that the certificate has not been sent and immediatly revoked, the impact of this incident has been regarded as null.

Best regards
Franck Leroy
Certinomis CTO.

Comment 2

[Wayne Thayer]

Franck: please update this bug when the rule to block non-qualified names has been implemented.

Comment 3

[Ryan Sleevi]

(In reply to Franck Leroy from comment #1)
> 7/ List of steps your CA is taking to resolve the situation and ensure such
> issuance will not be repeated in the future.
> The GUI used by operators is the same for PTC and non PTC, so it is
> technically possible to validate an certificate application with unqualified
> domain names.
> A enhancement will be added in the GUI in order to forbib validation of non
> qualified domain names for PTC (this feature allready exist in some parts of
> the software but not in the validation page).
> A new version of our validation tool is planned for the end of the year.
> 
> 
> The incident was not reported because the operator did not reported it to
> the manager.
> The operator did not reported it because the certificate was not sent to the
> customer, and because the certificate has been immediatly revoked.
> Taking into account that the certificate has not been sent and immediatly
> revoked, the impact of this incident has been regarded as null.

It does sound like there exists at least one systemic issue - which is confusion on behalf of the operator as to what constitutes an incident and reportable event.

While it's encouraging to hear you are working on technical controls to ensure that all domains are properly validated, this suggests that the current interface allows operators to specify domains as they wish, relying on human factors to prevent misissuance. It sounds like some changes to the training process and reporting process may be due.

For example, one possible mitigation is to have a daily review by senior management as to certificates revoked that day, to examine the reasons for that revocation and assess for potential patterns or problems. With such a daily review, it might have been noticed by Certinomis sooner.

It's unclear to me from Wayne's report is this was originally self-reported by Certinomis or whether it was something he detected through crt.sh. This equally seems an opportunity to improve here, by periodic scans for misissuance post-issuance, in addition to pre-issuance checks and linting.

It seems like there were multiple opportunities for correction or detection:
- Preventing manual configuration/validation/entry of domains
- Automatic linting/compliance checks prior to issuance (including precertificates)
- Periodic independent review of revoked certificates for policy compliance (which would minimally be expected as part of the quarterly reviews that a CA should be doing, but should be done sooner - daily even)
- Post-issuance evaluation and detection to ensure that the aforementioned tools and processes are working effectively

Could you discuss more about what procedures you have in place to systemically detect such issues, and why you may have chosen not to implement any of the above? Alternatively, if the above are useful approaches, can you provide timelines for their implementation?

Comment 4

[Wayne Thayer]

(In reply to Ryan Sleevi from comment #3)
> 
> It's unclear to me from Wayne's report is this was originally self-reported
> by Certinomis or whether it was something he detected through crt.sh. This
> equally seems an opportunity to improve here, by periodic scans for
> misissuance post-issuance, in addition to pre-issuance checks and linting.
> 
I discovered this while reviewing https://crt.sh/?cablint=issues on 1-October. The fact that the precertificate was revoked led me to assume that Certinomis had discovered the misissuance but failed to report it. The incident report appears to confirm my assumption.

Comment 5

[Wayne Thayer]

Franck is no longer a Certinomis representative. Reassigning to Marc.

Comment 6

[Ryan Sleevi]

Marc: It's been nearly two weeks. Do you have an update?

Comment 7

[Wayne Thayer]

Francois: We are still awaiting a response from Certinomis to comment #3

Comment 8

[François CHASSERY]

Hello,

there are several decision that had been taken and are on the point to be effective :

• a function has been developed for checking revocations : every night a list of revoked SSL certificates will extracted and send to Certinomis management for checking regularly revocation reasons (as there are few revocations we are confident that it will remain an acceptable load of work), planned for mid march.
• automatic pre-issuance controls of domain names validity have been strenghthened so that regsitration operators have no latitude in that matter.
• a post issuance linting of issued certificates will be performed every day by an internal audit team, different from the operational one, planned for mid march.
• in a longer perspective (no less than six months) we plan to implement a pre-issuance linting on the PKI software.

Kind Regards,

François

Comment 9

[Wayne Thayer]

I'm setting the next update for this bug to mid-March when the nightly revocation check is planned

Francois: thank you for the update. Do you mean that it will be longer than 6 months before Certinomis will implement pre-issuance linting? If so, why will it wait so long?

Comment 10

[François CHASSERY]

Hello Wayne,

We have to ugrade the PKI software version before connecting the linter to it.
And our team is already engaged in some heavy projects, which means the upgrade of version cannot be started presently.
If we try to do too many things at the same time I fear the result would not reach our expectations.

Kind Regards,

François

Comment 11

[Wayne Thayer]

Has the "function for checking revocations" been deployed to production yet? If it has, why was this bug not updated to reflect that change?

Comment 12

[François CHASSERY]

Dear wayne,

here is the status report for the three changes announced last month :

• checking revocation has been rejected in testing phase and now corrected; the new version has been delivered for testing and I believ I will be happy soon to annouve it is in production;
• automatic pre-issuance couldn't be deployed either, we have to fix it;
• post issuance linting is working and has already enabled us to react immediatley on an errors.

Kind regards,

François

Comment 13

[Wayne Thayer]

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.