Probably the most important question (since I haven't really looked at UrlShortener) is: are there subdomains involved, or just https://w.wiki/... ?

Either way, we're going to need to fix the w.wiki zonefile (it's currently a symlink to wikipedia.org, which isn't right), and we'll need to add TLS support for it. We could take two possible routes with that:

1. We could add another SAN onto our unified list for w.wiki
2. We could simply get a new non-wildcard cert for w.wiki and deploy it separately alongside the unified on the text clusters

Or, I guess we could do (2) for now and deal with rolling it up into (1) the next time we naturally renew the unified.

In T108649#1526679, @BBlack wrote:

Probably the most important question (since I haven't really looked at UrlShortener) is: are there subdomains involved, or just https://w.wiki/... ?

No subdomains. Just https://w.wiki/{shortcode}. This will be an internal rewrite to meta.wikimedia.org/w/index.php?title=Special:UrlRedirector/{shortcode} (or any other wiki), which will either output a 301 or an error page.

Either way, we're going to need to fix the w.wiki zonefile (it's currently a symlink to wikipedia.org, which isn't right), and we'll need to add TLS support for it. We could take two possible routes with that:

1. We could add another SAN onto our unified list for w.wiki
2. We could simply get a new non-wildcard cert for w.wiki and deploy it separately alongside the unified on the text clusters

Or, I guess we could do (2) for now and deal with rolling it up into (1) the next time we naturally renew the unified.

SAN = https://en.wikipedia.org/wiki/SubjectAltName ? I don't understand the details and implications here, so I'll leave it up to you to decide which is best :)

In T108649#1526679, @BBlack wrote:

1. We could add another SAN onto our unified list for w.wiki
2. We could simply get a new non-wildcard cert for w.wiki and deploy it separately alongside the unified on the text clusters

Or, I guess we could do (2) for now and deal with rolling it up into (1) the next time we naturally renew the unified.

I think (2) would be fine, at least from the angle of performance, which I don't think is critical here.

In T108649#1529324, @Legoktm wrote:

SAN = https://en.wikipedia.org/wiki/SubjectAltName ? I don't understand the details and implications here, so I'll leave it up to you to decide which is best :)

Yeah. One downside of taking the "easy at the moment" way out with a separate cert is that https://w.wiki/ would only work for SNI-capable clients. That excludes IE[78]-on-XP (but not IE8 on Win7+), Android 2.x, and probably a long tail of older/feature phones and strange devices like older "Smart TV"s and such (some of the oldest/crappiest of that long tail already don't work with us in general, but the list grows quite a bit for a domain which requires SNI, which our primary domains do not).

We've been OK with requiring SNI support for misc-web services (e.g. phabricator, monitoring) before, but we've never required it on our "primary" domains on the text/upload/mobile endpoints before. This falls into the primary category I think, so maybe we're better off looking into adding the SAN and re-issuing the primary unified certs. I don't think we've done that process before, at least not via GlobalSign, and it may involve some custom support from our rep there. We have some other unrelated things to sort out with these certs in the near future anyways, now may be as good a time as any to get the ball rolling. I'll start looking into how feasible that is tomorrow.

In the interest of full disclosure of options, there's a middle-ground option where we get a simple separate cert for w.wiki, and also give it its own separate IP address from the others, and then it works for non-SNI clients as well. Our standard nginx->varnish terminator stuff isn't set up to handle multiple distinct server-IPs per cluster in this manner at this time, but it could be refactored a bit to handle it.

Also where should we do the redirect? I guess any requests to w.wiki/(.*) should redirect to meta.wikimedia.org/w/index.php?title=Special:UrlShortener/$1 on the appservers. Should we just do this on varnish?

Err, by redirect I mean 'route to' from varnish, not an actual redirect.

Definitely not varnish!

Addiing another domain adds to the overall cost of the certificate, and thus would need additional budget approval.

Also, T101048 involves discussion on how to handle all the non top level domains we own and how to support them.

Change 258406 had a related patch set uploaded (by BBlack):
add w.wiki to VCL TLS redirect/HSTS

https://gerrit.wikimedia.org/r/258406

Change 258407 had a related patch set uploaded (by BBlack):
w.wiki: unlink from wp.o, remove all hostnames within (unused)

https://gerrit.wikimedia.org/r/258407

Change 258407 merged by BBlack:
w.wiki: unlink from wp.o, remove all hostnames within (unused)

https://gerrit.wikimedia.org/r/258407

Change 258406 merged by BBlack:
add w.wiki to VCL TLS redirect/HSTS

https://gerrit.wikimedia.org/r/258406