You get a few options:
If you don't expect the output to be read from a browser, you can make your server encrypt the data, then you can save it from your browser and decipher that file using another application.
Some shared hosting services will still serve your content at
https://www.yourserver.example/ using their own certificate (only valid for
www.yourhost.example, but not
If this works in your case, and if you can trust that the certificate presented to you by the server is realistically that of the server on which your service is hosted (e.g. a cert that would be valid for
www.yourhost.example), you can add a permanent security exception in Firefox (for example). This is usually not acceptable if your site is for more public use, but if you can judge that you can trust that server certificate, you will still have all the benefits of SSL/TLS when connecting to that server. This is clearly not ideal and require some of your own judgement when setting such exception. In your case, if the certificate you get for
https://www.yourserver.example/is valid for
secure1.hostgator.com (or something like that), it would seem reasonable to assume you're connecting to your shared server.
Use your host's shared SSL facility (as they seem to provide one). The URL won't look like it's yours, but it should at least be secure without any specific exception, and it's fine for personal access.
EDIT: To clarify the point about custom code.
Most modern browsers have a key/cert container (e.g. Software Security device on Firefox at least) where private keys can be used for SSL/TLS client authentication.
signText) that should protect the key for signing the correct way, but there's nothing to decrypt. There are also on-going efforts to make more cryptographic operations available, but this isn't ready at this stage (it's not clear whether it will be implemented in IE either).