Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

(Mis)-Issuance on CAA Timeout in DNSSEC signed zone

448 views
Skip to first unread message

Quirin Scheitle

unread,
Sep 12, 2017, 5:05:47 AM9/12/17
to mozilla-dev-s...@lists.mozilla.org
Hi,

inspired by the ballot paragraph [1], I set up a domain that is fully DNSSEC signed [2], but does not reply to CAA queries (timeout).

I could obtain certificates for this domain from Buypass and Startcom [3].
Other CAs (RapidSSL, GeoTrust, LetsEncrypt) have refused to issue, and GoDaddy and Certum have been stuck in "Pending" for days and will likely not issue.

Per my interpretation, and per the discussion in the other CAA/DNSSSEC thread, I believe those should not have been issued. I have reported this to the issuing CAs.

What do you think?

Kind regards
Quirin


[1] CAs are permitted to treat a record lookup failure as permission to issue if:

the failure is outside the CA’s infrastructure;
the lookup has been retried at least once; and
the domain’s zone does not have a DNSSEC validation chain to the ICANN root.

[2] https://dnssec-debugger.verisignlabs.com/crossbear.org
[3] https://crt.sh/?q=crossbear.org

Inigo Barreira

unread,
Sep 12, 2017, 5:38:56 AM9/12/17
to Quirin Scheitle, mozilla-dev-s...@lists.mozilla.org
Hi Quirin,

I was going to reply to your email after investigating what happened, but since you´ve posted here, I can share it.

I think most of the CAs are strugling with the DNSSEC interpretation or how to solve some of the issues.
In our case, I can tell the following:

The DNSSEC checking is optional, and at the time of the request we had it disabled so we didn´t check it. According to the logs, this cert was requested at 2017-09-09 11:44 GMT+8 and we enabled it a little bit later 2017-09-09 17:41 GMT+8. As we have had some other issues with the DNSSEC, we have disabled it again and are dealing with Primekey to have a better approach to this issue.
Futhermore, according to the logs, at the time of checking for a CAA record, there was none. The lookup was succesful and hence allowed the issuance.

Regarding to your question, I think you´re right and this certificate should have not been issued but it´s also true that having the DNSSEC checking optional, this can happen.


Best regards

Iñigo Barreira
CEO
StartCom CA Limited
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Mads Egil Henriksveen

unread,
Sep 12, 2017, 6:15:32 AM9/12/17
to Quirin Scheitle, mozilla-dev-s...@lists.mozilla.org
Hi

Buypass received the problem report at 2017-09-12 00:06 and started investigating early this morning.

After investigating what happened we identified an error in our system solution when we have a CAA RR lookup failure. In this case, the DNS CAA RR lookup timed out several times and we mis-interpreted this as permission to issue, without verifying the that the domain was DNSSEC signed. This is not permitted according to BR (see ballot paragraph [1]) and we will fix this as soon as possible.

We agree that this certificate should not have been issued and we have revoked the certificate.

Regards
Mads

Nick Lamb

unread,
Sep 12, 2017, 6:26:07 AM9/12/17
to mozilla-dev-s...@lists.mozilla.org
On Tuesday, 12 September 2017 10:38:56 UTC+1, Inigo Barreira wrote:
> Futhermore, according to the logs, at the time of checking for a CAA record, there was none. The lookup was succesful and hence allowed the issuance.

Given that this contradicts the facts alleged in Quirin's tests and the feedback from BuyPass I would strongly recommend doing further testing to ensure that StartCom's systems detect [and log] timeouts and other failures properly for CAA records. I'm sure Quirin will try to offer reasonable assistance in reproducing the problem.

It is definitely worth noting that with DNSSEC _enabled_ a CA ends up having cryptographic proof of their results - which could be recorded in case of any dispute. If you had such proof for the permissive CAA record we wouldn't need to investigate StartCom's systems or policies, we could examine the record and conclude that Querin made an error somewhere and permitted this issuance without knowing anything about StarCom or needing to take you at your word.

Inigo Barreira

unread,
Sep 12, 2017, 6:38:43 AM9/12/17
to Nick Lamb, mozilla-dev-s...@lists.mozilla.org
Ok, let me investigate this further, maybe I didn´t catch it rightly.
For the record, the certificate was revoked

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startco...@lists.mozilla.org]
On Behalf Of Nick Lamb via dev-security-policy
Sent: martes, 12 de septiembre de 2017 12:26
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

On Tuesday, 12 September 2017 10:38:56 UTC+1, Inigo Barreira wrote:
> Futhermore, according to the logs, at the time of checking for a CAA
record, there was none. The lookup was succesful and hence allowed the
issuance.

