Closed Bug 1931615 Opened 3 months ago Closed 2 months ago

SSL.com: Entrust API and CAA checking

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1932973

People

(Reporter: rileymags0901, Assigned: rebeccak)

References

Details

(Whiteboard: [ca-compliance] [ov-misissuance] [external])

Steps to reproduce:

  1. Created CAA record ";" on hyatt-test.com
  2. DNS verified domain with Entrust
  3. Issued certificate via Entrust's API for *.hyatt-test.com - signed by SSL.com

Actual results:
A certificate for *.hyatt-test.com was issued when it should not have. No CAs are allowed to issue ANY certificates on the domain.

Expected results:
Lack of an issuewild CAA record still makes the issue property valid for wildcard certificates. Inclusion of hyatt-test.com IN CAA 0 issue ";" should not allow ANY certificates to be issued for the domain. See page 2 section "introduction": https://www.entrust.com/sites/default/files/documentation/userguides/caa-best-practices-guide---25aug2017.pdf

"If there is at least one CAA issue record, but none of them match the no issuer domain name from the CA’s CPS, then the CA cannot issue certificates."

We did test issuance for test.hyatt-test.com and received an error. We also tested with other values in the CAA record (like ssl.com, Entrust.com, etc) and it will issue a wilcard certificate regardless of situation.

Entrust was notified via web form 11/14/2024 1:42 PM CST and opened an investigation 2024/11/15 11:20:35 AM CST

Duplicate of this bug: 1931417

Hi Riley,
Do you have a crt.sh link to the misissued certificate?
Thanks,
Ben

Type: defect → task
Flags: needinfo?(rileymags0901)

