There are many CAs. Commercial CAs charge for their services. Institutions and governments may have their own CAs, and there are free CAs.

Issuing a certificate

A CA will issue a public key certificate which states that the CA attests that the public key contained in the certificate belongs to the person, organization, server, or other entity noted in the certificate. A CA's obligation in such schemes is to verify an applicant's credentials, so that users ( relying parties ) can trust the information in the CA's certificates. The usual idea is that if the user trusts the CA and can verify the CA's signature, then they can also verify that a certain public key does indeed belong to whomever is identified in the certificate.

If the CA can be subverted, then the security of the system breaks down. Suppose an attacker, Mallory (to use the Alice and Bob convention), manages to get a certificate authority to issue a false certificate tying Alice to the wrong public key, which corresponding private key is known to Mallory. If Bob subsequently obtains and uses the public key in this certificate, the security of his communications could be compromised by Mallory — for example, his messages could be decrypted, or he could be tricked into accepting forged signatures.

Security

The problem of assuring correctness of match between data and entity when the data are presented to the CA (perhaps over an electronic network), and when the credentials of the person/company/program asking for a certificate is likewise presented, is difficult, which is why commercial CAs often use a combination of authentication techniques including leveraging government bureaus, the payment infrastructure, third parties databases and services, and custom heuristics. In some enterprise systems, local forms of authentication such as Kerberos can be used to obtain a certificate which can in turn be used by external relying parties. Notaries are required in some cases to personally know the party whose signature is being notarized; this is a higher standard than can be reached for many CA's. According to the American Bar Association outline on Online Transaction Management the primary points of federal and state statutes that have been enacted regarding digital signatures in the United States has been to "prevent conflicting and overly burdensome local regulation and to establish that electronic writings satisfy the traditional requirements associated with paper documents." Further the E-Sign and UETA code help ensure that:

(1) a signature, contract or other record relating to such transaction may not be denied legal effect, validity, or enforceability solely because it is in electronic form; and
(2) a contract relating to such transaction may not be denied legal effect, validity or enforceability solely because an electronic signature or electronic record was used in its formation.

In large-scale deployments Alice may not be familiar with Bob's certificate authority (perhaps they each have a different CA), so Bob's certificate may also include his CA's public key signed by a different CA₂, which is presumably recognizable by Alice. This process typically leads to a hierarchy or mesh of CAs and CA certificates.

List of Certification Autorities

Here is a list of certificate authorities. For a CA to be at any use, the client must trust the CA. In case of a browser visiting a web site with a certificate, the CA for that certificate should ideally be known by the browser. If not the user will be asked wether he trusts this CA. Most of the CAs below claim to be known by 99% of all browsers.

What is a Certificate Authority?

Certificate Authority or Certification Authority (CA) is an entity, which is core to many PKI (Public Key Infrastructure) schemes, whose purpose is to issue digital certificates to use by other parties. It exemplifies a trusted third party. Some certification authorities may charge a fee for their service while some other CAs are free. It is also not uncommon for government and institutions to have their own CAs.

More about Issuing a Certificate

The certification authority issues a Public Key Certificate (PKC), which attests that the public key embedded in it indeed belongs to a particular person, server, organization or any other entity as said in the certificate. In such schemes, the obligation or duty of CAs is to verify the credentials of the applicants before issuing the certificate so that the users can trust the information in the CA certificates of a particular entity without any second thoughts.

But this model is not fool proof, at least in a theoretical point of view. For example, if a person (say A) could manage to get a certification authority to issue a false certificate tying another person (say B) to a wrong public key, whose corresponding private key is available to A, then this could lead to some serious security problems. That is, if a third person (say C) eventually obtains and uses the public key in this certificate, then with the private key, it is possible for A to break into the security contours of C's communication. In such a way, on a practical level, C's messages could be decrypted and the person could be duped to accept forged signatures.

Security

As mentioned above, while the correctness of a certificate is taken for granted, it is to be accepted that assuring the correctness of data presented by companies, person or programs seeking a certificate is rather difficult and has glaring loop holes. That is, it is not an impossible task for an applicant to dupe the certification authority. In order to plug these chinks in the armor, certification authorities usually use a combination of authentication techniques which include leveraging government bureaus, third parties databases and services, the payment infrastructure, and custom heuristics to analyze the trust worthiness of the applicant. In few enterprise systems, local types of authentication like Kerberos can be used to obtain the certificate, which in turn can be used by relying third parties. Notaries may be required in some cases to personally verify the party whose sign is being notarized.