Ted Wynnychenko wrote: [...] > I block connections based on a list from malwaredomains.com. > A script runs nightly that downloads the list/changes, creates > zone files, and reloads unbound/nsd. The "blocked" zone files > point those domains at an internal (10.0.x.x) IP address. [...] > From my looking, it appears that a certificate is only accepted > by browsers with "one level" of domain wildcard present; so I am > not sure how to get a certificate with a common name of * to be > accepted for any/every domain.
Perhaps this is an idea: enable the v3 extensions in your configuration file and add something like subjectAltName = @bad_actors [bad_actors] DNS.1 = malware1.tld DNS.2 = *.malware1.tld DNS.3 = malware2.tld DNS.4 = *.malware2.tld ... After your nightly download from malwaredomains.com you could add the new malware-domains to the list [bad_actors] too and regenerate this multi-domain wildcard certificate. This should work around the "one level" of wildcards limit you discovered in Firefox. As long as you use your own CA to sign (as opposed to selfsigning) and the browser knows about the corresponding Root Certificate there should be no problem with having a new certificate every morning. However, this hinges on the fact that entries in the subjectAltName section are in fact allowed to contain wildcards. RFC5280 [1] carefully avoids "the semantics of subject alternative names that include wildcard characters" so it may or may not work in different browsers. Also, I am not sure how many entries are allowed in that section, I suppose there is some limit somewhere. However, perhaps it is worth a try? --Peter Fokker [1] https://tools.ietf.org/html/rfc5280#section-4.2.1.6 and https://tools.ietf.org/html/rfc5280#page-38
