Closed Bug 1462797 Opened Last year Closed 7 months ago
E-Tugra: Improper DER results in failure to comply with RFC 5280 - Invalid characters in Printable
Example certificate: https://crt.sh/?id=117812066&opt=cablint,x509lint,zlint This certificate fails to parse, as it contains a Subject attribute with a serialNumber field, and the serialNumber contains an underscore ("_"), which is not a valid character for a PrintableString. It's further unclear if this represents a potential violation of 184.108.40.206(j), as to whether such an underscore is a "metadata" field, but I believe it reasonably can be argued as such.
Davut: As Ryan indicated, this appears to be a misissued certificate. Please provide an incident report, 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.
Hi, We continue to review the case. I will provide incident report as soon as possible.
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. E-Tugra: We first aware from the problem via 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. E-Tugra: The following actions took in response after report. • Certificate is being revoked and a new certificate was issued for the certificate owner. The certificate will be revoked in a week. The certificate owner has a problem to change the system with new certificates. So for not giving a damage to their operations, we are waiting for the replacement for revocation. • All certificate database is searched for whether the problems is exist more or not. No more certificate is found with the problem. • The root analysis is applied and we found that why this problem occurs. (the reason of problem is applied in 6) • The pre-issue and post-issue control libraries in our system is upgraded and test against the problems. We try to create similar problem is we cannot after upgrade. 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. E-Tugra: The related certificate was planned for revocation and replacing with the new certificate getting bug notification from Bugzilla and all problems are fixed in our systems. The problem reasons are fixed and no more certificates will be produced with the problems. 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. E-Tugra: There is only one certificate with this problem. There is no more certificate with the same problem. 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. E-Tugra: There is only one certificate as reported. https://crt.sh/?id=117812066&opt=cablint,x509lint,zlint 6 Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. E-Tugra: The certificates owner requested an EV certificate at first. And during EV validation process, some jurisdiction information was entered to the system on our RA systems. Later, we recommended the applicant to convert application to OV based certificates due to customer needs and budgets. The serial number that was original set for jurisdiction number of organization continue to exist after converting application to OV SSL. In fact, We are not being set serialnumber on OV certificates. After final application validation. The certificate is issued with the organization serialnumber. After getting bug report from Bugzilla, we update our RA system by not allowing extra fields that is not defined in Baseline Requirements. 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. E-Tugra All required measures are taken for now. The certificates are controlled by the system. These are enough for preventing the certificates with these measures.
Apologies, this dropped off the radar for reviewing incident reports. > All required measures are taken for now. The certificates are controlled by the system. These are enough for preventing the certificates with these measures. This root cause analysis has not addressed how the invalid DER was produced or how it has been resolved/prevented. Can you please explain what steps that was taken? The incident report only seems to respond to serialNumber for OV (in #6 and #7), but that wasn't even the original reported issue. I highlight this, because even as recently as this past week, it appears that there are still misissued OV certificates being created: https://crt.sh/?id=1062781171&opt=x509lint https://crt.sh/?id=1061518954&opt=x509lint https://crt.sh/?id=1061497011&opt=x509lint Similarly, certs like https://crt.sh/?id=1062781171&opt=x509lint give me great pause about the design and suitability of this system. Even if it is not strictly an error, the prevalence of that issue with "testing" certificates (such as https://crt.sh/?id=1061295623&opt=x509lint or https://crt.sh/?id=1070751823&opt=x509lint ) suggests there are issues. While I think those I flagged should be reported by the CA as a separate issue, I do want to make sure we get a response to this - which is about invalid DER production for the certificate and how it was resolved.
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.