Currently, the LTI private key is checked and generated by openssl (if missing) in the following places:

1. Install
2. Upgrade (an old 3.6.x step iirc)
3. When trying to save a preconfigured tool on the manage tools site admin page

If the site's openssl.cnf isn't properly configured (can happen more commonly on Windows, as I recall - see MDL-65536), then the install will pass, but will warn the admin that the private key couldn't be set. Same for the upgrade step. 

So, number 3 was designed as a final catch at the time of tool creation, to handle cases where 1 or 2 had failed. If the openssl.cnf is still invalid at this time, pre-configured tools can't be saved. The user will see a validation message - and this is good, because it means we won't be dealing with reports of validation failures, etc for sites that are improperly configured.

What we didn't do was add this same kind of check to dynamic registration (because that feature came later). So, admins trying to add tools this way on a site with an improperly configured openssl.cnf won't be told they're missing the crucial private key. As in https://moodle.org/mod/forum/discuss.php?d=433995. 

We should add this same check somewhere in the dynamic registration workflow, just to make sure the admin is told clearly that they're missing the key, and to stop the process failing like it did in the above forum post.