keytool experience

I tried StandardSSLContextService in lieu of StandardRestrictedSSLContextService. Validation still failed.
I show JKS here as store type, but that was the first time around. Later I standardized on using PKCS12.
You see that just above here in oppostion to the older illustration posted below.

Some very useful links and notes in response to my question...

I have hesitated between providing some huge tl;dr exposé and something shorter. I'll do shorter here.

For now, I'm using "changeit" below as password rolling a self-signed certificate for key, key store and trust store.
I have a service running in Tomcat that I hit via HTTPs because the content always involves personal health information.
I use a key store containing my certificate. No trust store is needed or involved in Tomcat.
I need to hit my Tomcat service using InvokeHTTP in my flow.
This means configuring an instance of Standard[Restricted]SSLContextService.
The SSL context service insists on a defined key store with key password and key store password.
The SSL context service insists on a defined trust store. The best I have been able to do is to roll the key store certificate into a trust store.
When either key- or trust store file is missing, the SSL context service complains that a resource is missing (for key store or trust store).
Once both files/resources exist, all three passwords appear crucial.
Despite password used to create key and certificates, it is always wrong according to SSL context service validator which consistently issues:

Keystore Properties is invalid because invalid keystore password or type specified for file __________.
Truststore Properties is invalid because invalid truststore password or type specified for file __________.

It would be nice to see a step-by-step illustration of creating the key, key store and trust store artifacts required by SSL context service and perhaps the full configuration of the SSL context service.

Other notes:

I seem to get pretty far toward a solution using Java's keytool.
I don't get very far using openssl.
I get even less traction trying to use NiFi's TLS toolkit to solve this.
I guess I could simply write my own SSL context service that doesn't require a trust store?

Huge thanks for any help or comments.

There is a default Java truststore located at $JAVA_HOME/lib/security/cacerts that you should use.
(Cannon Palms)
You mention that you want to use InvokeHTTP in NiFi to access your Tomcat server.

Is Tomcat using a CA-signed certificate? If so, you should leave the InvokeHTTP property SSLContextService blank. This will cause InvokeHTTP to use the default JVM truststore, which trusts CA-signed certificates. If you can access your Tomcat from a web browser without certificate warnings, the certificate is likely CA-signed.

If Tomcat is using a self-signed certificate, you'll need to assemble a truststore using the self-signed certificate. Download the certificate, and use the instructions above to assemble the truststore.
One more bit of information. InvokeHTTP uses an open source library that expects the server hostname to match a distinguished name defined in the certificate.

Hope this helps...
(Paul Grey)
Create an SSL context service using a keystore and truststore
It's not a NiFi issue; it's a PKI infrastructure thing.

For PKI, you always need a truststore and a keystore. You can have them reside in the same place (not recommended) and/or you could just trust everything (again, not recommended), and/or your app (eg: Tomcat) could be default configured so that is does the risky "not recommended" things mentioned above. But that doesn't mean that "no trust store is needed or involved".

There are some good tutorials out there for using keytool and openssl for setting up PKI for client/server 2-way authentication.
(Patrick Timmins)

Failed attempt to use PKCS12

How credentials were created—summary

Credential inspection

StandardRestrictedSSLContextService configuration

Errors in StandardRestrictedSSLContextService

Other things tried...

Some very useful links and notes in response to my question...