Given that this contradicts the facts alleged in Quirin's tests and the
feedback from BuyPass I would strongly recommend doing further testing to
ensure that StartCom's systems detect [and log] timeouts and other failures
properly for CAA records. I'm sure Quirin will try to offer reasonable
assistance in reproducing the problem.

It is definitely worth noting that with DNSSEC _enabled_ a CA ends up having
cryptographic proof of their results - which could be recorded in case of
any dispute. If you had such proof for the permissive CAA record we wouldn't
need to investigate StartCom's systems or policies, we could examine the
record and conclude that Querin made an error somewhere and permitted this
issuance without knowing anything about StarCom or needing to take you at
your word.

Inigo Barreira

unread,
Sep 12, 2017, 9:38:22 AM9/12/17
to Inigo Barreira, Nick Lamb, mozilla-dev-s...@lists.mozilla.org
Hi all,

We´ve checked logs and still don´t have a final conclussion but some clues
about it.

There were 2 attempts to request a cert for crossbear.org, the first one was
10 minutes before and was rejected because of timeout but the second, the
one issued, permitted the issuance.

# 1st request for crossbear.org at 11:36
11:36:57,399 INFO [org.cesecore.audit.impl.log4j.Log4jDevice]
(http--0.0.0.0-8443-2) 2017-09-09
11:36:57+08:00;CERT_REQUEST;SUCCESS;CERTIFICATE;CORE;CN=ejbca
ws,C=CN;-366638826;;crossbear.org;subjectdn=CN=crossbear.org,C=DE;requestX50
0name=C=DE,O=TUM,CN=crossbear.org;subjectaltname=DNSNAME=crossbear.org;reque
staltn
ame=;certprofile=2102604971;keyusage=-1;notbefore=;notafter=;sequence=;publi
ckey=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm9PKsCgR0gsedHsp4UgQLzMc9uf
jZvOg5
MkyB8H7DDjuSY3lxcjTMqWHzwMJyJT6q/seCehfXaZ069CQt1vakgvyFhNZT4DhL52FPN3L+EqFI
erT9dUH60aL/bssDZ+L1vJ0R1+1vbM/8ZELPl1zrqhaZInMWvp3odxlhT/MXNR1NFZ4GMctWYyxq
Xg1N94
eQ1HoG18ssVEZx21La6f+DXldxhUHhJUW6H1v+lSpXA32MMytJ9EfIhl5pGFkIz/hx4T9CNSgxId
/qEE2Z5rbl9+vmkjmk5ZqEGOwUlgxxjTVtjp5qJ4TJrtRxu2spKtovvY+b2z4bHT7EjYbBXx00QI
DAQAB
11:37:07,416 ERROR [org.jboss.as.ejb3.tx.CMTTxInterceptor]
(http--0.0.0.0-8443-2) javax.ejb.EJBTransactionRolledbackException:
java.net.SocketTimeoutException
… more exception stack
Caused by: java.lang.IllegalStateException: java.net.SocketTimeoutException
        at
org.ejbca.util.validation.caa.CaaDnsLookup.lookup(CaaDnsLookup.java:534)
[caa.jar:]
        at
org.ejbca.util.validation.caa.CaaDnsLookup.lookupDomain(CaaDnsLookup.java:25
7) [caa.jar:]
        at
org.ejbca.util.validation.caa.CaaDnsLookup.performLookupForDomains(CaaDnsLoo
kup.java:199) [caa.jar:]
        at
org.ejbca.core.model.validation.CaaValidator.validate(CaaValidator.java:108)
[caa.jar:EJBCA 6.9.0.4 Enterprise (r26507)]
… more exception stack
 
# 2nd request for crossbear.org at 11:44
11:44:06,011 INFO [org.cesecore.audit.impl.log4j.Log4jDevice]
(http--0.0.0.0-8443-2) 2017-09-09
11:44:06+08:00;CERT_REQUEST;SUCCESS;CERTIFICATE;CORE;CN=ejbca
ws,C=CN;-366638826;;crossbear.org;subjectdn=CN=crossbear.org,C=DE;requestX50
0name=C=DE,O=TUM,CN=crossbear.org;subjectaltname=DNSNAME=crossbear.org;reque
staltn
ame=;certprofile=2102604971;keyusage=-1;notbefore=;notafter=;sequence=;publi
ckey=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm9PKsCgR0gsedHsp4UgQLzMc9uf
jZvOg5
MkyB8H7DDjuSY3lxcjTMqWHzwMJyJT6q/seCehfXaZ069CQt1vakgvyFhNZT4DhL52FPN3L+EqFI
erT9dUH60aL/bssDZ+L1vJ0R1+1vbM/8ZELPl1zrqhaZInMWvp3odxlhT/MXNR1NFZ4GMctWYyxq
Xg1N94
eQ1HoG18ssVEZx21La6f+DXldxhUHhJUW6H1v+lSpXA32MMytJ9EfIhl5pGFkIz/hx4T9CNSgxId
/qEE2Z5rbl9+vmkjmk5ZqEGOwUlgxxjTVtjp5qJ4TJrtRxu2spKtovvY+b2z4bHT7EjYbBXx00QI
DAQAB
11:44:06,023 INFO [org.cesecore.keys.validation.KeyValidatorSessionBean]
(http--0.0.0.0-8443-2) CAA Validator 'CAAValidator' has permitted issuance
of certificates to issuer startcomca.com.

