There are two serious technical ways to fix this. There may be policy reasons why you wouldn't want to do one or both of these

1. Transfer back to WMCZ:
   • WMCZ moves domain back to their own nameservers
   • WMCZ changes the domain's A/AAAA to point to their web server.
   • WMCZ adds a cert for the domain, using either a paid provider or LE
2. WMF-hosted secure redirect service - T133548
   • WMF sets up a new IP to handle this domain (and many, many others - see the ticket), with apache/nginx knowing the correct redirect rules and having all the correct certs
   • WMF changes the domain's A/AAAA to point to this new server
   • Policy-wise, if WMF ops don't mind being a pain and slowing this down further, they could potentially require that WMF own the domain.

<Urbanecm> Krenair, as I understood the mail we (I'm a member) prefer #2 (but #1 is possible if needed).

Indeed, #2/T133548 is the best option in my opinion. #1 is more likely to be possible quickly as it involves no WMF-side technical changes as far as I know

Now, policy-wise, and for the sake of spelling out all combinations, I doubt we'd do either of these:

• A situation where WMCZ owns the domain and points it to WMF-hosted NSes, but WMF sets the A/AAAA records for the domain to WMCZ web servers which have the cert
• A situation where WMF owns the domain and points it to a WMCZ-chosen/hosted NS, sending A/AAAA records to wherever has the cert

Probably this should be merged into T133548, unless it's altered to be about implementing some other solution outside of that scope.

Edit Addition: My info below was for wikimedia.cz, not wikipedia.cz. So the initial task description listed both, and I followed the link for the second. The task description could stand to be cleaned up and made a bit more clear.

Original post follows:

Implementation of SSL on our cluster is handled by the traffic team. So if there is a problem, they would be ideal to ask.

That being stated, I don't see any cert issues when I follow the link above in the task description. http://wikimedia.cz/ is in the description, and it redirects to https://www.wikimedia.cz/web/Hlavn%C3%AD_strana which shows a legit LetsEncrypt Certificate.

Addtionally, wikimedia.cz is not owned, controlled, or hosted by WMF when I check. There are multiple checks (dig, curl, reading the cert), but the simple host check is quite telling:

6 $> host wikimedia.cz
wikimedia.cz has address 81.95.96.148
wikimedia.cz has IPv6 address 2a02:4a8:ac24:108::96:148
wikimedia.cz mail is handled by 10 mx2.pravy.net.

8 $> host 81.95.96.148
148.96.95.81.in-addr.arpa domain name pointer uvirt14.active24.cz.

This doesn't appear to be hosted by us at this time.

22 $> whois wikimedia.cz
% (c) 2006-2017 CZ.NIC, z.s.p.o.
%
% Intended use of supplied data and information
%
% Data contained in the domain name register, as well as information
% supplied through public information services of CZ.NIC association,
% are appointed only for purposes connected with Internet network
% administration and operation, or for the purpose of legal or other
% similar proceedings, in process as regards a matter connected
% particularly with holding and using a concrete domain name.
%
% Full text available at:
% http://www.nic.cz/page/306/intended-use-of-supplied-data-and-information/
%
% See also a search service at http://www.nic.cz/whois/
%
%
% Whoisd Server Version: 3.10.2
% Timestamp: Mon Mar 06 20:23:29 2017

domain: wikimedia.cz
registrant: WIKIPEDIA
admin-c: WIKIMEDIA_ADMIN-C
nsset: NSS:GLOBE-SGLO000001:1
keyset: A24-KEYSET
registrar: REG-ACTIVE24
registered: 26.10.2005 08:25:00
changed: 06.03.2010 09:31:12
expire: 26.10.2025

contact: WIKIPEDIA
org: Wikimedia Česká republika
name: Wikimedia Česká republika
address: Konopišťská 790/3
address: Praha 10
address: 100 00
address: CZ
e-mail: wm-cz@wikimedia.org
registrar: REG-ACTIVE24
created: 08.08.2008 13:29:18
changed: 23.06.2014 13:27:26

contact: WIKIMEDIA_ADMIN-C
org: Wikimedia Česká republika
name: Petr Novák
address: Konopišťská 790/3
address: Praha 10
address: 100 00
address: CZ
phone: +420.603341918
e-mail: petr.novak@wikimedia.cz
registrar: REG-ACTIVE24
created: 27.08.2008 16:52:30
changed: 23.06.2014 13:30:56

nsset: NSS:GLOBE-SGLO000001:1
nserver: beta.ns.active24.cz (81.0.238.27, 2001:1528:151::12)
nserver: gama.ns.active24.sk
nserver: alfa.ns.active24.cz (81.95.96.2, 2a02:4a8:ac24:100::96:2)
tech-c: ACTIVE24
registrar: REG-ACTIVE24
created: 01.10.2007 02:00:00
changed: 19.07.2011 15:27:33

contact: ACTIVE24
org: ACTIVE 24, s.r.o.
name: ACTIVE 24, s.r.o.
address: Sokolovská 394/17
address: Praha 8
address: 186 00
address: CZ
phone: +420.234262000
fax-no: +420.234262009
registrar: REG-ACTIVE24
created: 29.04.2008 12:35:02
changed: 28.11.2012 15:33:24

keyset: A24-KEYSET
dnskey: 257 3 5 AwEAAaZg1mHVw0d/qllyQBGqnRGJGRbL/51OuJ/QmAwt5VACOeIbRjAOfZ5RDvnjc9IekSVgXiSjDuO+gSm63bvFHTiGLKUnJD03TmB12oOctDB0pMs0eQT+2HoKdkgmqipzqYssVZOdcb/t/NP3fq3xLdYlJgTBmx1769NsyF602her5PSojVcxRjUlqqA4zNmN9K2r6+xrbhSHf0+dGC2u8O4bW1qGEoeo2M+xr7oUiUL8yH5n0DbhxcribLcuGro1LTn4s3P9xTYGSRb0Pd9rK0s7csb7FxyGdwsOqmZr47t3UQn2pp8q4guca2ef/hjevkq+wVZv/eUHhu6FzMCYTqc=
tech-c: ACTIVE24
registrar: REG-ACTIVE24
created: 26.11.2008 14:12:02
changed: 07.10.2011 21:51:15

@RobH yea, but wikipedia.cz is our IP and DNS servers

In T152622#3076846, @Ottomata wrote:

Re-opening, I think both @RobH and I read this as 'wikimedia.cz', not 'wikipedia.cz'. wikipedia.cz is owned by WMF.

That's not true, wikipedia.cz is owned by WMCZ too (https://www.nic.cz/whois/domain/wikipedia.cz/). But it points to WMF's nameservers.

For clarifying:

• wikimedia.cz was linked just for case when somebody want's to look what I mean by WMCZ as it links to our website
• This ticket is about wikipedia.cz which is a) owned by the WMCZ (https://www.nic.cz/whois/domain/wikipedia.cz/) b) it's namespace servers are run by the WMF.

To be clear then: this ticket is about our (WMF's) hosting of wikipedia.cz not having a valid SSL cert, and maybe touches on broader issues of ownership and delegation rules.

I'm going to pass on making judgements or having ideas now about the latter, as we're really not to a point in our priorities where we can even tackle that problem for the general case, but we might re-visit at a later date (auditing and aligning registrar ownership vs NS delegation in both directions). For the simpler part about the bad SSL cert, this belongs merged into T133548 (which will eventually fix all such cases for non-canonical domains we host).