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 to get a personal (client) certificate

Generate a certificate request and a private key on a computer (preferably on your personal computer).

Files generated by the command line cryptographic program (eg openssl)

If you use a command line for openSSL or similar program, and enter the name of the resulting product, you will usually get these two most important files:

Note 1: .key and .csr file extensions are for reference only - other certificate generation programs may use other extensions!

Note 2: The certificate request file may be created in the P10 format with the extension .p10. Then its content may be binary and if so, the file needs to be converted to character (Base64) PEM format.

How to edit a binary certificate request to a form suitable for submission to CAcert

Use any website that allows you to read a binary file and encode it into Base64. For example, https://base64.guru/converter/encode/file. Add the BEGIN and END identification lines to the beginning and end of the file as shown in the following example listing:

... other lines of the certificate request, encoded in Base64

How to back up a certificate with a private key

The backup tool can be:

See Tutorials for the detailed description. Export (backup) creates a P12 file with the extension .p12 or .pfx, and with the following main parts:

Therefore, it's necessary to make the backup on the computer that contains the private key, ie where the certificate request was generated, or where the certificate and private key were restored from a backup file (.p12 or .pfx).

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 Certificates in Secure 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.

Using Certificates in Secure E-mail Communication (TLS)

The connection usually takes place on port 25 after verifying that both sides support the TLS protocol - nowadays: usually TLS 1.2 (RFC 5246) or TLS 1.3 (RFC 8446). The connection is started by the transmitting side (usually a client) with the SMTP command STARTTLS.

In TLS 1.2, the attempt is made to build the encrypted connection, even if some of the transferring partners do not have a certificate issued by a CA known to the other party - it is enough that the host has a private key related to its certificate. The connection can even be encrypted even if the client certificate does not exist at all.

The procedure is similar to a secure web browsing: generation and exchange of encryption keys used for a specific connection only, then exchange of encrypted messages with the ability to change keys during the connection.

TLS 1.3 connectivity is improved, among other things, by the fact that it can be built more quickly if the server side remembers parameters of a previous connection with that specific client side.

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: