1420860 - Asseco DS / Certum: CAA Mis-Issuance on mix of wildcard and non-wildcard DNS names in SAN

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Quirin Scheitle]

As per Gerv's request, I am filing individual bugs for [1] -- please confer to [1] for a full background.

In this case, Certum likely mis-issued on a mixed wildcard/non-wildcard SAN, as discussed in [2] and listed in [3]. 

What likely happened is that Certum validated CAA for the wildcard SAN *.cyberbajt.pl and then added the base domain cyberbajt.pl without a further CAA check. As Certum is not listed in the issue set, it was not permitted to add the base domain SAN. 

To proceed with this as a community, I guess answers to the the following questions from the affected CAs [1] would be of interest:
        a) Was CAA checking bypassed for this issuance? If so, why?
        b) If CAA lookups were conducted, what response did you receive? Why did it permit issuance? 

The certificate in question is this:
======= Certificate 6 - Group 1 =======
https://crt.sh/?id=223356078
          X509v3 Subject Alternative Name:
              DNS:*.cyberbajt.pl
              DNS:cyberbajt.pl
        Issuer: Unizeto Technologies S.A. (-> Certum)
DNS history (Certificate issued on Oct 1):
2017-09-27:cyberbajt.pl.       86400   IN      CAA     0 issue ";"
2017-09-27:cyberbajt.pl.       86400   IN      CAA     0 issuewild "certum.pl"
2017-09-28:cyberbajt.pl.       86400   IN      CAA     0 issue ";"
2017-09-28:cyberbajt.pl.       86400   IN      CAA     0 issuewild "certum.pl"
2017-09-29:cyberbajt.pl.       86400   IN      CAA     0 issue ";"
2017-09-29:cyberbajt.pl.       86400   IN      CAA     0 issuewild "certum.pl"
2017-09-30:cyberbajt.pl.       86400   IN      CAA     0 issue ";"
2017-09-30:cyberbajt.pl.       86400   IN      CAA     0 issuewild "certum.pl"
2017-10-01:cyberbajt.pl.       86400   IN      CAA     0 issue ";"
2017-10-01:cyberbajt.pl.       86400   IN      CAA     0 issuewild "certum.pl"
2017-10-02:cyberbajt.pl.       86400   IN      CAA     0 issue ";"
2017-10-02:cyberbajt.pl.       86400   IN      CAA     0 issuewild "certum.pl"
2017-10-03:cyberbajt.pl.       86400   IN      CAA     0 issue ";"
2017-10-03:cyberbajt.pl.       86400   IN      CAA     0 issuewild "certum.pl"
2017-10-04:cyberbajt.pl.       86400   IN      CAA     0 issue ";"
2017-10-04:cyberbajt.pl.       86400   IN      CAA     0 issuewild "certum.pl" 



[1] https://groups.google.com/d/topic/mozilla.dev.security.policy/QpSVjzrj7T4/discussion
[2] https://groups.google.com/d/msg/mozilla.dev.security.policy/O9HZPMvHMY8/HtXR8S-1AAAJ
[3] https://misissued.com/batch/32/

Comment 1

[Gervase Markham [:gerv]]

Over to Asseco rep.

Gerv

Comment 2

[Quirin Scheitle]

Hi all, 

I just kindly wanted to follow up on this.

Kind regards
Quirin

Comment 3

[Arkadiusz Ławniczak]

Hi


I will submitt report soon. Thank you

Comment 4

[Firefox Bug Husbandry Bot]

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

Comment 5

[Quirin Scheitle]

Hi Arkadiusz, 

I just kindly wanted to remind you of this open bug. 

Kind regards
Quirin

Comment 6

[Wayne Thayer]

Arkadiusz: it has now been 6 months since this bug was reported with no response other than comment #3. Please supply an incident report as soon as possible. Failure to do so may result in sanctions up to and including removal of this root certificate from the Mozilla program.

Comment 7

[Arkadiusz Ławniczak]

