Certificates (Overview)

A certificate is a confirmation or a testimonial - a document basically saying this:

Some accessories of the X.509 certificate are:

Contents of the certificate may be saved in a computer as data in a database (e. g. Windows Registry) or as a file.

How the secured transfers work

Using a certificate to encrypt-decrypt email messages

Let's imagine that Alice wants to send a message to Bob such way, that no unauthorized person could intercept and decrypt the message travelling through Internet. Alice needs the Bob's public key, which is a part of his client certificate; thus she needs to have his personal (client) certificate. Then she encrypts her message with Bob's public key. As the RSA encryption-decryption system is the asymmetric one, only the person possessing the complementary private key can decrypt the message, and that person should be Bob himself only.

Using a certificate to provide a proof of authenticity

Now, let's imagine that Bob is the author of some message/document/code. He wants to provide any recipient of his work with the possibility to verify, that the message/document/code is indeed Bob's work, and that it remains unchanged. So Bob has to add his digital signature to his work (in other words, he needs to sign his message/document/code). He also needs to attach his certificate (which contains his public key). Bob's digital signature is created on his (the sender's) side by creating a hash of the message/document/code and then by encrypting the hash with Bob's private key. Now, every recipient can create his/her own hash of that Bob's work, then decrypt Bob's signature resulting in the former hash, and compare the two. If they are equal, it is the proof, that the author of the work is indeed Bob, and that the work was not tampered with during its travel through Internet.

In both examples, the "hard work" with hashing, encryption, decryption is usually done by computer programs. The hash algorithm must be very precise, to product unpredictable hashes. This is achieved primarily by using efficient random number generators (RNGs).

Using a certificate to the secured web browsing

The basic type of a HTTPS connection (HTTP over SSL/TLS, "S" for "secured") is the exchange of encrypted messages of the type request (GET/POST) - answer. The exchange takes place between a client (browser) and a web server. It runs approximately as follows:

  1. A check is made that the server certificate comes from a trusted CA (warning or block, if not).
  2. Two pairs of keys are generated both on the client and the server side, and public keys are exchanged. All the keys referred in the next paragraph are just those generated here.
  3. The client encrypts its request or form data (with server's public key), then the server decrypts the request (with its private key), prepares one or more parts of its reply, encrypts them (with the client's public key) and sends the reply. The client decrypts the reply (with its private key). If the communication is longer, then any part can initiate the "cipher change", i.e. create a new key pair and exchange public keys again. As this exchange is already encrypted, this process is easier then the initial start of the communication.

All the "hard work" is performed again by computer programs - the client (browser) and the server.

Various kinds of the X.509 certificates

How strong X.509 certificates can I get from CAcert ?

Security is a serious, important concept. That's why the strength and other properties of certificates, you can get from CAcert, vary depending on the level of your trustfulness, which is measured by the assurance points (APs). You can obtain APs by getting assured, i.e. you show your identity with your personal documents you submit a CAcert assurer(s). Your CAcert certificates' abilities depends on the total APs obtained, as stated in this article:

How trustworthy is the CAcert itself ?

The trustfulness of the CAcert is derived from how CAcert verifies certificates applicants assurance issues, and how well CAcert secure private keys of its root certificates against abuse. Nowadays (2016) two CAcert root certificates are used:

Since 20170101, however, new versions of the mainstream browsers (IE, Edge, Firefox, Chrome, Opera, and more) request ALL certificates, including CA roots, to be signed using the SHA-256 algorithm. Such SHA-256 signed version of CAcert root certificate does already exist (see Wiki FAQ), and it is thus recommended to replace existing MD-5 signed root with it. All important data, including the public key of the CAcert root certificate, remain unchanged. The replacing procedure is described here.

For details of the two CAcert root certificates please read this article:

Private keys of both root certificates are stored by CAcert such manner, that they are inaccessible from Internet.

For the technical details about certificates issued please read the Policy referred from the following article:

Certificates (last edited 2018-02-10 09:44:40 by AlesKastner)