Una autoridad certificadora (CA) es una identidad digital que firma certificados y los convierte en documentos electrónicos válidos. Se emiten certificados de diferentes niveles, formando lo que se conoce como "cadena de certificación". Para que un certificado sea válido, la CA que lo firmó debe ser válida, y lo mismo se aplica a toda la cadena. El último elemento de la cadena de certificación es conocido como terminal. La validez de los certificados de una cadena es determinada en forma automática al evaluar un certificado.

Este es un ejemplo de una cadena de certificación:

Una Autoridad de Certificación es esa tercera parte fiable que acredita la unión entre una determinada clave y su propietario real. Actuaría como una especie de notario electrónico que extiende un certificado de claves, el cual está firmado con su propia clave, para así garantizar la autenticidad de dicha información.

Ahora bien, hemos visto como la firma electrónica se genera mediante la utilización de un par de claves (pública y privada), que se utilizan para cifrar y descifrar los mensajes. A diferencia de la firma autógrafa, que es de libre creación por cada individuo y no necesita ser autorizada por nadie ni registrada en ninguna parte para ser utilizada, la firma electrónica, y más concretamente el par de claves que se utilizan para firmar digitalmente los mensajes, no pueden ser creadas libremente por cada individuo.

En principio, cualquier persona puede dirigirse a una empresa informática que cuente con los dispositivos necesarios para generar el par de claves y solicitar la creación de éstas. Posteriormente, con el par de claves asignadas a una persona determinada, ésta se dirigiría a un Autoridad de Certificación para obtener el certificado electrónico correspondiente a ese par de claves. Sin embargo, en la práctica las Autoridades de Certificación cumplen ambas funciones: crean el par de claves (pública y privada) para una persona y expiden el certificado correspondiente a ese par de claves.

El otro concepto relacionado en este tema, es el certificado electrónico, el cual es un documento firmado digitalmente por una Autoridad Certificadora o de Certificación, en el cual se establece la relación entre una persona y su clave pública.

Por varias razones es conveniente que los certificados electrónicos tengan un periodo de validez, lo cual parece ser un principio básico en la emisión de cualquier tipo de identificación. Existe otra razón de carácter técnico y se refiere a que, por razones de seguridad, el usuario debe renovar sus claves, cada vez aumentando el tamaño de las mismas.

El estándar internacionalmente aceptado para certificados electrónicos, es el denominado X.509 de la CCITT (Consultative Committee for International Telephony and Telegraphy), cuyos campos básicos se ilustran en la siguiente Figura N° 3.



Figura N° 3. Certificado electrónico X.509

El número de serie es un número asignado por la Autoridad Certificadora y tiene el objeto de identificar unívocamente a cada certificado emitido por dicha Autoridad. Por otra parte, debido a que las operaciones electrónicas se pueden realizar entre puntos geográficos muy diferentes, con diversidad de horarios, las fechas a las que se hace referencia en este documento, están expresadas en la notación conocida como Hora Universal Coordinada (UTC) u hora del Meridiano de Greenwich. Una fecha en formato UTC, contiene el año, mes, día, hora, minutos y segundos, siempre con relación a la hora del meridiano de Greenwich.

¿Cómo funciona la firma electrónica?

El proceso de firma de un mensaje electrónico comprende en realidad dos procesos sucesivos:

- Proceso de firma del mensaje por el emisor.

- Verificación de la firma por el receptor del mensaje.

Esos dos procesos tienen lugar generalmente, de la manera que se expresa a continuación, en la que el emisor del mensaje es designado como “A” y el receptor del mensaje es designado como “B”.

Proceso de firma en un mensaje electrónico:

1) El emisor “A” crea un mensaje electrónico (mensaje de datos) determinado, por ejemplo, una propuesta comercial.

2) El emisor “A” aplica a ese mensaje electrónico una función “hash”, mediante la cual obtiene un resumen de ese mensaje.

3) El emisor “A” cifra ese mensaje-resumen utilizando su clave privada.