We have opened a ticket with Primekey to check with them what could be the
issue. Don´t know if between requests there was any change, maybe Quirin can
help.

We´ve also received another 2 request for crossbear.net which were denied
because had a CAA record not listing startcom

# 1st request for crossbear.net at 14:40
14:40:12,068 INFO [org.cesecore.audit.impl.log4j.Log4jDevice]
(http--0.0.0.0-8443-1) 2017-09-09
14:40:12+08:00;CERT_REQUEST;SUCCESS;CERTIFICATE;CORE;CN=ejbca
ws,C=CN;-366638826;;crossbear.net;subjectdn=CN=crossbear.net,C=DE;requestX50
0name=C=DE,O=TUM,CN=crossbear.org;subjectaltname=DNSNAME=crossbear.net;reque
staltn
ame=;certprofile=2102604971;keyusage=-1;notbefore=;notafter=;sequence=;publi
ckey=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm9PKsCgR0gsedHsp4UgQLzMc9uf
jZvOg5
MkyB8H7DDjuSY3lxcjTMqWHzwMJyJT6q/seCehfXaZ069CQt1vakgvyFhNZT4DhL52FPN3L+EqFI
erT9dUH60aL/bssDZ+L1vJ0R1+1vbM/8ZELPl1zrqhaZInMWvp3odxlhT/MXNR1NFZ4GMctWYyxq
Xg1N94
eQ1HoG18ssVEZx21La6f+DXldxhUHhJUW6H1v+lSpXA32MMytJ9EfIhl5pGFkIz/hx4T9CNSgxId
/qEE2Z5rbl9+vmkjmk5ZqEGOwUlgxxjTVtjp5qJ4TJrtRxu2spKtovvY+b2z4bHT7EjYbBXx00QI
DAQAB
14:40:12,447 INFO [org.ejbca.util.validation.caa.CaaDnsLookup]
(http--0.0.0.0-8443-1) Found CAA Record for domain crossbear.net.:
crossbear.net.
  300 IN CAA 0 issue ";"
14:40:12,447 INFO [org.ejbca.util.validation.caa.CaaDnsLookup]
(http--0.0.0.0-8443-1) Found CAA Record for domain crossbear.net.:
crossbear.net.
  300 IN CAA 0 iodef "mailto:c...@crossbear.net"
14:40:12,448 INFO [org.cesecore.audit.impl.log4j.Log4jDevice]
(http--0.0.0.0-8443-1) 2017-09-09
14:40:12+08:00;VALIDATOR_VALIDATION_FAILED;FAILURE;VALIDATOR;
CORE;CN=ejbcaws,C=CN;-366638826;;crossbear.net;msg=CAA Validator
'CAAValidator' failed issuance of certificates to issuer startcomca.com.

# 2nd request for crossbear.net at 14:41
14:41:00,891 INFO [org.cesecore.audit.impl.log4j.Log4jDevice]
(http--0.0.0.0-8443-1) 2017-09-09
14:41:00+08:00;CERT_REQUEST;SUCCESS;CERTIFICATE;CORE;CN=ejbca
ws,C=CN;-366638826;;crossbear.net;subjectdn=CN=crossbear.net,C=DE;requestX50
0name=C=DE,O=TUM,CN=crossbear.org;subjectaltname=DNSNAME=crossbear.net;reque
staltn
ame=;certprofile=2102604971;keyusage=-1;notbefore=;notafter=;sequence=;publi
ckey=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm9PKsCgR0gsedHsp4UgQLzMc9uf
jZvOg5
MkyB8H7DDjuSY3lxcjTMqWHzwMJyJT6q/seCehfXaZ069CQt1vakgvyFhNZT4DhL52FPN3L+EqFI
erT9dUH60aL/bssDZ+L1vJ0R1+1vbM/8ZELPl1zrqhaZInMWvp3odxlhT/MXNR1NFZ4GMctWYyxq
Xg1N94
eQ1HoG18ssVEZx21La6f+DXldxhUHhJUW6H1v+lSpXA32MMytJ9EfIhl5pGFkIz/hx4T9CNSgxId
/qEE2Z5rbl9+vmkjmk5ZqEGOwUlgxxjTVtjp5qJ4TJrtRxu2spKtovvY+b2z4bHT7EjYbBXx00QI
DAQAB
14:41:00,905 INFO [org.ejbca.util.validation.caa.CaaDnsLookup]
(http--0.0.0.0-8443-1) Found CAA Record for domain crossbear.net.:
crossbear.net.
  252 IN CAA 0 issue ";"
