Shulou(Shulou.com)06/03 Report--

Let's start with literacy.

CA Certificate https://coding.net/u/aminglinux/p/nginx/git/blob/master/ssl/ca.md

Let's start with an example.

Xiaohua of Company A was assigned to Company B to do business. How can Company B trust Xiaohua to be sent by Company A?

General letter of introduction

In order to make Company B trust Xiaohua, Company A specially issued a letter of introduction to Xiaohua, detailing Xiaohua's characteristics and the purpose of Xiaohua's visit.

And declare that this Xiaohua is indeed sent by Company A. in addition, there should be an official seal of Company A.

In this way, after the receptionist of Company B gets the letter of introduction, through the contents of the letter and the official seal of Company A, we can judge that Xiaohua is indeed an employee sent by Company A.

What if the official seal of the company is a fake? After all, it is too easy to forge official seals, so there will be problems. Let's just think that things like official seals are hard to forge.

Or the story won't go on.

Introduction of third-party intermediary companies

Okay, let's get back to what we were talking about. If there are many companies that do business with Company B and the official seals of each company are different, then the receptionist of Company B should know how to distinguish between official seals.

It's very troublesome. So, some intermediary company, C, discovered this business opportunity. Company C has set up a special business of "agency seal".

So in the future, when the salesman of Company A goes to Company B, he needs to bring two letters of introduction:

Letter of introduction 1 (contains the official seal of Company C and the official seal of Company A. And specifically note: company C trusts Company A. )

Letter of introduction 2 (only contains the official seal of Company A, and then write: Mr. / Ms. xxx is coming to your company for business, please let us know. )

Doesn't that add to the trouble? What's the advantage?

The main advantage is that for the receptionist of the reception company, she does not need to remember what the official seal of each company looks like, she only needs to remember the official seal of intermediary company C.

After she got two letters of introduction, she first verified and confirmed the C seal of the letter of introduction 1, and then compared the two A seals of "letter of introduction 1" and "letter of introduction 2" for consistency.

If it is the same, it can prove that the "letter of introduction 2" can be trusted.

Interpretation of related professional terms

The following is the example above to explain the relevant nouns.

What is a certificate?

Certificate is also called "digital certificate" or "public key certificate" in foreign languages.

It is used to prove that something is really something. Generally speaking, a certificate is like an official seal in an example. Through the official seal

It can be proved that the letter of introduction was indeed sent by the corresponding company.

In theory, everyone can find a certificate tool and make their own certificate. So how to prevent the bad guys from making their own certificates?

What is CA?

CA is the abbreviation of "Certificate Authority", also known as "Certificate Authority". It is the third party responsible for managing and issuing certificates.

Just like the intermediary C company in the example.

Generally speaking, CA must be trusted and recognized by all industries and all members of the public. Therefore, it must have sufficient authority.

For example, both An and B companies must trust C Company before they will find C Company as the intermediary of the official seal.

What is a CA certificate?

A CA certificate, as its name implies, is a certificate issued by CA.

As mentioned earlier, everyone can find tools to make certificates. But the certificate made by a broken child of yours is useless.

Because you are not an authoritative CA authority, your own certificate is not authoritative.

This is like in the above example, some bad guy carved an official seal and stamped it on the letter of introduction. But when others look at it,

If it is not the official seal of a trusted intermediary company, it will be ignored.

What is the trust relationship between certificates?

In the opening example, it is mentioned that after the introduction of an intermediary, the salesman has to bring two letters of introduction at the same time. The first letter of introduction contains two official seals and indicates that official seal C trusts official seal A.

The trust relationship between certificates is similar to this one. Is to use one certificate to prove that another certificate is authentic.

What is a certificate trust chain?

In fact, the trust relationship between certificates can be nested.

For example, C trusts A1, A 1, A 2, A 2, A 3. This is called a chain of trust called certificates.

As long as you trust the first certificate on the chain, the subsequent certificates can be trusted.

What is a root certificate?

