UniTrust: EV certificate with wildcard domain in common name and SAN
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: michel, Assigned: chenxiaotong)
Details
(Whiteboard: [ca-compliance] [ev-misissuance])
Hello,
I noticed the https://crt.sh/?id=7398207090 EV precertificate issued by UniTrust that contains a wildcard domain in the SAN and common name.
It also seems that the jurisdictionCountryName: CN
doesn't match the jurisdictionStateOrProvinceName: Saint Petersburg
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Accident Report
1.How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.
In August 31st SHECA was made aware of this problem via this Bugzilla.
2.A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
20220831 10:00 CST SHECA was aware of this issue by Bugzilla notification.
20220831 10:30 CST Investigation is started by Information Security & Compliance.
20220831 11:00 CST Confirmed the certificate was mis-issued, and suspended any EV SSL certificates to be issued immediately.
20220831 14:30 CST Started review of historically issued certificates and outstanding requests. Initiated root cause analysis.
20220901 15:30 CST Certificate revoked.
20220902 16:30 CST Root cause Confirmed.
20220905 16:30 CST Updated linter in production system.
3.Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
Yes, we have already stopped issuing any EV certificates once we are aware of the issue. We confirmed there were no additional historically issued certificates or outstanding requests affected by this issue.
4.A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
Only one certificate. See #5.
5.The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
https://crt.sh/?id=7398207090
6.Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The mis-issued certificate was caused by unknown character. Prohibiting wildcards in EV TLS certificates is one of the validation rules. In this case, due to a bug during issuance procedure, the system failed to trim the Common Name before processing the validation rules and therefore failed to flag that the Common Name value was a wildcard due to a special character at the beginning of the field. Develop team has fixed the bug and updated the linter.
And jurisdictionCountryName doesn't match the jurisdictionStateOrProvinceName was caused by inexperienced manually document review.
7.List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
The impacted certificate has been revoked and we have updated the affected functionality in the certificate processing component to ensure wildcards in EV TLS certificates are prohibited, even if the provided domain name is prefixed with spaces. We will strengthen vetting team training in case any similar issue happen again.
Reporter | ||
Comment 2•2 years ago
|
||
Hello,
Thank you for your report.
We confirmed there were no additional historically issued certificates or outstanding requests affected by this issue.
How did you check the certificates that were issued historically? I see that https://crt.sh/?id=7398187286 also has jurisdictionCountryName: CN
and jurisdictionStateOrProvinceName: Saint Petersburg
. I also saw that in march you issued https://crt.sh/?id=6313246866 that has jurisdictionCountryName: CN
that was revoked and you subsequently issued https://crt.sh/?id=6313311360 that has jurisdictionCountryName: RU
however it seems that you didn't send an incident report for that issue.
Assignee | ||
Comment 3•2 years ago
|
||
Basically the default setting of JurisidictionCourntryName is CN, becasuse we don't have much overseas customers, recently we are starting some SSL business in other countries so our customer service/vetting team will change the CountryName accordingly, but there are several manual mistakes ignored the JurisidictionCountryName item.
The claim you quoted says we have checked if there is any EV certs contains wildcard domain name. As for the Jurisdicition name we are reviewing all certs issued to overseas subscribers and revoking, reissuing corrected ones.
Thanks for bringing that to our attention again, we will correct this certs https://crt.sh/?id=7398187286 ASAP.
Comment 4•2 years ago
|
||
Will you be creating a new bug with an incident report for https://crt.sh/?id=7398187286 and https://crt.sh/?id=6313246866 and any other certificate that was mississued with an incorrect jurisdictionCountryName
?
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
We prefer to update here to keep all followers informed.
We will publish another incident report after finishing review on jurisdictionCountryName to see if any other certificate misissued.
Comment 6•2 years ago
|
||
A separate incident report should have it's own bug so that next steps and resolution timeline can be tracked properly.
Comment 7•2 years ago
|
||
Hello, we are also requesting a separate incident report be created for the jurisdictionCountryName
mississuance.
In that report please elaborate on the “several manual mistakes” cited earlier:
- What was the root cause for each of these manual mistakes?
- Can automation eliminate the error in the future? If so, when can the automation be implemented?
While not directly applicable to jurisdictionCountryName
, is pre- and post-issuance linting currently deployed? If so, can you please state which lints are used?
As a reminder, though the Chrome Root Program follows the NSS CA Certificate Compliance component in Bugzilla, our policy requires incidents be reported to chrome-root-program@google.com.
Updated•2 years ago
|
Assignee | ||
Comment 8•2 years ago
|
||
Hello,We published another incident report after finishing review on jurisdictionCountryNam mississuance.
The URL of incident report is : https://bugzilla.mozilla.org/show_bug.cgi?id=1798626
Updated•2 years ago
|
Updated•2 years ago
|
Comment 9•2 years ago
|
||
What is the status of SHECA's progress on closing out this incident? I will close this out, on or about next Wed., 12-Apr-2023, unless anyone can see a reason for keeping it open. Thanks.
Updated•2 years ago
|
Comment 10•2 years ago
|
||
(In reply to Ben Wilson from comment #9)
What is the status of SHECA's progress on closing out this incident? I will close this out, on or about next Wed., 12-Apr-2023, unless anyone can see a reason for keeping it open. Thanks.
The question from comment #7 was never answered.
While not directly applicable to jurisdictionCountryName, is pre- and post-issuance linting currently deployed? If so, can you please state which lints are used?
This continues a concerning pattern from SHECA where sufficient details aren't given, questions are left unanswered, and weekly updates aren't provided as required by Mozilla. https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed
Assignee | ||
Comment 11•2 years ago
|
||
(In reply to Mathew Hodson from comment #10)
(In reply to Ben Wilson from comment #9)
What is the status of SHECA's progress on closing out this incident? I will close this out, on or about next Wed., 12-Apr-2023, unless anyone can see a reason for keeping it open. Thanks.
The question from comment #7 was never answered.
While not directly applicable to jurisdictionCountryName, is pre- and post-issuance linting currently deployed? If so, can you please state which lints are used?
This continues a concerning pattern from SHECA where sufficient details aren't given, questions are left unanswered, and weekly updates aren't provided as required by Mozilla. https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed
Hello Mathew,linter is used to solve the wildcard problem. For the jurisdictionCountryName, We upgraded our system workflow and logic. Also, we trained our operator, reminder them to put more attention on the information of jurisdictionCountryName,we set the default value of the this field from China to no default value. Before issuing the certificate, the information would be reviewed by vetting member to avoid the errors.
Updated•2 years ago
|
Description
•