Security certificates on a web site serve two purposes. They identify the site so that you know for certain that the place you are sending your information to is the place you intended and they encrypt the data being sent in order to prevent it being read by someone intercepting it on the way.
Not every site needs a certificate for both of these purposes. Where only encryption is needed you do not need a certificate that is specific to your site and you do not even necessarily need one issued by an authorised third party. If the encryption of the data to prevent interception is all you need then any certificate on the server will do the job. Of course if the certificate doesn't match with your site then the browser will produce an error indicating the mismatch. In that instance your visitors will probably decide that your site is unsafe and will not continue with their visit. Of course for any back end processing done by you, the fact that the certificate doesn't match is not going to be an issue and neither is the fact that the certificate was not issued by an authorised party. You will know that the certificate is the correct one for what you are doing and the certificate will provide the encryption you require.
Where you want to provide encryption for your visitors but do not need to specifically identify the site then provided that the certificate you have available was issued by an authorised party then you can get around the alert by using the web address that goes via the domain the certificate was issued for rather than directly to the specified domain. For example, Hostgator provide certificates for all of their shared hosting servers so instead of accessing http://example.com/securearea you would access http://secure123.hostgator.com/~example/securearea which would access the exact same pages but would use the supplied security certificate and as it is valid for the specified domain would not give an error message. Your visitors would be able to access your pages using encryption without receiving any warnings about the certificate not matching. They would just be unable to confirm that they are on your site and not some other site as the address no longer specifies your domain.
Where your visitors need to verify that they are on the correct domain as well as having their connection encrypted you have no choice but to obtain your own security certificate for the specific domain. This will be the case where the primary purpose of the connection is for them to provide you with information rather than the other way around. The certificate you use in this case will need to specify the correct domain. Depending on how important the information you are expecting them to provide is, you may need to look at one of the extended validation certificates that requires a lot more information from you before it is issued so as to ensure that your visitors have more reassurance that they are giving their information to who they expect. An extended validation certificate usually highlights itself using a green marker at the front of the web address confirming that the domain using the certificate actually does belong to the person who ordered the certificate.
Of course all of the above depends on the certificate being secure. This relies on the SSL software that the server is running being secure and not exposing any of the private data from the certificates on the server. The heartbleed bug is an example of where this was not the case. Servers running versions of openSSL between 1.0.1 and 1.0.1f contained a bug that allowed access to the private data in security certificates installed on the server. This both allowed the transmitted data to be decrypted and it allowed the certificate to be changed so that it could be misused to misidentify sites. To fix this the openSSL on the server needed to be replaced with a newer bug free version and all of the existing certificates needed to then be revoked and reissued. Any data that may have been captured via the exposed certificate then needed to be changed. In some cases the site owners advised their users when they completed this process while others didn't bother (or perhaps were not even affected). The best way to protect yourself if you are unsure whether your information may have been exposed by this (or any similar bug) is to change the information that you can at intervals so that even if the information was exposed that it is not longer correct. This is easily done with things like passwords where you just need to select a new password for each site every few weeks. It is not as easily done with things like credit card numbers but there the issuing authority provides you with some further protection in that if your details are misused they will reverse the transaction and then issue you a new card.
This article written by Stephen Chapman, Felgall Pty Ltd.