Module gets installed, Magisk appears to attempt to run at boot, but no evidence that the commands in post-fs-data.sh were actually run

[bbygopher]

Magisk log (from the Magisk application Log view):

...
movecerts: exec [post-fs-data.sh]
* Loading modules
movecerts: loading mount files
** late_start service mode running
...

Files in /data/misc/user/0/cacerts-added/ remain unmoved, copies do not appear in /system/etc/security/cacerts. No messages indicating which files were targeted for the move.

Two Ninja Edits to make...

1: This bug seems to have been fixed by a fork of this project. Huge thanks to Andy Acer for fixing this 6 months ago. Check out the config flags in his install.sh. I think those are the source of the issue I experienced, and it should be a quick fix.

https://github.com/andyacer/movecert/blob/master/install.sh

Second, on my device (Retail Moto G Power), the behavior has changed such that the standard procedure results in an unusable certificate being placed in the System CA store. The User store wants an X509 certificate as input (ok, that's all good), but the file it spits out and sticks in /data/misc/user/0/cacerts-added/ is a binary blob .DER file (such as would be exported directly from Burp). I noticed other odd malformations of the file, like setting the creation date to 1969, etc.

Therefore, when the .DER file is copied by this script into the /system/etc/security/cacerts cert store, you have a completely valid certificate, named the correct name, in the wrong format, so you see no change in the HTTPS/HSTS errors thrown by the client when you attempt to intercept traffic.

TL;DR: For me (and possibly for other people), the best way to work around this is DO NOT install the certificate via the UI. Just copy the properly named x509-formatted certificate into /data/misc/user/0/cacerts-added/ and reboot.

Probably worth adding to the script to detect and correct this case for usability purposes.