I. Introduction
Digital certificates are the cornerstone of mutual trust between individuals in the modern Internet.
If there is no digital certificate, then there will be no various e-commerce platforms and convenient electronic payment services.
Digital certificates are a very important part of network security. If you want to learn network security well, you must fully understand its principles.
The digital certificates we mentioned so far are all based on the X.509 standard formulated by ITU.
This article is purely a personal learning experience sharing and exchange, with a lot of content and messy, so mistakes are inevitable, and it is for reference only!
If you find something wrong, please let me know if you can, thank you very much!
2. Basic knowledge
2.1 Asymmetric encryption
There are two keys, one is Key_1 and the other is Key_2.
After a piece of plaintext is encrypted with Key_1 by some encryption algorithm, the ciphertext can only be decrypted with Key_2, but cannot still be decrypted with Key_1.
Conversely, the ciphertext after the plaintext is encrypted with Key_2 can only be decrypted with Key_1, but cannot still be decrypted with Key_2.
An encryption algorithm that satisfies this characteristic is called an asymmetric encryption algorithm.
Currently commonly used asymmetric encryption algorithms are RSA, DSA and so on.
2.2 Digest Algorithm
After various "data" of variable length are processed by some algorithm, a piece of fixed-length data can always be generated. This fixed-length data is called "hash value".
If this algorithm can meet the following characteristics, it can be called a summary algorithm.
- Various "data" of variable length can be easily generated into "hash value".
- The original "data" cannot be deduced through the "hash value".
- It is not possible to find another "data" with the same "hash value".
Currently commonly used digest algorithms include MD5, SHA-1, SHA-256, etc.
2.3 Digital signature
A digital signature is actually an "encrypted hash value" obtained by encrypting the "hash value" through an asymmetric encryption algorithm.
The workflow of digital signature is as follows:
Digital signatures are generally used for identity authentication and prevention of repudiation.
2.4 Structure diagram of X.509 digital certificate
Simply put, a digital certificate is an information sheet with a digital signature attached.
The following figure may help to understand this article.
2.5 Common methods of information theft on the Internet
Suppose the client "C" wants to communicate with the server "S" on the other side of the Internet without confidentiality, and the client "C" does not deploy any server authentication mechanism.
2.5.1 Fake server
The fake server "fake_S" pretends to be "S" and communicates directly with "C".
If "C" intends to pass sensitive information such as passwords to "S", then the sensitive information will be intercepted by "fake_S".
At this time, "fake_S" will generally report an error to "C" and then retreat. Then "C" will communicate with the real server "S".
In this way, "fake_S" has obtained sensitive information. And "C" will also be aware of it, but most people think that the network is unstable and don't take it to heart.
At present, the common spoofing methods include DNS spoofing and so on.
2.5.2 Man-in-the-middle attack
The fake server "fake_S" can build a bridge between "C" and "S", forward the packets from "C" to "fake_S" to "S", and forward the packets from "S" to "fake_S" to "C".
Then, "fake_S" can listen to all communications between "C" and "S", and can also modify the content of the data packets and actively launch attacks.
This attack method is called a man-in-the-middle attack. The man-in-the-middle attack is also very subtle. Generally speaking, "C" cannot detect any abnormal situation.
At present, common spoofing methods include ARP spoofing and DNS spoofing.
3. Signing of digital certificates
The RSA certificate is used as an example, certificates of other algorithms may be different.
3.1 Construction of Root Certification Authority
Brief process
- The root certification authority "CA" generates the public key ca_KeyPub and private key ca_KeyPri, and the basic information table ca_Info. ca_Info generally contains information such as the name of the "CA" and the validity period of the certificate.
- The root certification authority "CA" performs a hash operation on (ca_KeyPub + ca_Info) to obtain the hash value ca_Hash.
- The root certification authority "CA" uses its private key ca_KeyPri to asymmetrically encrypt ca_Hash to obtain the encrypted hash value enc_ca_Hash.
- The root certification authority "CA" will combine (ca_KeyPub + ca_Info + enc_ca_Hash) to generate a self-signed digital certificate "ca_Cert". This certificate is called the root certificate.
The root certificate "ca_Cert" contains: ca_KeyPub + ca_Info + enc_ca_Hash.
"ca_Cert" can be used to sign the next level of certificates.
3.2 Certificate signing by single-level certification authority
Brief process
- Server "S" generates public key s_KeyPub and private key s_KeyPri, and basic information table s_Info. s_Info generally contains information such as the name of "S" and the validity period required by the certificate.
- The server "S" sends s_KeyPub, s_Info to the root certification authority "CA".
- After the root certification authority "CA" verifies the identity of "S" in some way, add some information ca_Info of the root certification authority itself, and then perform hash operation on them (s_KeyPub + s_Info + ca_Info) to get the hash value s_Hash .
- The root certification authority "CA" uses its private key ca_KeyPri to asymmetrically encrypt s_Hash to obtain the encrypted hash value enc_s_Hash.
- The root certification authority "CA" signs the combination of (s_KeyPub + s_Info + ca_Info + enc_s_Hash) into a digital certificate "s_Cert" and sends it back to "S".
The server certificate "s_Cert" contains: s_KeyPub + s_Info + ca_Info + enc_s_Hash.
"s_Cert" cannot be used to sign lower-level certificates.
3.3 Construction of secondary (or above) certification bodies
In reality, relying on only one certification authority cannot meet the signing requirements of massive certificates, so it is necessary to build a branch certification authority.
Brief process
- The secondary certification authority "CA2" generates the public key ca2_KeyPub and private key ca2_KeyPri, as well as the basic information table ca2_Info. ca2_Info generally contains information such as the name of "CA2" and the validity period required by the certificate.
- The secondary certification authority "CA2" sends ca2_KeyPub and ca2_Info to the root certification authority "CA".
- After the root certification authority "CA" verifies the identity of "CA2" in some way, add some information ca_Info of the root certification authority itself, and then perform hash operation on them (ca2_KeyPub + ca2_Info + ca_Info) to get the hash value ca2_Hash .
- The root certification authority "CA" uses its private key ca_KeyPri to asymmetrically encrypt ca2_Hash to obtain the encrypted hash value enc_ca2_Hash.
- The root certification authority "CA" signs the combination of (ca2_KeyPub + ca2_Info + ca_Info + enc_ca2_Hash) into a digital certificate "ca2_Cert" and sends it back to "CA2".
The content contained in the secondary certification authority certificate "ca2_Cert": ca2_KeyPub + ca2_Info + ca_Info + enc_ca2_Hash.
"ca2_Cert" can be used to sign the next-level certificate.
The construction process of a three-level or higher-level certification body is similar to this process, so I won't repeat it here.
3.4 Signing of certificates by secondary (or above) certification bodies
Brief process
- Server "S2" generates public key s2_KeyPub, private key s2_KeyPri, and basic information table s2_Info. s2_Info generally contains information such as the name of "S2" and the validity period required by the certificate.
- The server "S2" sends s2_KeyPub and s2_Info to the secondary certification authority "CA2".
- After the secondary certification authority "CA2" verifies the identity of "S2" in some way, add some information ca2_Info of the root certification authority, and then perform hash operation on them (s2_KeyPub + s2_Info + ca2_Info) to get the hash value s2_Hash.
- The secondary certification authority "CA2" uses its private key ca2_KeyPri to asymmetrically encrypt s2_Hash to obtain the encrypted hash value enc_s2_Hash.
- The secondary certification authority "CA2" signs the combination of (s2_KeyPub + s2_Info + ca2_Info + enc_s2_Hash) into a digital certificate "s2_Cert" and sends it back to "S2".
The server certificate "s2_Cert" contains: s2_KeyPub + s2_Info + ca2_Info + enc_s2_Hash.
"s2_Cert" cannot be used to sign lower-level certificates.
The certificate signing process of a third-level or higher-level certification body is similar to this process, and will not be repeated here.
As can be seen from the above, the certificate signing process is: "ca_Cert" -> "ca2_Cert" -> "s2_Cert". It is a complete chain, we call it "certificate chain".
3.5 Certificate signing in reality
Most certificates in reality are signed by secondary certification authorities.
Also, once the server's identity has been verified in some way (such as DNS), there is generally no need to ask the server to provide any information (CSR file).
The certification authority will provide the certificate, certificate chain and private key, and the server can use it directly.
Fourth, the application of digital certificates
4.1 Requirements
- Secure communication (SSL/TLS) is implemented between the server and the client through asymmetric encryption.
- The client needs to verify the real identity of the server, and the server cannot be impersonated.
- The server does not need to verify the identity of the client.
- Digital certificates use the RSA algorithm.
4.2 Server configuration
If the certificate used by the server "S" is directly signed by the root certification authority "CA", then only need to provide "s_Cert" to the client, and then use the private key s_KeyPri to achieve asymmetric encryption.
If the certificate used by the server "S2" is not directly signed by the root certification authority "CA", then not only the "s2_Cert" but also the certificates of all certification authorities except the root certification authority "CA" need to be provided to the client (here Also provide "ca2_Cert"), otherwise the client may prompt that the certificate chain is incomplete and cannot pass the verification. The server can use the private key s2_KeyPri to realize asymmetric encryption.
4.3 The client verifies the identity of the server
4.3.1 Verification by a single-level certification body
Brief process
(Assume that the root certificate "ca_Cert" of the root certification authority "CA" has been installed and trusted in the operating system. The same below.)
- The server "S" issues the certificate "s_Cert" to the client "C".
- Client "C" checks the ca_Info in "s_Cert" and finds that it is signed by "CA".
- The client "C" takes out the ca_KeyPub in "ca_Cert", and decrypts the enc_s_Hash in "s_Cert" to get s_Hash.
- The client "C" performs a hash operation on (s_KeyPub + s_Info + ca_Info) in "s_Cert" to obtain the hash value s_Hash_tmp.
- Client "C" judges whether s_Hash and s_Hash_tmp are equal. If both are equal, it proves that "s_Cert" was signed by "ca_Cert".
- The client "C" checks "ca_Cert" and finds that the certificate is the root certificate and has been trusted by the system, and the identity verification is passed.
If "ca_Cert" is not installed in the system, then enc_s_Hash cannot be decrypted, and the authenticity of "s_Cert" cannot be verified. The same below.
4.3.2 Verification by secondary (or above) certification bodies
Brief process
- Server "S2" issues certificates "s2_Cert" and "ca2_Cert" to client "C".
- Client "C" checks the ca2_Info in "s2_Cert" and finds that it is signed by "CA2".
- The client "C" takes out the ca2_KeyPub in "ca2_Cert", and decrypts the enc_s2_Hash in "s2_Cert" to get s2_Hash.
- The client "C" performs a hash operation on (s2_KeyPub + s2_Info + ca2_Info) in "s2_Cert" to obtain the hash value s2_Hash_tmp.
- Client "C" judges whether s2_Hash and s2_Hash_tmp are equal. If both are equal, it proves that "s2_Cert" was signed by "ca2_Cert".
- Client "C" checks the ca_Info in "ca2_Cert" and finds that it is signed by "CA".
- The client "C" takes out the ca_KeyPub in "ca_Cert", and decrypts the enc_ca2_Hash in "ca2_Cert" to get ca2_Hash.
- The client "C" performs a hash operation on (ca2_KeyPub + ca2_Info + ca_Info) in "ca2_Cert" to obtain the hash value ca2_Hash_tmp.
- Client "C" judges whether ca2_Hash and ca2_Hash_tmp are equal. If both are equal, it proves that "ca2_Cert" was signed by "ca_Cert".
- The client "C" checks "ca_Cert" and finds that the certificate is the root certificate and has been trusted by the system, and the identity verification is passed.
The certificate verification process of a three-level or more certification body is similar to this process, which is to verify one by one.
4.4 Encrypting transmitted data
After the identity of the server "S" is approved by the client "C", the server "S" can use s_KeyPri to encrypt outgoing data or decrypt incoming data.
In turn, client "C" can use s_KeyPub to encrypt outgoing data or decrypt incoming data.
Due to the low efficiency of asymmetric encryption, generally use asymmetric encryption to negotiate and exchange a temporary session key, and then use the session key to perform symmetric encryption.
4.5 Certificate verification in reality
In reality, the root certificates of some well-known and trusted certificate authorities are built into the operating system.
The image below is part of the built-in root certificate in macOS 10.13.3.
When the client checks the server certificate, it generally also checks its validity period and whether the certificate is in the certificate revocation list of the certification authority. Certificate revocation lists are generally checked online.
5. Establish a simple certificate system
The following operations can be performed on Linux and macOS systems with the openssl package installed.
We will create a root CA ourselves and then use it directly to sign certificates (i.e. single-level CA).
The entire certificate system uses RSA4096 and SHA512 algorithms by default.
The validity period of the root certification authority is 10 years, and the validity period of the signed certificate is 1 year.
5.1 Create a working directory and enter
Execute the following command:
mkdir ~/test_pki && cd ~/test_pki
5.2 Create a certificate serial number file
Execute the following command:
echo 01 > serial
5.3 Create a certificate database file
Execute the following command:
touch index.txt
5.4 Create openssl configuration file
Execute the following command:
cat << EOF >> test_pki.cnf
Paste the following content directly into the command line window and press Enter.
[ ca ]
default_ca = CA
[ CA ]
dir = .
database = \$dir/index.txt
new_certs_dir = \$dir
certificate = \$dir/ca_cert.pem
serial = \$dir/serial
private_key = \$dir/ca_key.pem
RANDFILE = \$dir/.rand
default_bits = 4096
default_days = 365
default_crl_days = 30
default_md = sha512
unique_subject = no
policy = policy_anything
[ policy_anything ]
countryName = supplied
stateOrProvinceName = supplied
localityName = supplied
organizationName = supplied
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
EOF
5.5 Create a self-signed root certification authority
Execute the following command:
openssl req -x509 -nodes -days 3650 -newkey rsa:4096 -keyout ca_key.pem -out ca_cert.pem -new -sha512
Results of the:
(Please fill in relevant information according to the prompts)
Generating a 4096 bit RSA private key
......................................................................................................................................................................................................................++
...................................................................................................................................................................................++
writing new private key to 'ca_key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []: #国家码
State or Province Name (full name) []: #洲、省名
Locality Name (eg, city) []: #城市名
Organization Name (eg, company) []: #组织名
Organizational Unit Name (eg, section) []: #部门名
Common Name (eg, fully qualified host name) []: #常用名
Email Address []: #邮箱地址
After execution, the root certification authority certificate ca_cert.pem and its private key ca_key.pem will be generated.
5.6 Create user certificate request and certificate private key
Execute the following command:
openssl req -nodes -new -newkey rsa:4096 -keyout cert1_key.pem -out cert1_csr.pem
Similarly, fill in the relevant information according to the above prompts. If A challenge password []: appears, just leave it blank and press Enter.
After execution, the user's certificate request file cert1_csr.pem and its private key cert1_key.pem will be generated.
5.7 Use the private key of the certification authority to sign certificates for users
Execute the following command:
openssl ca -in cert1_csr.pem -out cert1_cert.pem -config test_pki.cnf
operation result:
Using configuration from test_pki.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'CN'
stateOrProvinceName :ASN.1 12:'Guangdong'
localityName :ASN.1 12:'Shantou'
organizationName :ASN.1 12:'yzn_cert'
organizationalUnitName:ASN.1 12:'yzn_cert'
commonName :ASN.1 12:'yzn_cert'
emailAddress :IA5STRING:'yzn_cert'
Certificate is to be certified until Mar 19 05:12:41 2019 GMT (365 days)
Sign the certificate? [y/n]: #输入 y 回车确认签署
1 out of 1 certificate requests certified, commit? [y/n] #输入 y 回车确认签署
Write out database with 1 new entries
Data Base Updated
After execution, the user's certificate file cert1_cert.pem will be generated.
Users can use cert1_cert.pem and cert1_key.pem for authentication and asymmetric encryption.
5.8 View Results
I imported the root certificate ca_cert.pem into the keychain of macOS and set it as trust, and then imported cert1_cert.pem. When viewing the details of the certificate, I can see the following results:
It is obvious that yzn_cert is indeed signed by the certification authority yzn, and the certification authority yzn has been trusted by the system. This is how the chain of trust is established.