Wildcard cert. Should I add to my DNS: @ 3600 IN CAA 0 issuewild "letsencrypt.org"?

I have recently moved to a DNS provider who supports a DNS-challenge, so I could issue my first LE wildcard certificate.

My DNS already had a couple of simple issue CAA records:

albus	3600	 IN 	CAA	0	issue	"letsencrypt.org"
mail	3600	 IN 	CAA	0	issue	"letsencrypt.org"
snape	3600	 IN 	CAA	0	issue	"letsencrypt.org"
www	3600	 IN 	CAA	0	issue	"letsencrypt.org"

This was OK when I created the wildcard cert for rna.nl and *.rna.nl

Should I add

@	3600	 IN 	CAA	0	issuewild	"letsencrypt.org"

?

(I haven't started using the new wildcard cert yet).

  1. You don't need to add CAA records to specific FQDNs.
    Using "rna.nl" would cover the entire domain [and all possible subdomains].

  2. Only you can answer the question posed.
    If you only want LE to issue wildcard certs for your domain...
    Then "YES".
    If not, then "NO".

7 Likes

No, the issue directive (or how it's called) should also be enough to allow wildcards.

See also e.g. CAA Record Generator or other CAA generators.

6 Likes

Are you trying to allow LE to issue certs?
Such CAA entries are designed to limit issuances to ONLY those listed.
If nothing is listed, then ALL are allowed.
So, you don't need to explicitly put an entry to allow LE to issue certs.
You would put in such an entry to ONLY allow LE to issue such certs.

5 Likes

From here https://www.rfc-editor.org/rfc/rfc2181.txt
5.2. TTLs of RRs in an RRSet

Resource Records also have a time to live (TTL). It is possible for
the RRs in an RRSet to have different TTLs. No uses for this have
been found that cannot be better accomplished in other ways. This
can, however, cause partial replies (not marked "truncated") from a
caching server, where the TTLs for some but not all the RRs in the
RRSet have expired.

Consequently the use of differing TTLs in an RRSet is hereby
deprecated, the TTLs of all RRs in an RRSet must be the same.

Should a client receive a response containing RRs from an RRSet with
differing TTLs, it should treat this as an error. If the RRSet
concerned is from a non-authoritative source for this data, the
client should simply ignore the RRSet, and if the values were
required, seek to acquire them from an authoritative source. Clients
that are configured to send all queries to one, or more, particular
servers should treat those servers as authoritative for this purpose.

2 Likes

That was exactly the idea. Only LE is allowed to.

Thanks for this info (it's getting a bit OT but it is interesting nonetheless). The DNS provider (GoDaddy for now) forces you to choose a TTL when adding a record and they do not limit this at domain-wide level. If I understand the RFC correctly, the only way to manage this strict equality for all TTLs is to make sure you only use a single TTL everywhere. The question is of course, where/how to do that? The SOA has its own time values for caching etc. and as the RFC you mention says, this was supposed to be always 0 but nobody implements it that way. Anyway, my guess is that if I use 3600 everywhere, it is as good as it can make it.

2 Likes

Then you only need two entries one entry:
@ 3600 IN CAA 0 issue "letsencrypt.org"
@ 3600 IN CAA 0 issuewild "letsencrypt.org"

5 Likes

Actually the issue directive is enough. When no issuewilds are present, issue also controls wildcard issuance.

So for this use case you only need a single CAA record.

7 Likes

Thanks @Nummer378 and @rg305.

Just curious, What then is the behavioural difference between

@ 3600 IN CAA 0 issue "letsencrypt.org"

and

@ 3600 IN CAA 0 issuewild "letsencrypt.org"

if in both cases that is the only CAA record I have? 'issuewild' is less permissive (wild only?) than 'issue'?

5 Likes

From here DNS Certification Authority Authorization - Wikipedia
(look to the link for nicer formatting)

Certificate authorities implementing CAA perform a DNS lookup for CAA resource records, and if any are found, ensure that they are listed as an authorized party before issuing a digital certificate. Each CAA resource record consists of the following components:[11]

flag
A flags byte which implements an extensible signaling system for future use. As of 2018, only the issuer critical flag has been defined, which instructs certificate authorities that they must understand the corresponding property tag before issuing a certificate.[11] This flag allows the protocol to be extended in the future with mandatory extensions,[4] similar to critical extensions in X.509 certificates.
tag
One of the following property:

issue
This property authorizes the holder of the domain specified in associated property value to issue certificates for the domain for which the property is published.
issuewild
This property acts like issue but only authorizes the issuance of wildcard certificates, and takes precedence over the issue property for wildcard certificate requests.
iodef
This property specifies a method for certificate authorities to report invalid certificate requests to the domain name holder using the Incident Object Description Exchange Format. As of 2018, not all certificate authorities support this tag, so there is no guarantee that all certificate issuances will be reported.
contactemail
Increasingly, contact information is not available in WHOIS due to concerns about potential GDPR violations. This property allows domain holders to publish contact information in DNS.[13][14]
contactphone
As above, for phone numbers.[15]

value
The value associated with the chosen property tag.

The lack of any CAA records authorizes normal unrestricted issuance, and the presence of a single blank issue tag disallows all issuance

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.