Hi Jeffrey-- On 03/18/2014 01:43 AM, Jeffrey Walton wrote: > I believe wget has a security flaw in its certificate hostname matching code. > > In the attached server certificate, the hostname is provided via a > Subject Alt Name (SAN). The only SAN entry is a DNS name for "*.com". > Also attached is the default CA, which was used to sign the server's > certificate.
thanks for raising this concern. Have you tested this certificate and CA with other HTTPS clients (like browsers?) Section 11.1.3 of the CA/Browser Forum's baseline requirements for CAs are that compliant CAs MUST NOT issue wildcard certs for an entire registry-controlled zone or public suffix "unless the applicant proves its rightful control of the entire Domain Namespace": https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf So arguably, it is the responsibility of the CA, not the responsibility of the relying party, to determine what certs are legitimate. Put another way: should every TLS client library embed the public suffix list? how often should they update it? What if a certificate is issued by a trusted CA that *does* match part of the public suffix list (perhaps because the CA has determined tha tthe application has rightful control over the entire zone)? --dkg
signature.asc
Description: OpenPGP digital signature
