Page MenuHomePhabricator

*.mobile.wikipedia.org domains are using invalid SSL certificate
Closed, DeclinedPublic

Description

See https://en.mobile.wikipedia.org.

*.mobile.wikipedia.org should be added to domain list or these domain name should be disused.


Version: unspecified
Severity: normal

Details

Reference
bz36126

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:25 AM
bzimport added projects: HTTPS, acl*sre-team.
bzimport set Reference to bz36126.
bzimport added a subscriber: Unknown Object (MLST).
liangent created this task.Apr 20 2012, 2:58 PM

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."

drdee added a comment.Nov 23 2013, 2:35 PM

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?

BBlack added a subscriber: BBlack.Dec 8 2014, 10:24 PM

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)

(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/.

Krinkle closed this task as Declined.Dec 10 2014, 3:23 PM
Krinkle claimed this task.