14:41:00,905 INFO [org.ejbca.util.validation.caa.CaaDnsLookup]
(http--0.0.0.0-8443-1) Found CAA Record for domain crossbear.net.:
crossbear.net.
  252 IN CAA 0 iodef "mailto:c...@crossbear.net"
14:41:00,906 INFO [org.cesecore.audit.impl.log4j.Log4jDevice]
(http--0.0.0.0-8443-1) 2017-09-09
14:41:00+08:00;VALIDATOR_VALIDATION_FAILED;FAILURE;VALIDATOR;
CORE;CN=ejbcaws,C=CN;-366638826;;crossbear.net;msg=CAA Validator
'CAAValidator' failed issuance of certificates to issuer startcomca.com.

We´ll keep investigating this.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startco...@lists.mozilla.org]
On Behalf Of Inigo Barreira via dev-security-policy
Sent: martes, 12 de septiembre de 2017 12:44
To: Nick Lamb <tiala...@gmail.com>;
mozilla-dev-s...@lists.mozilla.org
Subject: RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

Ok, let me investigate this further, maybe I didn´t catch it rightly.
For the record, the certificate was revoked

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startco...@lists.mozilla.org]
On Behalf Of Nick Lamb via dev-security-policy
Sent: martes, 12 de septiembre de 2017 12:26
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

On Tuesday, 12 September 2017 10:38:56 UTC+1, Inigo Barreira wrote:
> Futhermore, according to the logs, at the time of checking for a CAA
record, there was none. The lookup was succesful and hence allowed the
issuance.

Given that this contradicts the facts alleged in Quirin's tests and the
feedback from BuyPass I would strongly recommend doing further testing to
ensure that StartCom's systems detect [and log] timeouts and other failures
properly for CAA records. I'm sure Quirin will try to offer reasonable
assistance in reproducing the problem.

It is definitely worth noting that with DNSSEC _enabled_ a CA ends up having
cryptographic proof of their results - which could be recorded in case of
any dispute. If you had such proof for the permissive CAA record we wouldn't
need to investigate StartCom's systems or policies, we could examine the
record and conclude that Querin made an error somewhere and permitted this
issuance without knowing anything about StarCom or needing to take you at
your word.

Quirin Scheitle

unread,
Sep 12, 2017, 5:58:34 PM9/12/17
to mozilla-dev-s...@lists.mozilla.org
Hi all,

Thank you for the replies. I am glad that there is agreement these certificates should not have been issued.

I am confident that the test behaved correctly, the last edit on the zone file was on Aug 31 17:24, and it reads:

crossbear.org. 0 CAA 0 issue ";"

So even if requests would somehow have gotten through the iptables rule dropping them, it would definitely not have gotten a permitting record.

I also have full pcaps from both name servers serving this domain and can confirm that not a single query response was sent to any server on September 8th and 9th.

crossbear.net is a different domain with a different configuration, it is unrelated to this issue.

Inigo, I am very happy to debug this in detail offline -- I have plenty of records and data to assist debugging.

Kind regards
Quirin

Inigo Barreira

unread,
Sep 13, 2017, 3:28:52 AM9/13/17
to Quirin Scheitle, mozilla-dev-s...@lists.mozilla.org
Thanks Quirin, we´re working with Primekey to know what happened (we´ll
generate a report once known) and will contact you if necessary to check
that info you have.

Regarding the logs, the log message actually means that CAA either
explicitly permitted the issuance, or implicitly permitted issuance (e.g. by
the lack of a CAA record, that according to this email that´s no the case).
We´re also checking if the DNS resolver server was caching the timeout
failure and sent a SERVFAIL or similar response the second time, rather than
letting the query time out again. But, as said, we´re still investigating
the issue.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startco...@lists.mozilla.org]
On Behalf Of Quirin Scheitle via dev-security-policy
Sent: martes, 12 de septiembre de 2017 20:30
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

Quirin Scheitle

unread,
Sep 13, 2017, 9:06:21 AM9/13/17
to mozilla-dev-s...@lists.mozilla.org
Hi,

just wanted to update that Certum has also issued on this domain: https://crt.sh/?id=209378608

I have opened a support ticket, which has led to revocation but not a qualified statement as to what happened yet.

Kind regards
Quirin
0 new messages