Page MenuHomeMiraheze

Create automated system for managing SSL requests
Open, LowPublic


Following the positive experience with ImportDump and given very limited experience with webservices, we've decided that for the time being it would be better to follow that model for SSL. These are the steps that are being/were taken

  • Step 1: Automatically copy and commit private keys
  • Step 2: Automatically push certificates to GitHub
  • Step 3: Create RequestSSL and automatically add ManageWiki $wgServer entry
  • Step 4: Create an API endpoint on puppet141 and configure it to listen to requests from the RequestSSL extension and execute '/root/ssl-certificate' when requests are marked as completed
  • Step 5: Automatically add DNS zone for wikis that have pointed their NS to Miraheze (check whether CNAME, if not add zone)
  • Step 6: Decommission the SSL admin group

<Original plan; kept as an archive; might not follow exactly>
Stage 1:

  • Update check_reverse_dns to check records present too.
  • Move SSL generation from mwtask141 to puppet141
  • Automate copying private keys
  • Automate pushing certificates from puppet141 to GitHub

Stage 2:

  • Update certbot cli to check rDNS is correct and either CNAME or NS record is present. Add argument to skip this.

Stage 3:

  • Create a web form to automate creating SSL tasks + checking validity - refuse to create if invalid.

Stage 4:

  • create a new wrapper for generating new ssl certs, include updating ManageWiki (puppet-user will be pointless at this point).

Stage 5:

  • Move all SSL requests to the new ssl self serve site and allow one click to do everything.

Event Timeline

RhinosF1 triaged this task as Low priority.Jul 3 2021, 08:49
RhinosF1 updated the task description. (Show Details)

I've created a script, will add it to puppet, deploy it everywhere later.

Icinga will now go off if the domain points in a manner we don't expect.

I'll send a PR tommorow for updating ssl-certificate to run the check too.

After that, I will start work on the beta site for creating new requests. There is a varnish config PR to force all requests via jobrunner3 for it.

Unknown Object (User) moved this task from Backlog to Goals on the MediaWiki (SRE) board.Jul 4 2021, 16:54
Unknown Object (User) moved this task from Backlog to MediaWiki on the Goal-2021-Jul-Dec board.Jul 31 2021, 00:28
Reception123 removed a subscriber: Unknown Object (User).Aug 24 2021, 19:05

Can we have an update on this goal please? Last update was on July 3rd.

Can we also have a plan for realistic completion or significant progress before this goal period is update December 31st please?

So far none. This is looking unlikely it'll be done this period.

Unknown Object (User) added a comment.Jan 1 2022, 17:06

I purpose that this task does not become a goal for the new goal period, as there was no progress on it last time, and does not seem that there is anyone who intends to work on it. Goals should ideally have someone fully committed to getting them done.

Unknown Object (User) moved this task from Goals to Long Term on the MediaWiki (SRE) board.Jan 1 2022, 17:06
Unknown Object (User) removed a subscriber: Bukkit.Jan 30 2022, 22:36
Reception123 added a subscriber: Unknown Object (User).Jan 31 2022, 18:07
In T7582#172916, @Universal_Omega wrote:

I purpose that this task does not become a goal for the new goal period, as there was no progress on it last time, and does not seem that there is anyone who intends to work on it. Goals should ideally have someone fully committed to getting them done.

While this is super late, I agree that tasks should not be goals unless there is a clear and expressed desire for someone (or multiple people) to work on it. However I think it's a shame that no one wants to work on this particular task which while not urgent (since we've been doing this for 6 years now) is important to allowing for quicker resolution of SSL-related tasks.

I propose that since maybe the extent of this task is what puts people off from doing it, we start with a simpler task which would just be to automate adding private keys to puppet111 (i.e. when using the script the key is added to puppet111 automatically) therefore allowing MWEs to generate SSLs, then further automation/user-integration can be done separately.

Unknown Object (User) unsubscribed.Feb 12 2022, 07:25

Since there is no progress, I propose we simply move ssl-certificate to puppet111 (since no mw-admins have done any SSL tasks in recent years anyway) and have the private keys automatically added.

SSL certificates are now generated on puppet111 directly and private keys are automatically copied.

Unknown Object (User) subscribed.May 28 2022, 08:38
Unknown Object (User) updated the task description. (Show Details)Nov 10 2022, 16:45


Due to the fact that the initial options seems more complicated, our currently shorter term plan would be to implement it in a similar way to ImportDump and in the end only have SRE copy/paste the command for everything.

For automatic approve = creation, that will be a longer term goal that will likely be separated out in separate tasks. For now I think it's enough of an improvement if we can get to the point where SRE members just copy a command and that's it.

While this hasn't been fully tested yet here is my not-so-perfect version of step 3 which I unfortunately didn't integrate into the ssl-certificate script due to lack of knowledge on how to do so properly and not wanting to make things too messy. Here is the current script that can be used in the meantime (not 100% sure if DNS works yet): and hopefully be integrated into the main one soon so that step 4 can follow.

Though unofficially, adding DNS zones manually is no longer necessary!

Reception123 renamed this task from Create better system for managing SSL requests to Create automated system for managing SSL requests.Jan 20 2023, 13:20

Just so we don't forget, the current idea would be to try using and have an API backend for ManageWiki with the web app being MediaWiki. has been created based on ImportDump. Things that are required to make it operational

  • Add a method so that $oldstatus and $newstatus is known in order for the updateManageWiki function to be executed only when the status is changed from something else to completed
  • Implement logging (can be copied from ManageWiki) so that when RemoteWiki is executed it logs it as if someone had changed managewiki on wiki
  • Fix issues with timestamp (might just be a problem with the SQL implemented on beta)

Due to limited knowledge on my part, it would be preferable if someone else had a go at this.

  • Check if all i18n messages make sense (can be done by anyone) [DONE!]
Unknown Object (User) unsubscribed.Mar 18 2023, 03:25