I think we have a pretty graceful path at this point.
There's absolutely nothing preventing you from provisioning certs the way you know how, assuming you already know how and you happen to have an intermediate cert handy.
No (so long as you're making it configurable... and I think we're on the same page on that), there's nothing preventing you from doing that. But, by providing a "security on" button, you're encouraging users to not even think about security by creating an easy button (like your proposed "bin/accumulo init-ssl") that presumably implements some sort of security without thinking about what kind of security, what protections it offers, and what risks it mitigates. This is a bad precedent, and it feels like your coding to developers (like us, for ease in testing) rather than users... either that, or users who want security but really don't know what they're doing and who just want the comfort of "security" (not a good target audience to cater to, as a rule).
Besides, you're not doing end users any favors by providing an "easy button" for security. Anybody whose first experience with certificate management and provisioning is with this "easy button", will have to learn it all over again when they use SSL in any other Java application, and users who do have the experience will want to configure the details themselves, to ensure they are set up correctly (or they'll learn an unnecessary shortcut).
The short of it is that Accumulo should not be in the business of provisioning or managing certificates. We should make it easy to configure and use whatever certificates user provide, and any external convenience provisioning software should be left as an external tool, because that's outside the scope of Accumulo (just as its outside the scope of Tomcat, Apache Web Server, Jetty, JBoss, Thrift, and any other SSL-capable application).
The best thing for provisioning is to simply document how one might provision certificates... perhaps as a sequence of keytool or openssl commands. That way, it's clear to users that Accumulo's security isn't anything special or custom or novel. It's simply leveraging the same kinds of security that is available to them in other applications... the same that they may already understand, or that is well documented, or that they can get help with on StackOverflow or the countless message boards.
I can certainly get behind an external tool to help provision certificates for an entire cluster... I'd probably use something like that, but I think that's way outside the scope of Accumulo.
I know it seems like it, but I'm really not trying to argue for the rougher path for end users. I want things to go easy for them, too. But, I don't want them to have to re-learn custom things, and I don't want compromise security by automating security considerations that are necessary when provisioning certificates. I also don't want our public API and configuration to reflect our internal needs for development and testing, instead of the end-user's needs. I also want to protect against bloat, and the tendency to try to make software do all the things.
And as Michael Allen says above, there are definitely security and operational reasons for wanting a separate trust tree for your accumulo deployment.
I don't disagree. This is not an argument against that use case... I concede the utility and convenience of that. I do not concede that we should provide tools for provisioning that type of certificate chain and encourage users to turn on security "auto-magically" with an "easy button".
no way for you to tell it to use an external config source
That's not quite true. MiniAccumuloConfig accepts a map of keys to values, for configuration elements, which mimics the accumulo-site.xml file. It's relatively trivial to construct this map from any arbitrary external source. Provisioning certs is not part of regular Accumulo initialization, and it shouldn't be part of MAC's initialization.