You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While PKIX certificate usages are optional, for complete DANE implementation we should support DANE-TA(2). This is useful if server administrators that would like to pin self-signed CA instead of pinning an individual end entity certificate for each service.
From RFC7671
Some domains may prefer to avoid the operational complexity of
publishing unique TLSA RRs for each TLS service. If the domain
employs a common issuing CA to create certificates for multiple TLS
services, it may be simpler to publish the issuing authority as a TA
for the certificate chains of all relevant services. The TLSA query
domain (TLSA base domain with port and protocol prefix labels) for
each service issued by the same TA may then be set to a CNAME alias
that points to a common TLSA RRset that matches the TA
The text was updated successfully, but these errors were encountered:
Designs in which clients support just the DANE-TA(2) and DANE-EE(3)
certificate usages are RECOMMENDED. With DANE-TA(2) and DANE-EE(3),
clients don't need to track a large changing list of X.509 TAs in
order to successfully authenticate servers whose certificates are
issued by a CA that is brand new or not widely trusted.
While PKIX certificate usages are optional, for complete DANE implementation we should support DANE-TA(2). This is useful if server administrators that would like to pin self-signed CA instead of pinning an individual end entity certificate for each service.
From RFC7671
The text was updated successfully, but these errors were encountered: