Price increase on .io on January 21, 2021
Offtopic but related question: is there any TLD for which a first-level wildcard is allowed in SSL certs? (I mean &quot;* .tld&quot; instead of second-level such as &quot;* .foo.tld&quot;).<p>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!<p>It is so cumbersome to provide WebRTC sample apps and tutorials that can be universally run for testing purposes. WebRTC <i>requires</i> 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 <i>nasty</i> if you ask me; to avoid this, you can manually install custom Root CAs to the device).<p>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 &quot;localhost&quot; as a safe origin, but what happens with testing on LAN? I feel there should be some convention there, it&#x27;s not very helpful to test a WebRTC application just on localhost.<p>To not assume any given LAN subnet, I create my self-signed certs for these domains [1]:<p><pre><code>  127.0.0.1
  ::1
  localhost
  *.test.local
</code></pre>
That way, users can create a quick DNS redirection from some .test.local domain to their server (e.g. using <i>avahi-publish</i> command), install the root cert in iOS, and test from an Apple device.<p>But I&#x27;d love if it was possible to just define a first level wildcard:<p><pre><code>  *.test
  *.local
</code></pre>
or similar.<p>Actually the .local domain would be perfect! Thanks to mDNS, when available, all hostnames automatically get their &lt;hostname&gt;.local address, which would be great for an easier than ever setup. Alas, MacOS seems to reject first-level wildcards.<p>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.<p>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&#x27;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&#x27;t know if there is an escape hatch.<p>As mentioned in the TLDR; suggestions are welcome!<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;Kurento&#x2F;mediasoup-demos" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Kurento&#x2F;mediasoup-demos</a><p>[1]: <a href="https:&#x2F;&#x2F;doc-kurento.readthedocs.io&#x2F;en&#x2F;latest&#x2F;features&#x2F;security.html#generating-a-self-signed-certificate" rel="nofollow">https:&#x2F;&#x2F;doc-kurento.readthedocs.io&#x2F;en&#x2F;latest&#x2F;features&#x2F;securi...</a>