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 to get a personal (client) certificate
Generate a certificate request and a private key on a computer (preferably on your personal computer).
Depending on the purpose, certain data can be encrypted using the private key, and decrypted using the public key, or vice versa. However, the private key should always remain where it was generated.
Different cryptographic programs or some web browsers can be used to generate those two items. The most comfortable way to do this is to use a browser to get the certificate and usually install it on a single visit of the CA's website (for example, CAcert Web of Trust website). Currently, however, the authors of the most famous browsers (Firefox, Chrome, IE, Edge, Opera, Safari, Maxthon) have removed this ability, allegedly for security reasons.
- In addition to browsers, there are other cryptographic programs, with graphical or command line interface, that can generate the private key and certificate request. However, you must edit the certificate request file (CSR) to Base64 text format, and submit it manually to the CA (for example, to the CAcert Web of Trust website).
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:
This is your private key. You should keep this key only on the computer where and for which it was created. (Except for the key and certificate backup, see below.)
NO Certification Authority needs/requests this file neither the contained key!
- Sending it in an email to a CA is the same as sending the PIN of your credit card to someone.
This is your certificate request and it contains your currently generated public key.
This file needs to be converted to the proper character (PEM) form, and then submitted to CA.
This means (at CAcert): Check the "Advanced options" checkbox. Paste the contents of the file to the CAcert webpage "New" and check additional options you require (e- email address, your name, the ability to sign documents and/or files). CAcert will then create your new certificate and offer you to download/install it.
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:
-----BEGIN NEW CERTIFICATE REQUEST----- MIIEHzCCAwcCAQAwVzELMAkGA1UECwwCSVQxDjAMBgNVBAoMBUFMS0FTMRIwEAYD VQQHDAlTb2tvbG5pY2UxCzAJBgNVBAYTAkNaMRcwFQYDVQQDDA5tYWlsLmFsa2Fz ... ... other lines of the certificate request, encoded in Base64 ... 6UMLNsXu8F7ZEU+LP1oyiWSBAO/LqLuqMlc5KvRRyVENJMpPlNYJdL2YRcLTzF9+ F6CC -----END NEW CERTIFICATE REQUEST-----
How to back up a certificate with a private key
The backup tool can be:
- A command line program (like openSSL)
- An operating system program (like MMC)
- Another cryptographic program (such as XCA)
- Browser with Certificate manager (Firefox, Chrome, ...)
See Tutorials for the detailed description. Export (backup) creates a P12 file with the extension .p12 or .pfx, and with the following main parts:
- The appropriate private key
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:
- 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.
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:
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 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.
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: