It sounds like you have an oversimplified idea of "security". Security is not a scalar property that increases with the number of bits in a hash or key. Security depends on your threats, and it's possible to be reasonably secure without the addition of any cryptography at all (although this will be the exception rather than the rule). Let's discuss security threats for a moment.
One threat is that of the eavesdropper. This is the classic threat from online shopping: "OMG, some hacker will see my CC number when I submit it to the shop." This threat can be defeated with encryption -- sort of. You don't need any kind of "certificate" to effect this level of security: you just need a key-sharing technique which defeats a passive eavesdropper. SSL/TLS has this, and it's independent of the number of bits in any hash, since that's a different part of the security puzzle.
Now the bad news: your CC number will still be compromised, despite your super-strong encryption. If you're using a malware-prone OS, then any malware on your system makes an end-run around the encryption. If you're using a public terminal, you need to be sure that it doesn't have keyloggers installed on it, either hardware or software. And even if your client-end computer isn't compromised, your CC number will be stored in a PCI-compliant database, where "PCI-compliant" means "this kind of thing gets compromised several times a week, leaking X thousand CC numbers in one go" for large values of X.
Encryption of the channel, in this case, provides security against the least convenient and least likely attack. You should probably encrypt the channel anyhow, but you simply can not achieve security, because most of the real threats lie outside your control.
Another threat is the impostor. This is where someone gets lured into going to BadGuy website which is dressed up as GoodGuy website. This is where public key certificates are supposed to help, and that's where you need to worry about how many bits there are in the hash. But if you're worried about the number of bits in the hash, or the kind of hash algorithm, then you're probably fussing over the smallest of problems. Certificates have a very limited lifespan, and so long as your current one isn't at the bottom of the pile, strength-wise, it's probably satisfactory for now.
The real problems that you face in this case are usually beyond your control. You can't create a self-signed certificate in general, because every browser on earth will throw up a warning (that 99% of users won't understand anyway) saying that the certificate can not be verified. You don't want that: you want the browser to do the "I'm secure now" thing, whatever that happens to be, visually. So you'll need to pay up for a certificate. Unfortunately, your clients must then be smart enough to pick the difference between your website with its "I'm secure now" indicator, and an exact copy of that website which lacks this indicator at a different URL, or one that has an "I'm secure now" indicator which doesn't match your identity. How smart are your clients?
If you're a really important target (e.g. Gmail), you have much bigger worries. You ask, "Can I trust that my SSL provider hasn't been hacked (or at least snooped)?", but the problem is much worse than this: you need to trust that every issuer of certificates on Earth hasn't been compromised, which you can't, because some of them have. When any certificate issuer is compromised, it's possible that a fake certificate has been generated for your identity, and someone else can set up a server which validates itself as "secure" for your domain name. There are browser add-ons in some cases that will raise a red flag when a "valid but previously unseen" certificate is shown, but then you're asking for even greater security expertise on the part of your end users to diagnose the situation.
So, in summary, step away from the key-generation software, and go back to square one. Think about your threat model, and whether any of your crypto-magic will protect you better than the Maginot line protected France against invasion by the Germans. And if you're into Bruce Schneier, go pick up a copy of "Secrets and Lies". It will give you a much better education on the difference between cryptography and security than I've done here.