The foreign language of the root certificate is called "root certificate". In order to explain what the root certificate is all about, let's take a look at a slightly more complicated example.

Suppose the C certificate trusts An and B; then A trusts A1 and A2. B trusts B1 and B2. Then a tree relationship (an upside-down tree) is formed between them.

The certificate at the top root of the tree is the "root certificate". Except for the root certificate, all other certificates rely on the certificate at the next higher level to prove themselves.

Then who will prove that the "root certificate" is reliable?

In fact, the root certificate itself proves that it is reliable (or in other words, the root certificate does not need to be proved).

Smart students should realize by now: the root certificate is the foundation of the security of the whole certificate system.

Therefore, if there is a problem with the root certificate in a certificate system (no longer trusted), then all other certificates trusted by the root certificate will no longer be trusted.

What's the use of a certificate?

CA certificates can serve many purposes, listing only a few that are commonly used.

Verify the trustworthiness of the website (for HTTPS) usually, if we visit some sensitive web pages (such as the page where the user logs in), the protocol will use HTTPS instead of HTTP, because the HTTP protocol is plaintext, and once a bad person is spying on your network communication, he or she can see the content of the network communication (such as your password, bank account, etc.). And HTTPS is an encrypted protocol that ensures that bad guys can't peep during your transmission. However, do not think that with encryption in HTTPS protocol, you can rest easy. Suppose there is a bad guy who makes a fake online banking site and then tricks you into going to this site. Suppose you are relatively simple, inadvertently, you will enter your account number and password. Then the villain's plot succeeds. In order to prevent bad guys from doing this, HTTPS protocol not only has an encryption mechanism, but also has a certificate mechanism. Use a certificate to ensure that a site is indeed a site. After you have a certificate, when your browser visits a HTTPS website, it will verify the CA certificate on that site (similar to the official seal for verifying a letter of introduction). If the browser finds that there is no problem with the certificate (the certificate is trusted by a root certificate, the domain name bound to the certificate is the same as the domain name of the website, and the certificate does not expire), then the page opens directly, otherwise, the browser will give you a warning. tell you that there is a problem with the website's certificate and whether to continue to visit the site. Verify that the file is trusted

SSL principle

Https://coding.net/u/aminglinux/p/nginx/git/blob/master/ssl/ssl.md

SSL principle

If you want to understand the principle of SSL authentication, you must first have some understanding of CA, which plays a very important role in the process of SSL authentication.

To put it bluntly, CA is an organization that issues certificates for network servers. The internationally renowned CA institutions are VeriSign and Symantec, and the domestic ones are GlobalSign.

Each CA has its own root certificate, which is used to verify the server-side certificates it has issued.

If the server provider wants to apply for a certificate for its own server, it needs to apply to the CA institution.

The server provides its own identity information to the CA. After the CA identifies the applicant, it assigns a public key to it.

And CA binds the public key to the server identity and signs it, which forms a server-side certificate.

If a user wants to verify the authenticity of another certificate, he verifies the signature on that certificate with the public key of CA, and once verified, the certificate is considered valid.

The certificate is actually the authentication of the user's public key issued by the Certificate and Visa Authority (CA).

The contents of the certificate include: the information of the electronic visa authority, the public key user information, the public key, the signature and validity of the authority, and so on.

At present, the format and verification methods of certificates generally follow the X.509 international standard.

Process of applying for certificate

First you need to have a CA root certificate, and then use the CA root certificate to sign the user certificate.

The user applies for a certificate:

Mr. A uses the private key to generate the certificate request (the certificate request should contain the public key information) to sign the certificate using the CA root certificate of the certificate server.

In this way, you end up with a certificate issued by the CA root certificate, which contains only the public key and the private key is in the hands of the user.

SSL workflow (one-way)

1. Client say hello server

two。 The server sends the certificate, public key, etc., to the client

3. Client CA validates the certificate and continues successfully, but does not pop up the selection page successfully.

4. The client informs the server of the encryption algorithm supported

5. The server chooses the highest-level encryption algorithm to notify the client in clear text

