Hi there!
It's not really about whether it's possible - it is possible, but rather about whether it's a good idea to do it, which is really not, even though some people really want it. We do realize that it is possible to create a certificate that will appear secure to the client as a part of the installation process. A wildcard certificate could be shipped along with the application, a self-certificate can be issued, etc.
The problem is that most people want encryption without realizing that
encrypting a conversation with an unverified party has no value. In this respect both self-signed and redistributed certificates are flawed and provide an appearance of security, while providing no actual security. Self-signed certificates have no way of proving true identity of the server - they are no more reliable in proving server's identity than driver's license you could create for yourself would tell who you truly are. And as we mentioned, encryption is useless if there is no guarantee that the party on the other end of the conversation is truly who they claim they are.
Redistributable certificates also suffer from a flaw of vouching for an identity of a machine merely by being placed there, which is also fundamentally non-secure. Private key, which is a part of the certificate, is something like your fingerprint - it's supposed to be very hard to move to another actor (that's what non-exportable keys are for) and to be unique. Wildcard certs represent identity of a web farm instead of a single machine, and therefore allowed to be moved, which reduces their security by making them like a fingerprint that can be adopted by other people. Wildcard certs and other redistributable certs break the cardinal rule of the PKI: they make private key easily obtainable by many actors.
These are very similar reasons as to why CAs do not sign certificates for "localhost", 192.168.x.x, etc. - because it's impossible to guarantee identity of the server, in which case encryption is moot. Same applies to every use case where issuer of a certificate has no way of proving server's identity, and redistributable applications never can w/o user interaction. If we were to get hold of your application distribution, we could install it on our server and all of the sudden our machine looks very much like your farm node to the outside world.
We do understand that there are many cases where administrators do not fully understand PKI security, and where mere presence of SSL and corresponding encryption is considered sufficient, but infrastructure products, like web servers, have much higher security requirements, and if we were to enable automatic SSL certificates, we'd be in trouble for creating a false sense of security where there is virtually none.
The only somewhat remotely realistic flow of enabling SSL for a redistributable app we tried was us ensuring that a wildcard/redistributable cert shipped with the application has password-protected private key, and password is compliant with some strict password strength rules. That would require people who install it to call someone who will tell them password. We ruled out this idea after one of our trial customers promptly started displaying the password before installation.
This all means that although we do realize that most users are soothed when they see SSL even if it's not doing much for actual security, and although would love nothing more than helping ISVs like you, we really cannot risk our brand supporting this case.
Best regards,
UltiDev Team.
Please donate at
http://www.ultidev.com/products/Donate.aspx to help us improve our products.