4) El emisor “A” envía a “B” (receptor) el mensaje electrónico que contiene los siguientes elementos:

· El cuerpo del mensaje, que es el mensaje en claro (es decir, sin cifrar). Si se desea mantener la confidencialidad del mensaje, éste se cifra también pero utilizando la clave pública de “B” (receptor).

· La firma del mensaje, que a su vez se compone de dos elementos:

- El hash o mensaje-resumen cifrado con la clave privada de “A”.

- El certificado electrónico de “A”, que contiene sus datos personales y su clave pública.

Verificación de la firma electrónica del mensaje de datos:

1) El receptor (B) recibe el mensaje electrónico que contiene todos los elementos mencionados anteriormente.

2) El receptor en primer lugar, descifra el certificado electrónico del emisor “A”, incluido en el mensaje, utilizando para ello la clave pública de la Autoridad de Certificación que ha expedido dicho certificado. Esta clave pública la tomará el receptor “B”, por ejemplo, de la página web de la Autoridad Certificadora, y estará a disposición de todos los interesados.

3) Una vez descifrado el certificado, el receptor “B” podrá tener acceso a la clave pública del emisor “A”, que es uno de los elementos contenidos en el certificado. Además podrá saber a quién corresponde dicha clave pública, dado que los datos personales del titular de la clave del emisor también están contenidos en el certificado.

4) Posteriormente el receptor utilizará la clave pública del emisor obtenida del certificado electrónico para descifrar el hash o mensaje-resumen creado por el emisor.

5) El receptor “B” aplicará al texto del mensaje (no cifrado), que también está contenido en mensaje electrónico recibido, la misma función hash que utilizó el emisor con anterioridad, obteniendo igualmente un mensaje-resumen. Es de hacer notar, que si el cuerpo del mensaje también ha sido cifrado para garantizar la confidencialidad, previamente el receptor debe descifrarlo utilizando para ello su propia clave privada (recordemos que el cuerpo del mensaje había sido cifrado con la clave pública de “B”).

6) Finalmente el receptor comparará el mensaje-resumen o hash recibido del emisor con el mensaje-resumen o hash obtenido por él mismo. Si ambos mensajes-resumen o hash coinciden totalmente, significa que el mensaje no ha sufrido alteración durante su transmisión. Por el contrario, si los mensajes-resumen no coinciden, quiere decir que el mensaje ha sido alterado por un tercero durante el proceso de transmisión, y más aun si el mensaje-resumen descifrado por el receptor es ininteligible, quiere decir que no ha sido cifrado con la clave privada del emisor sino por otra persona.

Todo esto suena engorroso, pero cuando el proceso descrito anteriormente se integra con los sistemas, lo que está pasando es totalmente transparente para el usuario. De igual forma, de esta manera quedan solventados los problemas relacionados a las principales premisas que deben cumplirse para propiciar el crecimiento de la economía digital: identidad, integridad, no repudio y confidencialidad.

Esto hace pensar que el protagonismo del Comercio Electrónico en el futuro, será mayor que el que tiene hoy en día, debido a que sin duda, constituye uno de los factores que contribuirá en mayor medida al éxito y desarrollo del mundo empresarial. Es igualmente cierto que la evolución futura de este tipo de comercio depende de forma directa de la capacidad de garantizar su seguridad mediante mecanismos como la firma electrónica y la criptografía, pero tampoco es conveniente que la psicosis de inseguridad electrónica nos lleve a frenar el despegue del comercio en Internet. En definitiva, sería conveniente que empezásemos a considerar el comercio electrónico no tanto como un problema de inseguridad sino más bien de confianza. A certificate authority or certification authority (CA) is an organization that issues digital certificates and public-private key pairs which are used by other parties to create digital signatures. It is an example of a trusted third party . CA's are characteristic of many public key infrastructure (PKI) schemes.

Also called: CA, Certificate Authority, and Certification Authorities.

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.