https://rt.wikimedia.org/Ticket/Display.html?id=3275

Affected domains:

*.mobile.wikipedia.org
*.m.wiktionary.org (from bug 38434)

• Bug 38434 has been marked as a duplicate of this bug. ***

Removing dependency to bug 27946 which is secure.wikimedia.org.

(In reply to comment #2)

*.mobile.wikipedia.org

That one is NOT used according to the RT ticket.

Comment by CT Woo on RT ticket which is closed as rejected:
"We have *.m.wikimepia.org.
We do not use mobile.wikipedia.org."

It seems to me that this bug can be closed as wontfix as the mobile subdomains have been decommissioned.

(In reply to comment #7)

It seems to me that this bug can be closed as wontfix as the mobile
subdomains
have been decommissioned.

No they still exist as redirects, and are still serving invalid certificates for HTTPS.

(In reply to comment #8)

No they still exist as redirects, and are still serving invalid certificates
for HTTPS.

What do you think about removing (killing) the redirects?

Afaik operations' policy is to not support SSL certificates for redirect domains. They work fine over HTTP, but HTTPS will yield a warning.

This applies to:

• http://wikimediacommons.org https://wikimediacommons.org
• http://wikipedia.com https://wikipedia.com
• http://wikimedia.com https://wikimedia.com
• http://wikijunior.com https://wikijunior.com
• http://pa.us.wikimedia.org https://pa.us.wikimedia.org
• http://arbcom.en.wikipedia.org https://arbcom.nl.wikipedia.org
• http://arbcom.nl.wikipedia.org https://arbcom.nl.wikipedia.org
• http://noboard.chapters.wikimedia.org https://noboard.chapters.wikimedia.org/

And many more (operations-puppet:/apache/sites/redirects.dat).

And thus http://en.mobile.wikipedia.org / https://en.mobile.wikipedia.org as well.

So, just to be technically-explicit, these are the wildcard domains we have valid certs for:

*.m.wikipedia.org
*.wikipedia.org
*.m.wikimedia.org
*.wikimedia.org
*.m.wiktionary.org
*.wiktionary.org
*.m.wikiquote.org
*.wikiquote.org
*.m.wikibooks.org
*.wikibooks.org
*.m.wikisource.org
*.wikisource.org
*.m.wikinews.org
*.wikinews.org
*.m.wikiversity.org
*.wikiversity.org
*.m.wikidata.org
*.wikidata.org
*.m.wikivoyage.org
*.wikivoyage.org
*.m.wikimediafoundation.org
*.wikimediafoundation.org
*.m.mediawiki.org
*.mediawiki.org
*.zero.wikipedia.org

Note that for the purposes of certificate wildcards, the asterisk only covers a single name rather than arbitrarily-deep subdomains, which is why we have separate *.m certs for every domain except zero. Certificates are costly, which is why we don't buy infinite/random certificates for every domain/subdomain we can dream up. So yes, in a policy sense, we're not going to have valid SSL certs for those other domains, including the long list of things like typo-redirect domains.

What I'm a little concerned about in all of this, though, is that we need to be sure that we're consistent about which domains are official and which are redirects without SSL support, and we need to be sure that we're not generating or emitting links to the public that reference the the redirect-only domains. That may sort-of work now, but as we keep moving forward with more-aggressive SSL support (which will probably someday culminate in all traffic being SSL-protected and HSTS), that will become a very bad experience for users who might have to accept mismatched certs to follow a link that ultimately came from us. This may require rethinking some of these microsite URLs in some cases, to make them path-based rather than hostname-based. At the very least, we need to be sure that if we are generating links to these hostnames, that the links aren't HTTPS (although even that may become an issue down the road).

(I should have said above: an alternative to path-based is just to make sure that they're in one of the supported primary domains from our SSL list and that the hostname is only one level deep. For example, arbcom.nl.wikipedia.org could become arbcom-nl.wikipedia.org)

In T38126#831983, @BBlack wrote:

(I should have said above: an alternative to path-based is just to make sure that they're in one of the supported primary domains from our SSL list and that the hostname is only one level deep. For example, arbcom.nl.wikipedia.org could become arbcom-nl.wikipedia.org)

@BBlack While some may have been missed, I think this was done this last year. Focus was to rid all deep-subdomains except for *.m.*. http://arbcom.nl.wikipedia.org, for example, has already been renamed to https://arbcom-nl.wikipedia.org, and http://pa.us.wikimedia.org to https://pa-us.wikimedia.org/.