english
Introduction
This short article is aimed at you as a user and shows you what digital certificates are, why you need them and how they work. It also describes in detail how you can apply for your own certificate free of charge and install it in your applications.
Since digital certificates can usually be very cost-intensive for private users, the use of certificates from the non-commercial certification authority CAcert Inc. is described below.
About CAcert Inc.
CAcert Inc. was incorporated in July 2003 in New South Wales (Australia) as a non-profit association.
CAcert is a community-operated, non-commercial Certification Authority (Root-CA or CA for short) that issues X.509 - Certificates free of charge for various fields of application. This is intended to provide an alternative to the commercial root CAs, some of which charge quite high fees for their certificates. (Source: wikipedia.org)
CAcert sees itself primarily as a CA for X.509 certificates. In addition, it offers the possibility to sign PGP keys for registered users. However, this article is limited to the handling of X.509 certificates.
Further information is available on the website of CAcert.org.
Purpose of digital certificates
When digital certificates are mentioned, X.509 certificates are usually meant. They secure their private communication or data in various ways:
- Secure communication via the internet (e.g. by e-mail)
- Encrypting data (usually in combination with a signature)
- Securing identities (electronic identity card)
In addition to the points mentioned above, there are other areas of application, but these are less intended for the normal end user:
Signing of source code
Certifying servers on the Internet (e.g. HTTPS, TLS or SSL).
Establishing private networks on the Internet (VPN).
In addition, there are many other areas of application, which will not be examined in detail here.
What is a digital certificate?
A digital certificate primarily confirms the identity of a person. It can also confirm the identity of an organisation or company, as well as servers on the internet.
For example, it can be ensured that a received e-mail really comes from the specified sender and has not been forged. Or it can be ensured that the online banking server you connect to is really the bank's server and that you have not been redirected to a foreign server by malicious software. In addition, the entire communication can be encrypted, thus preventing third parties from reading it.
As a rule, the person applying for a certificate identifies himself/herself to the certification office with a valid official ID. The certification authority then issues the certificate to the person. The certificate itself is protected against forgery by a digital signature of the certification authority.
With this certificate, the certified person can clearly identify himself/herself in the electronic world.
But how does the identification work and what makes the certificate so secure? This is described in the following chapters.
Structure of a digital certificate
First of all, the structure and content of a digital certificate should be described. The following data can be stored in a certificate (not all information is mandatory):
- Information about the certification authority (issuer).
- Name of the organisation
- E-mail address
- Information about the certified person/company (Subject)
- Name of the person
- E-mail address
- Name of organisation (optional)
- Home country (optional)
- Home region (optional)
- Residence (optional)
- The public key of the certified person
- Date from which the certificate is valid
- Date until which the certificate is valid
- The digital signature of the certification authority (protection against forgery).
Here is the content of an exemplary certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 52494 (0xcd0e)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=CAcert Inc., OU=http://www.CAcert.org, CN=CAcert Class 3 Root
Validity
Not Before: Apr 8 17:19:43 2011 GMT
Not After : Apr 7 17:19:43 2013 GMT
Subject: CN=Test Person/emailAddress=test.person@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (4096 bit)
Modulus (4096 bit):
00:dc:a2:6f:42:87:c6:21:56:39:a6:2e:40:97:d8:
d2:17:23:d4:ce:68:c0:98:ba:88:27:66:52:21:9d:
a4:59:6b:73:c4:f4:d5:6c:9b:9a:03:f6:c7:7e:0e:
a0:54:64:a9:ee:93:5d:d7:ce:e6:9f:39:7c:cb:7a:
62:f5:d4:8d:79:c3:1e:ff:c8:86:a1:94:99:3d:2e:
00:1c:6c:3a:39:6d:2d:72:45:d6:6f:87:7c:3d:e9:
62:82:ce:68:d1:3d:b1:17:b5:0c:39:f4:b6:49:1d:
f5:e4:af:9d:8c:78:12:a1:db:ca:a7:40:0f:dd:57:
e5:57:c5:ff:37:ad:a0:d4:62:d0:90:02:83:95:22:
d5:94:73:72:0f:e1:bc:5f:32:c5:fd:61:86:98:e7:
03:40:fb:ab:18:e1:23:e6:10:f0:fe:0b:08:a7:e4:
28:c8:03:4c:83:03:b7:9b:63:6d:d3:fb:c4:b7:39:
f5:63:1f:cb:dd:b9:92:e1:a9:1e:58:de:7f:35:d4:
e8:4b:4a:12:23:57:1c:93:87:0c:1a:62:c9:a1:e7:
56:44:37:db:7d:fd:81:24:0b:ac:ba:db:66:b3:04:
02:10:bd:88:c1:3c:f4:4b:13:7d:f3:34:6b:e0:96:
29:65:a0:ac:5c:75:3a:37:38:71:98:a0:55:4e:45:
d3:06:8a:6f:4b:83:5d:88:0e:5c:97:fb:3b:c9:66:
9b:94:6c:43:26:a2:51:67:70:5a:71:48:df:b8:01:
ba:9d:0b:44:a3:29:59:f9:0e:2f:e6:f7:3b:83:78:
40:39:88:b9:ee:88:33:1a:be:14:ac:b8:c7:f1:3d:
0a:82:ec:41:e8:1d:ea:a5:83:b5:2e:74:2a:e3:0e:
47:d8:7f:df:86:fd:f7:30:bf:82:da:01:a6:34:89:
c7:e1:5a:ce:6c:26:3d:a2:0b:e3:7e:10:92:34:e1:
d7:36:ba:c2:6b:7a:00:27:a3:5e:9e:de:f6:75:f1:
04:c7:b9:b3:b1:4a:04:af:6e:ee:54:87:d2:08:e0:
51:ab:9e:e5:cb:a3:d4:f3:6e:01:ad:63:0d:0e:c8:
fe:c3:bf:00:90:7a:05:28:c1:f7:f3:a6:02:e0:16:
33:fb:42:a1:2f:6c:53:f7:14:d6:e4:48:8f:33:21:
4f:c9:f0:67:18:97:9e:34:cf:75:40:72:43:52:8b:
90:cc:64:86:34:98:87:4f:c0:5e:95:fc:54:f4:cd:
68:45:c7:fc:b5:87:80:6b:f2:72:26:9f:d3:85:5f:
6d:91:33:06:b0:93:5a:bf:a5:93:ae:00:c0:97:7c:
85:6b:b3:f9:45:cf:d2:73:62:2a:08:ab:fa:29:92:
e6:06:45
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
Netscape Comment:
To get your own certificate for FREE head over to https://www.CAcert.org
X509v3 Extended Key Usage:
E-mail Protection, TLS Web Client Authentication, Microsoft Encrypted File System, Microsoft Server Gated Crypto, Netscape Server Gated Crypto
Authority Information Access:
OCSP - URI:http://ocsp.cacert.org
X509v3 Subject Alternative Name:
email:test.person@example.com
Signature Algorithm: sha1WithRSAEncryption
09:25:7d:0c:e3:88:24:57:1d:73:ca:4f:ac:1f:6b:07:5a:c2:
ab:75:1f:d1:8c:82:77:41:69:f6:a6:6f:d1:79:b5:e4:2d:9c:
bd:b8:5f:3f:0b:9e:36:57:ef:49:90:89:0d:f7:5f:fa:60:41:
87:11:08:81:58:87:06:df:c4:7e:86:9b:b8:b9:de:e6:50:3a:
28:ed:af:9e:94:b9:53:d5:b8:2e:ec:45:d4:46:de:04:a7:ab:
5f:6e:03:d4:94:d5:bd:13:14:6c:3d:98:66:ad:f8:57:07:02:
2b:32:ca:9a:47:a1:82:e6:0b:39:c7:b9:54:87:8d:bb:fb:a3:
22:2f:ad:c1:80:e2:1c:63:53:3f:f1:3a:38:8b:6e:4d:db:dd:
09:85:0e:fe:45:40:ba:24:55:f2:cc:29:ca:60:6f:f5:eb:d2:
a7:a7:0d:ee:e1:6e:7c:4f:65:f0:2a:ec:5f:44:36:89:fd:1a:
80:9c:5d:da:56:18:6a:17:e7:cf:39:3e:90:ea:c5:49:5a:6f:
55:3d:34:4b:60:08:ee:7a:d4:4d:ae:e9:ce:79:cd:8b:9f:f0:
ad:8e:26:79:e2:8c:e5:8a:ae:c7:e8:9e:a1:a8:02:ce:49:27:
03:d6:00:7f:e0:c0:b8:67:0f:8d:40:ea:5b:8e:1c:56:96:74:
c9:b7:83:4e:f7:99:72:85:09:44:9e:1f:1d:ad:60:b0:9d:eb:
3e:a1:ec:61:59:d2:5e:27:a4:34:5d:3c:41:bc:a6:0e:01:4a:
4f:b6:43:55:14:82:d7:85:d0:62:44:9c:33:6b:ae:29:e8:88:
84:ae:cd:c7:67:e2:d7:ef:0b:93:74:06:bd:2e:91:e4:34:c2:
55:8a:9e:fc:9f:1f:b7:18:5f:f1:a1:17:83:99:d9:9f:d2:1c:
01:d1:51:af:11:b2:c3:bb:7e:10:85:a7:89:56:cc:45:b8:1a:
ac:d1:cf:f5:73:72:c6:b6:86:33:22:a7:ad:c2:42:bd:95:c3:
4b:32:a1:c5:3e:fd:7d:a8:16:4f:ec:d2:00:94:52:50:54:02:
21:cc:94:8a:ee:70:52:45:55:32:bc:16:5d:0a:21:3c:92:19:
43:47:6c:3a:d4:f5:06:bd:7a:85:36:68:ba:79:50:f6:06:e7:
11:e2:bf:43:16:82:18:99:dc:10:4a:9d:bd:df:66:8a:01:79:
13:39:ca:9d:dc:49:3c:5e:01:5f:89:24:a3:64:6a:f0:3d:cb:
5b:88:db:cc:76:5b:00:40:5b:04:71:9b:29:83:e6:53:0f:30:
c3:e0:e3:92:5d:26:ef:f4:2c:d9:04:96:09:ee:00:37:6f:2a:
93:7f:b9:23:9a:ca:87:4c
Asymmetric encryption
If you want to understand digital certificates, you must learn the basic rules of asymmetric encryption. These are described below in as simple manner as possible.
In contrast to symmetric encryption, where there is only one key (e.g. the password for password-protected files), two keys are needed here: a private key and a public key. Both together make up a so-called key pair.
The private key is secret. It must not be made public under any circumstances. It is usually protected by another encryption method (symmetric encryption), so that a password must be entered when using the private key. You must keep it safe and protect it from being read by others.
The public key, on the other hand, may be published at will. Data that has once been encrypted using the public key can no longer be decrypted using the public key, but only with the private key. The reverse is also true: data that has once been encrypted using the private key can only be decrypted using the public key.
This connection is important to understand! For example, checksums over documents are encrypted with the private key (see chapter Digital signing of documents). This means that anyone who knows the public key can read and check the checksum. However, no one can forge the checksum, as this would require the private key.
Data intended for a single recipient is encrypted with the recipient's public key, so that only he or she can decrypt the data again using his or her private key. Decryption would not work with the public key.
Analogous to the public and private keys, there are public and private certificates. The public certificate contains the public key and the certificate information. Strictly speaking, the private certificate is a PKCS12 file in which the public certificate and the private key are stored. This file is usually secured by a password (symmetrically encrypted).
Digital signing of documents
Digital signatures of documents are the order of the day these days. The reason for this is the (Swiss) discussion about the Signature Law (SigG) and the Signature Decree (SigV). But what is a digital signature?
A digital signature ensures that the document has not been altered by the originator (or any other person) after creation. This is done by calculating the checksum of the document, using asymmetric encryption, and also an X.509 certificate.
The digital signature is created as follows:
- A checksum (also called a hash or hash) is calculated for the entire document.
- This hash is encrypted with the author's private key.
- The author's certificate (which contains the public key) and the encrypted checksum are attached to the document.
- This digitally signs the document.
The validity of the document is checked as follows:
- the verifier (recipient) receives the certificate attached by the author and the encrypted checksum from the document.
- He decrypts the checksum using the author's public key found in the attached certificate.
- It calculates its own checksum from the document and compares it with the decrypted checksum.
- If the checksums match, the document is valid. If the checksums do not match, the document has been altered (or forged) after signing.
Secure communication over the internet
Similar to digital signing of documents, secure communication takes place over the Internet. This process is described here using the example of a sent e-mail:
- The author writes an email
- A checksum is calculated from the contents of the e-mail (including all - encrypted - e-mail attachments).
- The checksum is encrypted with the sender's private key (signature).
- A certificate and encrypted checksum is attached to the email.
- Optionally, the entire content of the email is encrypted with the recipient's public key. Then the message is both signed and encrypted.
- The email is sent.
- The recipient receives a message (e-mail).
- If the message was encrypted with the recipient's public key, he decrypts it with his private key (from his private certificate or PKCS12 file).
- Decrypts the enclosed checksum (signature) and compares it with its own checksum calculated for the entire content of the email.
- If the checksums are the same, the message originated from the sender and was not modified during the communication.
- If the checksums are different, the message has been tampered with.
The S/MIME technology is used to encrypt and sign emails. We will not go into details here. S/MIME is the most common way of encrypting and/or signing content. Details can be found on the Internet.
In addition to email communication, this type of secure communication can also be used in other communication protocols (e.g. chat, internet telephony, etc.).
Data encryption
Data can be encrypted and signed not only in emails or (text) documents. In principle, any type of data (images, audio, video, text, spreadsheets and any other format you can imagine) can be encrypted and signed. Usually the S/MIME file format mentioned above is used for this.
Your email client supports the use of certificates, e.g. for emails. You must encrypt any data yourself. You need additional software to do this (such as OpenSSL).
Web of Trust (WoT)
The Web of Trust (WoT) is the most commonly used cryptographic method of authenticating digital keys using a network of mutual acknowledgements (digital signatures). Source: Wikipedia
Digital certificates work with keys - so-called key pairs. A certificate contains a person's public key. You need to ensure that this key actually belongs to the person named in the certificate. If this is not the case, a malicious third party could use their own private key to, for example, forge signatures on documents and store their own public key in a forged certificate. If this certificate is now used to verify a digital signature, the verified signature appears genuine, even though it has been forged.
The required assurance is provided by a certification authority. Each certificate contains a CA signature, which in turn consists of the encrypted checksum of the issued certificate and the CA root certificate. This is based on the same principle as digital document signing, except that the issued certificate is used as the document.
To verify the validity of a certificate, the reviewer must know and trust the CA (or its root certificate). If the CA is unknown or not trusted, the certificate cannot be successfully verified. Therefore, many software vendors (e.g., web browsers and email clients) have already preinstalled some root certificates from known CAs.
Each communication partner must therefore know the root certificate of the other partner's CA. Otherwise the certificates cannot be verified! The root certificates of commercial CAs are usually pre-installed in most applications. This is where CAcert critics object: CAcert root certificates are preinstalled in very few commercial applications. However, CAcert Inc. is currently working to get itself audited so that it can store its root certificates in other applications by default. At CAcert, you can find list of applications that currently have CAcert Inc. root certificates pre-installed.
There are other types of WoT, such as those used in PGP. There are no explicit certification authorities. Anyone can certify anyone. So the WoT here would not be mapped through a hierarchical structure like X.509 certificates use, but through a graph-like structure.
Registration with CAcert
Below is described, how you can apply for a free digital certificate from CAcert Inc.
First you need to create a user account. To do so, go to the CAcert.org homepage. On the right-hand side you will find a menu bar. Under Join you can apply for membership.
The next step is to fill in the form with your registration details. Important: you must enter your correct name and a valid email address here. Otherwise no certificate can be issued!
After registering with CAcert, simply reply to the confirmation email.
At this point, we would like to point out one special feature of CAcert. In the case of commercial certification authorities, the applicant usually proves his/her identity to the certification authority using the Post-Ident procedure. Since CAcert is a community-driven association, a different procedure applies here.
CAcert uses so-called Assurance program. There are a number of volunteer assurers (verifiers) who authenticate community members (assurrees) and confirm their identity for CAcert. Each assurree can be credited with a limited number of points if he/she presents more than one official photo ID (usually an ID card and a driver's license). To do so, assurrees must meet the assurer in person. On the CAcert website, you can find an assurer near your home here. You can also find out about assuring events on the website. These usually take place at trade fairs. There are always several assurers present who can confirm your identity. To verify your identity they need a CAP form, which you have to fill in and sign in the presence of the assurer.
You need 50 Assurance Points (APs) to be considered guaranteed and to use your real name on the certificate. To achieve this number of points, you need to be assured by at least two assurers. If you do not have at least 50 points on your account, only the name CAcert WoT User will appear on certificates. However, your email address will be listed even if you have 0 points.
If you have less than 50 points in your account, your client certificates are valid for a maximum of six months. After six months, you must renew your certificate. If you have more than 50 points, your client certificate is valid for two years.
If you have more than 100 points on your account, you can take the Assurer's Challenge exam and you can assure others yourself. However, there are certain rules that must be followed!
The assurers can give 10 to 35 points to another person depending on how many Experience Points (EPs) they have in their account.
More information about this can be found on the CAcert Wiki "How many points do I need for... (Privileges)", also at CAcert Point System and in German at Presentation on Assurer Training.
Requesting a certificate
If you have successfully registered with CAcert Inc., you can have a certificate issued right away. Log in to CAcert.org with your password. In the right menu bar you will see various items to edit your details.
For example, if you have several email addresses, you can add new email addresses here. For each certificate you are applying for, you can add one or more email addresses listed here.
The menu item "Client Certificates" is used to apply for certificates (New) and later to manage certificates already issued (View).
Using the web application
Note: After 20230501, no browser can generate a key pair anymore, for security reasons. Use the new procedure using the Show advanced options checkbox. Part of the procedure is to navigate to the WoT CAcertu by clicking New in the Client Certificates menu. This will display the form that you need to fill out for the request.
Depending on how many points you have in your CAcert account, this form will look slightly different. If you have more than 50 points (i.e. your identity has been confirmed by at least two CAcert Guarantors), you can add your real name to your certificates. If you have less than 50 points, the name on your certificate will be CAcert WoT User.
You can add one or more email addresses to your certificate depending on how many addresses you have entered and verified in your account.
After exiting the web application with a "bounce" to the CAcert site and returning to the web application, you have a P12 file to download and then import into your browser or operating system.
Obtaining the CSR application by the utility and submitting it for signature
If you don't want to use the CAcert web app, you need to do a bit of prep work. First, you need to generate an RSA key pair (key pair) on your computer. Then you need to create a certification request (CSR). Then copy this into the Optional Client Request (CSR) input text box. This is how it works:
Creating a key pair
If you want to create a few keys yourself, you need the OpenSSL program. Download it from the OpenSSL website and install it.
(You can also use XCA or Kleopatra, which have graphical user interfaces.)
Once the installation is complete, you can generate the key pair using the following command at command prompt:
openssl genrsa -aes256 -out cacert.org.privatekey.pem 4096
The command generates RSA key pairs of 4096 bits and stores them in the file cacert.org.privatekey.pem. It is imperative that you keep this file safe'! When creating the file, you will be asked to enter a password to protect the file. Enter the strongest password possible (as long as possible, upper and lower case letters, numbers and special characters).
You then create a certificate request request (CSR) with the command:
openssl req -new -key cacert.org.privatekey.pem -out cacert.org.csr -days 7
Use it to apply for an X.509 certificate and submit it to CAcert. This application is valid for 7 days. It is stored in the cacert.org.csr file. The contents of this file must be copied into the Optional Client Request (CSR) text box on the CAcert form.
The signer's response always contains both the download links and the certificate dump in Base64 character format with two (front and rear) comments - PEM format! In this procedure, use the link to download the certificate in PEM format, with the .crt suffix.
To check the contents of the (public) certificate you just received, you can enter this command:
openssl x509 -in publiccert.pem -noout -text
Note: A certificate created in this way does not contain your private key!
Now you just need to create your own PKCS12 file. Into the file you put the certificate you just received in PEM format and your private key. This file will be your private certificate and you must keep it safe! The command to create a PKCS12 file is as follows:
openssl pkcs12 -des3 -export -in publiccert.pem -inkey cacert.org.privatekey.pem -out privatecert.p12
You can now import the resulting privatecert.p12 file into a Web browser, e-mail client, or other software that uses X.509 certificates.
This file is also created by CAcert's "Client certificate generation in your browser" web application.
For more information on using OpenSSL, see examples here:
Using your new certificate
X.509 certificates are now supported by a large number of applications. Only a few of them are mentioned here:
Electronic mail (e-mail) client applications
FairEmail for Android - see Google Play
Web browsers (communicators)
However, certificates are not only used in email and web browser applications. For example, your own tax return can also be signed and sent using a digital certificate (here the certificate is issued by the tax office).
The procedure for installing the certificate and the CRL (see below) into applications can be found in the documentation for the respective application.
Certificate renewal
Your certificate will expire after a set period of time. For CAcert, this is either 6 months for users with less than 50 AP points, or 2 years for users with 50 or more AP points.
If your certificate has expired, you must renew it. This is done using web CAcert.org.
You can either create a new certificate under the Client Certificates menu item and then let the old certificate expire, or you can view your current certificate and click Renew. (To see and renew/revoke certificates, please use the link for displaying all certificates, including the expired/revoked ones.)
Using "Renew" updates the validity of the certificate. Neither the private nor the public key is changed, both remain valid.
The rest of the procedure is described in the chapter Requesting a certificate.
Certificate revocation
If you no longer wish to use the certificate, you should revoke it. One reason for this may be that your private certificate has fallen into unauthorised hands. Once revoked certificate cannot be used or renewed.
To revoke, view your certificates in the Client Certificates - View menu, select the certificate to be revoked, mark it, and click on Revoke. Your revoked certificate will then be stored in the so-called Certificate Revocation List (CRL). You cannot then renew or download this certificate from CAcert.
Applications, browsers, and other programs use CAcert's OCSP server to detect revoked certificates. The OCSP server maintains the current revocation status. Using it quickly and without the need to periodically download CRLs ensures that invalid certificates are not used by applications. If you still need an up-to-date CAcert certificate revocation list, you can find it at http://crl.cacert.org/revoke.crl.
Author: Henrik Sachse
Email: <henrik.sachse AT posteo DOT de>
English translation and review: <alkas AT SPAMFREE cacert DOT org>