| BBlack added a comment. |
It's a pain any direction we slice this, and I'm not fond of adding new canonical domains outside the known set for individual low-traffic projects. We didn't add new domains for a variety of other public-facing efforts (e.g. wdqs, ORES, maps, etc).
We don't have clear standards about these things, and frankly some of the existing legacy canonical project domains currently bloating our unified certs probably wouldn't comply with any standard I'd want to put in place here going forward, either. Those other projects domains are "special" though, in that they can only reasonably be handled via commercial wildcards today due to the language-subdomain issues.
We're not structured in such a way that adding new domain registrations to our termination is trivial, and I'm not sure it's ever going to be completely trivial. There is always going to be some overhead associated with it, and we don't in the general case want to build up a pile of canonical domains that are mostly low-traffic and/or defunct but kept around for historical compatibility.
The three paths forward to support the unique wikiba.se domainname on our termination are:
- Add it to our unified certs that we just renewed. This costs some $$ ongoing per-year, and will require us to prove ownership of the domain first before we integrate it (we need it in our DNS control either way). It also bloats the unified certificate size sent with every session on all projects (e.g. every TLS handshake for enwiki), which makes it really unpalatable to add new things here that could just as easily have been wikimedia.org subdomains for smaller projects "for free".
- Add it as a separate commercial cert deployed alongside the unified. Same $$ ongoing. More maintenance burden on our end (e.g. accounting for it in OCSP Stapling and nginx server configs, etc). We've had multiple certificates deployed like this in the past (for wmfusercontent.org before it was integrated into the unified wildcards cert), but there have been several refactors during the era of one-cert-only, and so I'm not sure there isn't some debt to clean up before we successfully switch back to multiple, independent certs.
- Add it separately as above, but using LetsEncrypt. This avoids the $$ cost, but adds additional complexities to deal with initially, as our current puppetized deployment of LE certs isn't robust enough for our primary traffic terminators, only for smaller single-host/one-off sites. It lacks dual-cert support (as in ECDSA+RSA), it lacks OCSP Stapling integration, and most-importantly it doesn't know how to do renewal updates for a service with many global traffic termination points (i.e. we need to add support for centralizing the renewal process with updates out to all the global edge terminators, as well as support on all the terminators to forward challenge requests to the central renewer, etc).
Cc: BBlack, Lucas_Werkmeister_WMDE, Liuxinyu970226, Stashbot, gerritbot, Dzahn, Lydia_Pintscher, mark, greg, PokestarFan, faidon, Ladsgroup, Ivanhercaz, Addshore, Jonas, JeroenDeDauw, thiemowmde, hoo, JanZerebecki, Aklapper, Lahi, Gq86, Baloch007, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, Lewizho99, Zppix, Maathavan, Wikidata-bugs, aude, Mbch331, Jay8g, fgiunchedi
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
