5 ms·
Offtopic but related question: is there any TLD for which a first-level wildcard is allowed in SSL certs? (I mean "* .tld" instead of second-level such as "* .f
by j1elo 6y ago
Offtopic but related question: is there any TLD for which a first-level wildcard is allowed in SSL certs? (I mean "* .tld" instead of second-level such as "* .foo.tld").
TLDR; I feel like there should be a special dev-only TLD for certs that go on example code, which skipped all the certificate management limitations. Suggestions are welcome!
It is so cumbersome to provide WebRTC sample apps and tutorials that can be universally run for testing purposes. WebRTC requires HTTPS, and thankfully an untrusted self-signed cert will do for Firefox and Chrome (they will show a warning page that the user can accept); iOS further requires that the certificate is trusted (so no warning page is shown and the load silently hangs on an infinite reload loop, which is nasty if you ask me; to avoid this, you can manually install custom Root CAs to the device).
So, my WebRTC tutorials and demos need to include a self-signed cert that allows users to deploy in their LAN and do a quick test [0]. Browsers tend to accept "localhost" as a safe origin, but what happens with testing on LAN? I feel there should be some convention there, it's not very helpful to test a WebRTC application just on localhost.
To not assume any given LAN subnet, I create my self-signed certs for these domains [1]:
127.0.0.1
::1
localhost
*.test.local
That way, users can create a quick DNS redirection from some .test.local domain to their server (e.g. using avahi-publish command), install the root cert in iOS, and test from an Apple device.
But I'd love if it was possible to just define a first level wildcard:
*.test
*.local
or similar.
Actually the .local domain would be perfect! Thanks to mDNS, when available, all hostnames automatically get their <hostname>.local address, which would be great for an easier than ever setup. Alas, MacOS seems to reject first-level wildcards.
To add to the problem, these demo self-signed certs were created for 10 years, which is fine because I want to drop then on the Git repo and forget about them. But now the maximum allowed longevity for newly created certs is enforced to be a measly 398 days.
Why does all this need to be so needlessly complicated? I guess people will tell me to put in place a cert-renewal scheme, using some CI for all repos that contain demo code or tutorials, but that's highly undesired... There are even people suggesting that certs should live for just days or hours, I guess they are not thinking on this simple use case, for which I don't know if there is an escape hatch.
As mentioned in the TLDR; suggestions are welcome!
[0]: https://github.com/Kurento/mediasoup-demos https://github.com/Kurento/mediasoup-demos
[1]: https://doc-kurento.readthedocs.io/en/latest/features/security.html#generating-a-self-signed-certificate https://doc-kurento.readthedocs.io/en/latest/features/securi...
- jlgaddis 6y ago> Offtopic but related question: is there any TLD for which a first-level wildcard is allowed in SSL certs? Nope (unless you own "an entire gTLD"). From the CA/Browser Forum's Baseline Requirements (v1.7.3) [0] (with a few links/references added): -- 3.2.2.6 Wildcard Domain Validation Before issuing a certificate with a wildcard character (*) in a CN or subjectAltName of type DNS-ID, the CA MUST establish and follow a documented procedure that determines if the wildcard character occurs in the first label position to the left of a “registry-controlled” label or “public suffix” (e.g. “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 [1] for further explanation). If a wildcard would fall within the label immediately to the left of a registry-controlled /1 or public suffix, CAs MUST refuse issuance unless the applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue “*.co.uk” or “*.local”, but MAY issue “*.example.com” to Example Co.). Determination of what is “registry-controlled” versus the registerable portion of a Country Code Top-Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a “public suffix list” such as the Public Suffix List (PSL) [2,3, and to retrieve a fresh copy regularly. If using the PSL, a CA SHOULD consult the “ICANN DOMAINS” section only, not the “PRIVATE DOMAINS” section. The PSL is updated regularly to contain new gTLDs delegated by ICANN, which are listed in the “ICANN DOMAINS” section. A CA is not prohibited from issuing a Wildcard Certificate to the Registrant of an entire gTLD, provided that control of the entire namespace is demonstrated in an appropriate way. -- [0]: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-... (PDF) [1]: https://tools.ietf.org/html/rfc6454#section-8.2 https://tools.ietf.org/html/rfc6454#section-8.2 [2]: https://publicsuffix.org/ https://publicsuffix.org/ [3]: https://publicsuffix.org/list/public_suffix_list.dat https://publicsuffix.org/list/public_suffix_list.dat
- j1elo 6y agoThanks. So the CA/Browser Forum has given space for this in their definitions, but lack establishing one of those TLD for the use case I mention. Which surprises me. We even have IP address ranges defined for usage in examples in documentation... How come no TLD has been assigned for development purposes with relaxed requirements. Everybody needs to develop, as a first step before using an actual TLD. Just use .lan or similar!