Infrastructure

Hi,
https://in.libreoffice.org/ doesn't exist. https://libreoffice.in/ exist. The redirection doesn't work.

Redirection from what to what?

Guilhem Moulin wrote:

I thought libreoffice.$tld domains were just a convenience and there are 301 (permanent) redirections in place from http://libreoffice.$tld to https://$tld.libreoffice.org or https://libreoffice.org.

$ curl -w '%{http_code} -> %{redirect_url}\n' -so/dev/null http://libreoffice.in
301 -> https://www.libreoffice.org/

The main question is, is it a regression? Does https://libreoffice.in appear anywhere? There are quite a few other libreoffice.$tld for which there is no valid X.509 cert (and never was AFAIK), because these domains are just a convenience: when the user types libreoffice.$tld in the browser URL bar they're permanently redirected to the right site. Fair enough, requesting a new cert is cheap, but why should we also redirect https://libreoffice.$tld (or other scheme and/or subdomains)?

Hi Guilhem,
I don't know if it's a regression or not or if exist link to .in site anywhere. It's just bad user experience. Steps:

- write https://libreoffice.in/
 - you get error, nothing is redirected

curl -w '%{http_code} -> %{redirect_url}\n' -so/dev/null https://libreoffice.in
000 ->

probably redirect exist only for http:// but not for https://

Let's Encrypt now supports wildcard certificates - that might be the way
to go?

Florian Effenberger wrote:

Let's Encrypt now supports wildcard certificates - that might be the way
to go?

Wouldn't help here, as “libreoffice.*” isn't a valid request (only the leftmost label can be a ‘*’). Generally I don't think wildcard certs are helpful for us because most services have a fixed and short list of virtual hostnames (with the exception of vm168, where wildcard certs can be useful for *.libreoffice.org, but even there new NL sites don't pop up every day).

Wouldn't help here, as “libreoffice.*” isn't a valid reques

Stupid me, you're right of course... ;-)

Guilhem Moulin wrote:

and I guess in practice people don't enter scheme:// in their browser bar, just the hostname and path.

To clarify, what I meant here is that looking at the logs, people don't enter https://libreoffice.$tld in their browser bar (and I guess not http://libreoffice.$tld either, though there is no way to check as browsers automatically prepends http:// when someone enters a bare hostname). People do enter https://$nl.libreoffice.org and https://libreoffice.org though, and there are also links with these scheme & hostname. So while not having a working redirection from https://libreoffice.org to https://www.libreoffice.org would be a regression, IMHO from https://libreoffice.$tld it's not.

Florian Effenberger wrote:

What Guilhem says sounds sensible indeed to me. Raal, is there a use case to adjust the certificates in the way you proposed? Otherwise I'd not spend time on this... ;-)

Hi Florian, I have not problem with closing this task. When i type the URL and I get the error, I can repair URL by myself.