(In reply to Ben Wilson from comment #2)

Hi Riley,
Do you have a crt.sh link to the misissued certificate?
Thanks,
Ben

https://crt.sh/?id=15354471911

(In reply to Riley Magnuson from comment #0)

Steps to reproduce:

  1. Created CAA record ";" on hyatt-test.com
  2. DNS verified domain with Entrust
  3. Issued certificate via Entrust's API for *.hyatt-test.com - signed by SSL.com

Actual results:
A certificate for *.hyatt-test.com was issued when it should not have. No CAs are allowed to issue ANY certificates on the domain.

Expected results:
Lack of an issuewild CAA record still makes the issue property valid for wildcard certificates. Inclusion of hyatt-test.com IN CAA 0 issue ";" should not allow ANY certificates to be issued for the domain. See page 2 section "introduction": https://www.entrust.com/sites/default/files/documentation/userguides/caa-best-practices-guide---25aug2017.pdf

"If there is at least one CAA issue record, but none of them match the no issuer domain name from the CA’s CPS, then the CA cannot issue certificates."

We did test issuance for test.hyatt-test.com and received an error. We also tested with other values in the CAA record (like ssl.com, Entrust.com, etc) and it will issue a wilcard certificate regardless of situation.

Entrust was notified via web form 11/14/2024 1:42 PM CST and opened an investigation 2024/11/15 11:20:35 AM CST

Hi Riley,

Thanks for your report and for providing plenty of information for SSL.com to investigate this issue. Before we dive into the details, we want to clarify that the certificate was issued based on domain validation performed by SSL.com.

On 2024-11-15, SSL.com received a Certificate Problem Report (CPR) regarding a potential misprocessing of a CAA “issue ;” record which resulted in the issuance of a wildcard TLS certificate https://crt.sh/?id=15354471911 by SSL.com. The report was processed by SSL.com, according to the CPR procedures and within the required 24-hours. On the same day, an investigation was initiated to determine whether the issue constitutes a violation.

After an in-depth analysis of RFC 8659, it is our opinion that there is some ambiguity due to the lack of explicit language that states the "issue" tag should also be considered a restriction for Wildcard Domain Names in addition to Fully Qualified Domain Names (FQDNs) (defined terms).

However, this is implied indirectly through an example in section 4.3 which states:

The following RRset requests that only ca1.example.net issue certificates for "wild2.example.com", 
"*.wild2.example.com", or "*.sub  .wild2.example.com".  

wild2.example.com         CAA 0 issue "ca1.example.net"

implying that no other CA is allowed to issue wildcard certificates except for “ca1.example.net”.

By extension, if the value is ";" (the empty set), no CA is allowed to issue FQDNs but also Wildcard Domain Names.

Therefore, the "issue" tag alone, controls the CA authorization of FQDNs AND Wildcard Domain Names that end with all the labels of the FQDN of the RR, if there is no RR with the "issuewild" tag, which then takes precedence over the "issue" tag for Wildcard Domain Names.

While this expectation is reasonable for a positive indication that a specific CA is authorized to issue certificates for a specific domain name, and this should be considered true for FQDNs and Wildcard Domain Names, it is not reasonable for being used as a negative indicator for the empty set. If that’s the case, it would be impossible for a domain owner to signal allowance of issuance on ONLY Wildcard Domain Names from ALL CAs.

The reverse signal is possible by adding an empty set for both “issue” and “issuewild” tags.

SSL.com continued the investigation by checking the behavior of the CA software CAA Validator and confirmed that the existence of any value except the empty set “;” in the “issue” tag, is also being checked when a Wildcard Domain Name is being requested, restricting issuance to the CA that is listed in the “issue” tag when there is no “issuewild” tag.

We are not certain if this should be considered a mis-issuance, which is why we took more time to analyze before posting this response. SSL.com is asking the community for feedback on this matter, in the hope of obtaining a general understanding of how this RFC is implemented throughout the community. Using the empty set for the issue tag to prevent issuance of Wildcard Domain Names in general, seems like an edge case.

(Wearing RFC8659 co-author hat)

RFC8659 section 4.3 (CAA issuewild Property) begins by saying that (emphasis mine):
"The issuewild Property Tag has the same syntax and semantics as the issue Property Tag except that it only grants authorization to issue certificates that specify a Wildcard Domain Name and each issuewild Property takes precedence over each issue Property when specified."

"same...except that it only" can only mean that "issuewild" applies to a subset (specifically, Wildcard Domain Names) of the domain names that "issue" applies to (namely, all domain names). It would not make any sense to use that phrase if "issue" and "issuewild" were intended to apply to two completely separate sets.

Also, "takes precedence over each issue Property" only has meaning because the scope of "issue" includes Wildcard Domain Names. There would be no notion of precedence if "issue" and "issuewild" were intended to apply to two completely separate sets.

Section 4.2 (CAA issue Property) doesn't use the word "Wildcard", but that's because it doesn't need to. Each "issue" tag (emphasis mine):
"is a request that Issuers:
1- Perform CAA issue restriction processing for the FQDN, and
2- Grant authorization to issue certificates containing that FQDN to the holder of the issuer-domain-name or a party acting under the explicit authority of the holder of the issuer-domain-name."

Wildcard Domain Names are (or, more correctly, are suffixed by) FQDNs, and certificates containing Wildcard Domain Names are obviously certificates, so they're in scope for section 4.2.

Section 4.3 also says:
"Each issuewild Property MUST be ignored when processing a request for an FQDN that is not a Wildcard Domain Name."

It's no accident that there is no corresponding sentence in section 4.2 that declares Wildcard Domain Names out of scope for "issue" properties.

Thanks Rob, I was about to write the same thing.

Note that the *.deny.basic.caatestsuite.com test case checks for this. Does SSL.com not make use of https://caatestsuite.com/?

Assignee: nobody → rebeccak
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Entrust w/ SSL.com issues wildcards despite CAA rules → SSL.com: Entrust API and CAA checking
Whiteboard: [ca-compliance] [ov-misissuance]

(In reply to Rob Stradling from comment #5)

(Wearing RFC8659 co-author hat)

RFC8659 section 4.3 (CAA issuewild Property) begins by saying that (emphasis mine):
"The issuewild Property Tag has the same syntax and semantics as the issue Property Tag except that it only grants authorization to issue certificates that specify a Wildcard Domain Name and each issuewild Property takes precedence over each issue Property when specified."

"same...except that it only" can only mean that "issuewild" applies to a subset (specifically, Wildcard Domain Names) of the domain names that "issue" applies to (namely, all domain names). It would not make any sense to use that phrase if "issue" and "issuewild" were intended to apply to two completely separate sets.

Also, "takes precedence over each issue Property" only has meaning because the scope of "issue" includes Wildcard Domain Names. There would be no notion of precedence if "issue" and "issuewild" were intended to apply to two completely separate sets.

Section 4.2 (CAA issue Property) doesn't use the word "Wildcard", but that's because it doesn't need to. Each "issue" tag (emphasis mine):
"is a request that Issuers:
1- Perform CAA issue restriction processing for the FQDN, and
2- Grant authorization to issue certificates containing that FQDN to the holder of the issuer-domain-name or a party acting under the explicit authority of the holder of the issuer-domain-name."

Wildcard Domain Names are (or, more correctly, are suffixed by) FQDNs, and certificates containing Wildcard Domain Names are obviously certificates, so they're in scope for section 4.2.

Section 4.3 also says:
"Each issuewild Property MUST be ignored when processing a request for an FQDN that is not a Wildcard Domain Name."

It's no accident that there is no corresponding sentence in section 4.2 that declares Wildcard Domain Names out of scope for "issue" properties.

Thank you Rob for the insight and the detailed explanations about the intent.

We agree and interpret this similarly for any “issue” tag value that serves as a positive indicator by the domain owner. For example,

example.com CAA 0 issue "ca1.example.net"

means that "ca1.example.net" is the only CA allowed to issue FQDNs and Wildcard Domain Names under example.com. If SSL.com attempted to issue a Wildcard Certificate to *.example.com, it would be prevented by the CAA validator because the value does not match “ssl.com”.

Without disregarding the intent of the RFC authors, the actual language and examples do not provide enough clarity on the empty set use. The following language from the RFC:

For example, the following RRset requests that no certificates be issued for the FQDN "nocerts.example.com" by any Issuer.

nocerts.example.com CAA 0 issue ";"

would be much clearer if the text said:

no certificates be issued for the FQDN "nocerts.example.com"** or any Wildcard Domain Name under "nocerts.example.com"** by any Issuer

We still see an issue with the “issue” tag being used as a negative indicator in the sense that the empty set “;” should prohibit issuance to all FQDNs and Wildcard Domain Names.

To reach to a conclusion, let’s examine all the possible “catch-all” combinations from a domain owner’s perspective:

  1. Allow issuance of FQDNs and Wildcard Domain Names by all CAs --> do not include CAA “issue” or “issuewild”

  2. Allow issuance of FQDNs by all CAs and prevent issuance of Wildcard Domain Names by all CAs --> include just the CAA “issuewild” with an empty set “;”

  3. Prevent issuance of FQDNs and Wildcard Domain Names by all CAs --> include the CAA “issuewild” and “issue” with an empty set “;”

  4. Allow issuance of Wildcard Domain Names by all CAs and prevent issuance of FQDNs by all CAs --> Include the CAA “issue” with an empty set “;”

There is some difference in the interpretation of 3 and 4. According to your description, the “issue” with an empty set “;” would be considered enough to prevent issuance for FQDNs and Wildcard Domain Names. If that’s the case, we can’t think of any semantics that can support case 4.

(In reply to Andrew Ayer from comment #6)

Thanks Rob, I was about to write the same thing.

Note that the *.deny.basic.caatestsuite.com test case checks for this. Does SSL.com not make use of https://caatestsuite.com/?

Thanks Andrew. We initially tested all cases described in https://caatestsuite.com/ back in 2017 and re-checked. The example you mentioned (“*.deny.basic.caatestsuite.com “) was tested and gets blocked by our CAA validator.

The “empty.basic.caatestsuite.com” test case did not mention the expected outcome for Wildcard Domain Names. Would you consider adding “*.empty.basic.caatestsuite.com” to explain what the expected behavior should be, if there is only one CAA record with “issue” “;”?

We appreciate the patience as we try to get a better understanding of what is written and actually intended by RFC 8659.

We have also notified our CA software vendor to review this bug and share their initial interpretation when implementing RFC 6844, and then 8659, in the CAA validator component.

The instance that would support case 4 - in my understanding - is an "issue" with empty set ";" and "issuewild" with "ssl.com" as "issuewild" always takes precedence over "issue" when it is implemented when applying to wildcard FQDNs. (RFC8659 section 4.3 CAA issuewild Property)

ie:
example.com CAA 0 issue ";"
example.com CAA 0 issuewild "ca1.example.net"

The language from the RFC:

For example, the following RRset requests that no certificates be issued for the FQDN "nocerts.example.com" by any Issuer.
in my opinion, is very clear: "no certificates", period. It might help to have an example with the records above as a solution to case 4 in the RFC as required.

Correcting the markdown from above:

The language from the RFC:

For example, the following RRset requests that no certificates be issued for the FQDN "nocerts.example.com" by any Issuer.

in my opinion, is very clear: "no certificates", period. It might help to have an example with the records above as a solution to case 4 in the RFC as required.

Flags: needinfo?(rileymags0901)

RFC 8659 states, separately, that:

  1. An empty issue Property prevents all CAs from issuing.
  2. The issue Property applies to Wildcard Domain Names when the Relevant RRSet contains no issuewild Property.

SSL.com agrees with the above, since their CAA implementation correctly denies empty.basic.caatestsuite.com and *.deny.basic.caatestsuite.com, which respectively test these two rules. This suggests that there is no problem with the clarity of these rules, individually.

RFC 8659 doesn't explicitly say what to do in the case of a Wildcard Domain Name with an empty issue Property and no issuewild Property (e.g. *.empty.basic.caatestsuite.com or *.hyatt-test.com). But it doesn't need to, because the two rules above say what to do - deny issuance.

It's true that applying both rules means there is no way to express a policy of "no non-wildcard issuance but unrestricted wildcard issuance". But that doesn't mean that RFC 8659 is unclear and that it's OK to act like one of the rules doesn't exist. The right thing to do when a desired use case is not allowed is to propose a change to the RFC.

Thank you all for your comments and contributions. After careful analysis of all information gathered, SSL.com is hereby filing the following preliminary incident report.

Please refer to Bug #1932973, which appears to supersede/duplicate most of the underlying facts of this bug/incident. To streamline tracking the discussion and resolution of this incident, I will be closing this bug as a duplicate of Bug #1932973.

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Duplicate of bug: 1932973
Resolution: --- → DUPLICATE
Whiteboard: [ca-compliance] [ov-misissuance] → [ca-compliance] [ov-misissuance] [external]
You need to log in before you can comment on or make changes to this bug.