1430909 - QuoVadis: Non-BR-Compliant issuance --improper characters in DNSName (BIT sub-CA)

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Alex Gaynor reported https://crt.sh/?id=282646337&opt=cablint on 21-Dec 2017. One of the dNSNames ends with two newline (\n) chracters, which are not valid is a DNS label

Stephen Davidson posted the following to the mozilla.dev.security.policy forum on 22-Dec 2017:
>On Dec 21 at 1715 UST we received a problem report (below) by email to >[e-mail] from Alex Gaynor relating to a TLS/SSL certificate >issued by Swiss Government Public Trust Standard CA 02, a technically constrained >external CA operated by Bundesamt fuer Informatik und Telekommunikation (BIT).
>
>Specifically, a SAN in that certificate included a dNSName that ended with two \n >characters:
>https://crt.sh/?id=282646337&opt=cablinthttps://crt.sh/?id=282646337&opt=cablint
>
>The certificate was revoked by the CA on Dec 22 at 1125 UST.
>
>Upon investigation, the CA reports that the misissuance was the result of >administrator error during the manual input of the SAN entry.  The misissuance >will be reported to the CAs external auditors.  The CA has undertaken to add >linting as part of the issuance of their TLS/SSL certificates.
>
>Thanks to Alex Gaynor for reporting the issue.

Please provide a full incident report in this bug and on the mozilla.dev.security.policy forum, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 1

[Stephen Davidson]

Thank you for your patience.  As noted below - both BIT and QuoVadis have been active on this case.

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.

On Dec 21 at 1715 UST we received a problem report (below) by email to [e-mail] from Alex Gaynor relating to a TLS/SSL certificate issued by Swiss Government Public Trust Standard CA 02, a technically constrained external CA operated by Bundesamt fuer Informatik und Telekommunikation (BIT).

Specifically, a SAN in that certificate included a dNSName that ended with two \n characters:
https://crt.sh/?id=282646337

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.

QuoVadis immediately notified BIT on the evening (UST) of Dec 21.  The certificate was revoked by BIT the next morning on Dec 22 at 1125 UST.  

Upon investigation, the CA reports that the misissuance was the result of administrator error during the manual input of the SAN entry.  The RA interface not show the \n character and the CA allowed it.
The misissuance has been reported to the CAs external auditors, KPMG.  

On January 17 BIT conducted a scan using an internally developed tool of all valid SSL issued by them, which revealed an additional certificate with the same issue which had previously been revoked.  That certificate was never deployed on the internet.

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.

BIT acknowledges the error.   BIT is running scans of SSL issuance using the above tool as a chron job several times a day while longer term improvements are being made.

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.

Two affected certificates were identified.  Further details are shown below.  

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.

SAN Error: Malformed SAN (CR|LF Match) was found for Subject www.schweizerfilmpreis.ch Serial: 55567933988439459748194099991947755489
Fingerprint: c0366bebafd384f67e71015688611155e74296c1
Issued: ‎ August ‎29, ‎2017
Revoked: September 4, 2017
https://crt.sh/?id=323947014 

SAN Error: Malformed SAN (CR|LF Match) was found for Subject sipref.admin.ch Serial: 77416902622611509339847446402784399713
Fingerprint: a1727ca86475cb80d47a211cfe7acada803625c7
Issued: ‎ ‎August ‎29, ‎2017
Revoked: December 22, 2017
https://crt.sh/?id=282646337

BIT commenced logging all new SSL issuance to CT on Jan 1, 2018 in batches post issuance.

5.  Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

BIT is undertaking a review of its RA interface to confirm that BR standards on field contents are enforced.

6.  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.

BIT already had a plan to introduce post issuance scanning into their certificate management system by November 2018 (and discussions were underway to accelerate that).  

At the same time, QuoVadis and BIT are in discussions to move BIT’s trusted SSL issuance in to a managed CA operated by QuoVadis, which would leverage QuoVadis’ automated controls for BR compliance.  Action on this decision on this expected by mid February 2018.

In addition, QuoVadis intends to introduce an improved tool for post issuance scanning of CT logs for all CAs associated with its roots using a zLint based tool in Q2.  In the meantime, QuoVadis undertakes frequent checks using public tools including crt.sh and censys.io.

Comment 2

[Wayne Thayer]

Thanks for the report Stephen.

(In reply to Stephen Davidson from comment #1)

> BIT already had a plan to introduce post issuance scanning into their
> certificate management system by November 2018 (and discussions were
> underway to accelerate that).  

Why not a pre-issuance check?

> At the same time, QuoVadis and BIT are in discussions to move BIT’s trusted
> SSL issuance in to a managed CA operated by QuoVadis, which would leverage
> QuoVadis’ automated controls for BR compliance.  Action on this decision on
> this expected by mid February 2018.

Please provide an update on the timing for a permanent fix.

> In addition, QuoVadis intends to introduce an improved tool for post
> issuance scanning of CT logs for all CAs associated with its roots using a
> zLint based tool in Q2.  In the meantime, QuoVadis undertakes frequent
> checks using public tools including crt.sh and censys.io.

Again, this approach still permits misissuance to happen.

Comment 3

[Stephen Davidson]

> Why not a pre-issuance check?

That original approach would be surpassed by a plan to move to a managed PKI.

> Please provide an update on the timing for a permanent fix.

Will do.

> Again, this approach still permits misissuance to happen.

In the case of BIT, the types of misissuance that have occurred would be prevented by our managed PKI interfaces.  We can achieve post issuance linting quickly, and it will have the advantage of assisting us in monitoring our few remaining SSL external CAs in close to real time.

Comment 4

[Firefox Bug Husbandry Bot]

Changing QA contact per https://bugzilla.mozilla.org/show_bug.cgi?id=1438254

Comment 5

[Stephen Davidson]

(In reply to Wayne Thayer [:wayne] from comment #2)

> Please provide an update on the timing for a permanent fix.

Beginning February 28 2018, BIT will use a managed PKI service from QuoVadis for TLS/SSL certificates previously issued by the external (root signed) 'Swiss Government Public Trust Standard CA 02'.  All issuing policies will be confirmed deactivated and the RA Service will be stopped on that CA. That CA will not be revoked until all existing certificates have expired.

Comment 6

[Wayne Thayer]

I believe all actions have been completed, so am marking this resolved.