6. The client generates a random symmetric key key, which is encrypted and sent to the server using the server public key

7. The server uses the private key to decrypt and obtain the symmetric key key

8. The subsequent client and server use the key key for encrypted communication

SSL Workflow (Bidirectional)

One-way authentication, only that the client needs to verify that the server certificate is correct, while the server does not verify that the client certificate is correct. Two-way authentication means that the client verifies the server-side certificate, and the server also needs to verify the client-side certificate through the CA public key certificate.

The process of two-way verification:

1. Client say hello server

two。 The server sends the certificate, public key, etc., to the client

3. Client CA validates the certificate and continues successfully, but does not pop up the selection page successfully.

4. The client sends its certificate and public key to the server

5. The server verifies the client certificate, if not directly disconnected

6. The client informs the server of the encryption algorithm supported

7. The server selects the highest level encryption algorithm and sends it to the client after it is encrypted using the client public key.

8. After receiving it, the client uses the private key to decrypt and generates the random symmetric key key, which is encrypted and sent to the server using the server public key.

9. The server uses the private key to decrypt and obtain the symmetric key key

10. The subsequent client and server use the key key for encrypted communication

Generate SSL key pairs on Linux machines

Https://coding.net/u/aminglinux/p/nginx/git/blob/master/ssl/key.md

Generate CA root certificate

Mkdir / etc/pki/ca_test / / create a directory for CA certificates cd / etc/pki/ca_testmkdir root server client newcerts / / create several related directories echo 01 > serial / / define the serial number as 01echo 01 > crlnumber / / define the crl number as 01touch index.txt / / create index.txtcd.. vi tls/openssl.cnf / / change the configuration file

Change default_ca = CA_default to default_ca = CA_test

Change [CA_default] to [CA_test]

Change dir = / etc/pki/CA to dir = / etc/pki/ca_test

Change certificate = $dir/cacert.pem to certificate = $dir/root/ca.crt

Change private_key = $dir/private/cakey.pe to private_key = $dir/root/ca.key

Openssl genrsa-out / etc/pki/ca_test/root/ca.key / / generate the private key openssl req-new-key / etc/pki/ca_test/root/ca.key-out / etc/pki/ca_test/root/ca.csr

/ / when the request file is generated, we will be asked to fill in some indicators. Note here: if you fill in the corresponding indicators in this step

Such as Country Name, State or Province Name, hostname.

Openssl x509-req-days 3650-in / etc/pki/ca_test/root/ca.csr-signkey / etc/pki/ca_test/root/ca.key-out / etc/pki/ca_test/root/ca.crt

Generate crt file

Generate server-side certificate

Cd / etc/pki/ca_test/serveropenssl genrsa-out server.key / / generate private key file openssl req-new-key server.key-out server.csr// generate certificate request file, enter information to be consistent with Organization Name in ca.csr openssl ca-in server.csr-cert / etc/pki/ca_test/root/ca.crt-keyfile / etc/pki/ca_test/root/ca.key-out server.crt-days 3650

/ / sign server.csr with the root certificate, and finally generate the public key file server.crt. In this step, you need to enter y in two places.

Sign the certificate? [y/n]: y

1 out of 1 certificate requests certified, commit? [y/n] y

Generate client certificate

If you do the two-way authentication of ssl, you also need to generate a certificate for the client. The steps are basically the same as above.

Cd / etc/pki/ca_test/clientopenssl genrsa-out client.key / / generate private key file openssl req-new-key client.key-out client.csr / / generate request file. Enter information that needs to be consistent with Organization Name in ca.csr openssl ca-in client.csr-cert / etc/pki/ca_test/root/ca.crt-keyfile / etc/pki/ca_test/root/ca.key-out client.crt-days 3650

/ / sign client.csr to generate client.crt. If this step occurs

Failed to update database

TXT_DB error number 2

To perform:

Sed-I 's/unique_subject = yes/unique_subject = no/' / etc/pki/ca_test/index.txt.attr

After execution, repeat the signature client.csr operation again

As above, the results are as follows

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.