(In reply to comment #7)
It seems to me that this bug can be closed as wontfix as the mobile
have been decommissioned.
No they still exist as redirects, and are still serving invalid certificates for HTTPS.
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).
So, just to be technically-explicit, these are the wildcard domains we have valid certs for:
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)
@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/.