I confirm that we processed CAA records for wildcard certificates improperly. 
The problem occurred due to misinterpretation of RFC 6844.
In fact, RFC 684 relates to the verification of singel domain, not to the combination of domains in SAN extension. But our interpretation was as if RFC describe verification for certificate request, not for domain. We were wrong.
Thus we accepted CAA records for wildcard certificate request as if they concerned only one wildcard domain (issuewild), whereas there are always two names in SAN.


Now, the logic for certificate request where wildcard domains in SAN exist is as follows:
ASSUME:
W = Wildcard domain
NW = Non-wildcard domain
CAA = CAA record
OK = Verification OK
NOT OK = Verification not OK 
LACK = Lack of a CAA record

WHERE:
CAA(NW(OK)) = domain is non-wildcard and CAA record consists a proper issue tag which is acceppted by CA 
CAA(W(OK)) = domain is wildcard and CAA record consists a proper issuewild tag which is acceppted by CA  
CAA(NW(NOT OK)) = domain is non-wildcard and CAA record consists an issue tag which is not acceppted by CA or the tag is unknown 
CAA(W(NOT OK)) = domain is wildcard and CAA record consists an issuewild tag which is not acceppted by CA or the tag is unknown
CAA(NW(LACK)) =  domain is non-wildcard and CAA record wasn't found
CAA(W(LACK)) = dmain is wildcard wildcard and CAA record wasn't found

THEN:
CAA(W(OK)) + CAA(NW(OK)) = SAN vaildation (OK)
CAA(NW(NOT OK)) + CAA(W(NOT OK)) = SAN vaildation (NOT OK)

CAA(W(NOT OK)) + CAA(NW(OK)) = SAN vaildation (NOT OK)
CAA(W(OK)) + CAA(NW(NOT OK)) = SAN vaildation (NOT OK)

CAA(W(OK)) + CAA(NW(LACK) = SAN vaildation (OK)
CAA(W(LACK)) + CAA(NW(OK)) = SAN vaildation (OK)

CAA(W(NOT OK)) + CAA(NW(LACK) = SAN vaildation (NOT OK)
CAA(W(LACK)) + CAA(NW(NOT OK)) = SAN vaildation (NOT OK)

CAA(NW(LACK)) + CAA(W(LACK)) = SAN vaildation (OK)

Comment 8

[Wayne Thayer]

Arkadiusz: Thank you for this information. This is not, however, everything that is required in an incident report as described here: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report Please post a full incident report.

Also: since you agree that this certificate was misissued, why has it not been revoked?

Comment 9

[Arkadiusz Ławniczak]

I have to correct my statement I wrote previously. The certificate s/n 51:14:ab:40:68:fc:30:f8:91:90:35:88:67:f6:48:df (https://crt.sh/?id=223356078) has been issued correctly. 
The fact that takes us to confusion, was the difference in the dates of issue of the certificate and the beginning of its validity. 
The certificate was issued on 20 Sep 2017 after full verification of CAA records. However the not before date was set by certificate requester 11 days in the future (Oct  1 00:00:00 2017 GMT).
I mistakenly accepted the evidence that Quirin provided, although the CAA records from 2017-10-01 were not actually on the day of issuing the certificate. On 20 Sep 2017 CERTUM did not find any CAA records for domains * .cyberbajt.pl and cyberbajt.pl and therefore the verification of CAA records was successful. Based on this and on the basis of domain verification (using one of the methods listed in section 3.2.2.4 Baseline Requirements) the certificate has been issued.

Comment 10

[Quirin Scheitle]

Thank you for your reply, Arkadiusz. 
We have only seen CAA records for that domain starting Sep 24th, 2017, so if you have indeed conducted the validation and issuance on Sep 20th, I have no evidence to the contrary. 
This is a known limitation to the CAA end-to-end audit methdology: In lieu of a pre-certificate SCT, the notValidBefore timestamp is the only indication as to when a certificate has been issued, and that may be off. 

It might, however, be interesting to investigate whether the bug described above has affected other Certum certificates.

Comment 11

[Wayne Thayer]

In comment 9 Certum asserts that this was not a misissuance and this bug is INVALID. However, due to the lack of evidence either way and the unaceptably slow responses from Certum, I am resolving this as FIXED.