A certificate is a confirmation or a testimonial - a document basically saying this:
"We, the Certification Authority (CA), have verified and confirm that the subject "CommonName" is indeed what it claims to be. This confirmation is valid since (date) until (date)."
Some accessories of the X.509 certificate are:
- a pair of cryptographic keys (one of them, the public one, is a part of the certificate) provides that the claim presented was not forged;
- some information about the subject (depends on certificate purpose);
- the "fingerprint" - an identification of the certificate;
- the serial number of the certificate;
- the CRL list (of certificate serial numbers), maintained at the issuer (CA), showing whether or not the certificate is still valid (i.e., whether or not the certificate has been revoked).
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 the 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:
- A check is made that the server certificate comes from a trusted CA (warning or block, if not).
- 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.
- 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:
CAcert Class 1 root certificate
is the primary certificate of the highest level. As such, it must be self-signed. It is signed using the MD5 algorithm, which is no more considered as secure in present. Thus, some browsers warn against it. However, your declaration of trust of the authority CAcert means that you trust of its primary root's public and private key (and the public key is included in the Class 1 root certificate of CAcert), thus the signing algorithm of the root certificate itself is not important at all. This is different for all successive (and subordinate) certificates, including the ones issued to you. The algorithm SHA-256 is used there, commonly considered as secure nowadays.
Any certificate issued can be signed with the Class 1 Root certificate.
Since 20170101, however, new versions of the mainstream browsers (IE, Edge, Firefox, Chrome, Opera, and more) request ALL certificates, including CA root ones, 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.
Intermediate Class 3 root certificate
is the 2nd level signing certificate. It is signed by the Class 1 Root certificate. The control hash is created by the SHA-256 algorithm.
Any certificate issued to the CAcert community members having at least 50 APs can be signed with the Class 3 Root (intermediate) certificate.
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: