Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How does the HTTPS certificate correct the name of the website

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

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

This article is about how the HTTPS certificate corrects the name of the website. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

What problem does HTTPS solve?

HTTPS addresses two issues:

Encrypted transmission ensures that the information between the client and the server is not transmitted in clear text, and ensures the confidentiality of the information.

Identity authentication HTTPS protocol can prove the identity of the server and prevent fake websites from impersonating their own identity.

Symmetric encryption algorithm

This part needs the basis of cryptography, and this paragraph only makes a summary. Symmetric encryption because there is only one key, there is a problem that the key is enumerated, and the encryption security is not high enough.

The common symmetric encryption is DES,3DES,AES.

Because the performance is higher than asymmetric encryption, it is used in HTTPS content encryption. HTTPS uses asymmetric encryption algorithm to do key negotiation to generate key, which is used as symmetric encryption of page content.

Asymmetric encryption algorithm

The common asymmetric encryption algorithms are based on mathematical problems, which are difficult to crack under the current computing power, such as RSA,ECC and so on. Abstract several noun concepts: public key, private key.

Public key and private key can be calculated and verified each other by mathematical algorithm.

Encryption: to generate ciphertext from plaintext computation (such as RSA) by a public key (or private key).

Decryption: the ciphertext is calculated by another key to generate plaintext.

The above concept of encryption and decryption is relative. In daily applications, there are two common scenarios:

The sender encrypts the plaintext through the receiver's public key, and the receiver decrypts it through its own private key.

In scenarios where identity authentication is required, the signature content is signed electronically with its own private key. When verification is needed, the verifier obtains the signer's public key for verification (the public key performs mathematical calculation and decryption of the ciphertext)

Scenarios of asymmetric encryption algorithms-authentication and PKI

Identity authentication

One of the scenarios mentioned in the previous section of asymmetric encryption algorithms is digital signatures, which are methods of identity authentication. Because one's own private key is unknown to others and cannot be copied by others, just like a person's fingerprint, it can represent oneself. But here's the problem? I want someone to communicate with me encrypted with my public key. How does the other person know that this is my public key?

How do you prove I'm me?

Prove that I am me, can only take my ID card to the police station to inquire, and then ask the authorities to issue a "personal certificate", because the relevant departments are credible, so if the authorities say that this is legal, then it can prove that this is me.

So is there an official organization in the electronic world? Yes!

PKI Infrastructure

PKI is the infrastructure of the secure world, and CA institutions are its main members. CA institutions issue certificates to users who apply to prove that "I am me". Users judge whether they need to communicate by verifying the validity of the certificate. Of course, CA is a profit-making organization, enterprises apply for certificates to prove that "I am me" needs to spend a lot of money, of course, there is no shortage of money!

Certificate issuance

Certificate content: certificate = consumer public key + subject information such as company name + CA confirmation signature + fingerprint of the information

The certificate issuance process is roughly as follows:

The applicant generates CSR, fills in the company principal identity information when applying, and generates CSR and private key. The content of CSR is equivalent to public key and identity information.

Select a CA certificate issuing authority, such as Amazon, Globalsign, or a free organization

Submitting a CSR,CA will verify the company's principal information, and then sign the CSR submitted by the applicant to generate a public key that can be deployed by the web server.

Send to applicant

It can be seen that under the issuance of a trusted official CA institution, everyone can think that this is you after seeing this certificate. Clients have built-in root certificates of trusted institutions, so recognize this official organization, which will be described in detail later in the trust chain section.

But here comes the problem again: with more and more HTTPS, what if the authorities are too busy? What about the language communication barriers between countries? As in the real world, official agencies authorize subsidiaries or new head office branches, just as CA institutions add their own branches, giving rise to the concept of intermediate certificates and cross-certificates.

Intermediate certificate: instead of using the private key of the root certificate to sign the applicant's CSR, the intermediate certificate is used to sign the applicant's CSR and issue the certificate.

Cross certificates: mutual signatures between different root certificates to change the starting point of trust

Trust chain and trust anchor

Due to the adoption of intermediate certificates, the whole certificate validity verification process has the concept of trust chain, which means that the client verifies step by step from the server entity certificate. The process of certificate verification at each level is to mathematically verify the signature of the certificate (Subject) by obtaining the public key in the certificate of the certificate issuer (Issuer) (certificate = user public key + subject information such as company name + CA confirmation signature + fingerprint).

The whole level-by-level verification forms a chain of trust. Until the issuer and consumer of a certificate are the same person, this point is the trust anchor, that is, the starting point of the trust chain, which needs to be in the root certificate trust list of the client system or browser. At the end of the whole process, the certificate is trusted.

PS: the trusted root certificate list is different for different browsers (clients). Chrome reads the root certificate list in the system, while FireFox browsers use the trusted root certificate list built-in by their own browsers.

Nginx deployment Certificate and Verification Analysis

Nginx server certificates deploy certificates that use the base64 encoding format. After issuing a certificate through CA, you get a certificate in base64 format, which is deployed on the server together with the private key.

Ssl on; ssl_certificate / opt/soft/ssl/0xfe.com.cn_chain.crt; ssl_certificate_key / opt/soft/ssl/0xfe.com.cn_key.key

0xfe.com.cn_chain.crt is a public key file and 0xfe.com.cn_key.key is a private key file.

Cat / opt/soft/ssl/0xfe.com.cn_chain.crt-BEGIN CERTIFICATE- MIIFpjCCBI6gAwIBAgIQBjLXXyMcU5DDZQ7gshcXdTANBgkqhkiG9w0BAQsFADBy MQswCQYDVQQGEwJDTjElMCMGA1UEChMcVHJ1c3RBc2lhIFRlY2hub2xvZ2llcywg SW5jLjEdMBsGA1UECxMURG9tYWluIFZhbGlkYXRlZCBTU0wxHTAbBgNVBAMTFFRy dXN0QXNpYSBUTFMgUlNBIENBMB4XDTE5MDgxNjAwMDAwMFoXDTIwMDgxNTEyMDAw MFowFjEUMBIGA1UEAxMLMHhmZS5jb20uY24wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDcNNv3Ap4P+LRHrPHPWwuHHZhexQiSCPBAba/kSAcXjFAxaI7o NdyiuBmUhPoGeV3YvIpzV9nsgcar94yDWef/L6Dl5SpVlHYYudgDwa+MKibhPGaL ncW3urpPok3LFngSz63n2xg77Of4gEcOOeMPdzUb9UT6tKrZlPKXRjrGXKbLTwTj AQo4MhvmS8ZddmaRjCTSxhJrZ8n4W2YfgBjITZEqNDDQyhxkS5Sr8/8OQ8wfn38c rrd6FMAgnjnEZZVi3ivd4+XEz+g/DNE/m7+8cmRuHfG8ELXjGnswquJstgllNyUl qumW3dfE9YVIJlQkvEQWFMsw5dzxHidJWTFLAgMBAAGjggKSMIICjjAfBgNVHSME GDAWgBR/05nzoEcOMQBWViKOt8ye3coBijAdBgNVHQ4EFgQUlKhM50RH3AC7pIcy qEoULdttwXUwJwYDVR0RBCAwHoILMHhmZS5jb20uY26CD3d3dy4weGZlLmNvbS5j bjAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC MEwGA1UdIARFMEMwNwYJYIZIAYb9bAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQIBMIGSBggrBgEFBQcBAQSBhTCB gjA0BggrBgEFBQcwAYYoaHR0cDovL3N0YXR1c2UuZGlnaXRhbGNlcnR2YWxpZGF0 aW9uLmNvbTBKBggrBgEFBQcwAoY+aHR0cDovL2NhY2VydHMuZGlnaXRhbGNlcnR2 YWxpZGF0aW9uLmNvbS9UcnVzdEFzaWFUTFNSU0FDQS5jcnQwCQYDVR0TBAIwADCC AQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2AO5Lvbd1zmC64UJpH6vhnmajD35fsHLY gwDEe4l6qP3LAAABbJg76VwAAAQDAEcwRQIhAO5fxTuzbUnz6fna1BAyOzzAxoSw N1xo0lnXrMr2bVBrAiAe2PWp7rCX0eMzO+ZdICzFwQtcULLHSGehHv8CgMqbNQB2 AId1v+dZfPiMQ5lfvfNu/1aNR1Y2/0q1YMG06v9eoIMPAAABbJg76eAAAAQDAEcw RQIhAItx6WPv2a2nKIBRVDuvns5D4fElzlPAHMVM9gKDA4HcAiB/D+n/UCFAH5YY L6r+vLKgLRJCfq5Vw0kaLWA+P3a5RDANBgkqhkiG9w0BAQsFAAOCAQEAllOZKfyY hoyC5/FRnEhoY/6v/kbzPlVsgZvUVtk3IDnyo7GOaUUigQaLSmL0oWTnwmMOweb7 UhP1TL+RCYcw2fc39l4FIaOKjMmSaPLZw2Fm9Lk/ie5BZ3pLD5A3exz4nMgVjJB6 XC0ZiBgTsCOl3K3vFefL4x4ewoR0KwN5fTwkxKKT7XUCMTcIOMgWX2ubUXhjM2cy c9lRPTy2joO4za9AS6sR5JExLY/kJ3dR7t99gko5MnJZINcPD8WIUySw5oQZA22Y OhFVBGiERcH+oD6TNoZuqu2pSfrAIFT3dWpb1bGgiCxblsN2yH1REXmnTx3bmuy2 UAXfwUlUhtmRbw==-END CERTIFICATE--BEGIN CERTIFICATE- MIIErjCCA5agAwIBAgIQBYAmfwbylVM0jhwYWl7uLjANBgkqhkiG9w0BAQsFADBh MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD QTAeFw0xNzEyMDgxMjI4MjZaFw0yNzEyMDgxMjI4MjZaMHIxCzAJBgNVBAYTAkNO MSUwIwYDVQQKExxUcnVzdEFzaWEgVGVjaG5vbG9naWVzLCBJbmMuMR0wGwYDVQQL ExREb21haW4gVmFsaWRhdGVkIFNTTDEdMBsGA1UEAxMUVHJ1c3RBc2lhIFRMUyBS U0EgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgWa9X+ph+wAm8 Yh2Fk1MjKbQ5QwBOOKVaZR/OfCh+F6f93u7vZHGcUU/lvVGgUQnbzJhR1UV2epJa e+m7cxnXIKdD0/VS9btAgwJszGFvwoqXeaCqFoP71wPmXjjUwLT70+qvX4hdyYfO JcjeTz5QKtg8zQwxaK9x4JT9CoOmoVdVhEBAiD3DwR5fFgOHDwwGxdJWVBvktnoA zjdTLXDdbSVC5jZ0u8oq9BiTDv7jAlsB5F8aZgvSZDOQeFrwaOTbKWSEInEhnchK ZTD1dz6aBlk1xGEI5PZWAnVAba/ofH33ktymaTDsE6xRDnW97pDkimCRak6CEbfe 3dXw6OV5AgMBAAGjggFPMIIBSzAdBgNVHQ4EFgQUf9OZ86BHDjEAVlYijrfMnt3K AYowHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUwDgYDVR0PAQH/BAQD AgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjASBgNVHRMBAf8ECDAG AQH/AgEAMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Au ZGlnaWNlcnQuY29tMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jcmwzLmRpZ2lj ZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RDQS5jcmwwTAYDVR0gBEUwQzA3Bglg hkgBhv1sAQIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzAIBgZngQwBAgEwDQYJKoZIhvcNAQELBQADggEBAK3dVOj5dlv4MzK2i233 lDYvyJ3slFY2X2HKTYGte8nbK6i5/fsDImMYihAkp6VaNY/en8WZ5qcrQPVLuJrJ DSXT04NnMeZOQDUoj/NHAmdfCBB/h2bZ5OGK6Sf1h6Yx/5wR4f3TUoPgGlnU7EuP ISLNdMRiDrXntcImDAiRvkh6GJuH4YCVE6XEntqaNIgGkRwxKSgnU3Id3iuFbW9F UQ9Qqtb1GX91AJ7i4153TikGgYCdwYkBURD8gSVe8OAco6IfZOYt/TEwii1Ivi1C qnuUlWpsF1LdQNIdfbW3TSe0BhQa7ifbVIfvPWHYOu3rkg1ZeMo6XRU9B4n5VyJY RmE=-END CERTIFICATE-cat / opt/soft/ssl/0xfe.com.cn_key.key-BEGIN RSA PRIVATE KEY- ellipsis-END RSA PRIVATE KEY-

In the public key file, there is a certificate between-BEGIN CERTIFICATE- and-END CERTIFICATE-. The first must be a domain name entity certificate, followed by an intermediate certificate or cross-certificate. After testing, the first domain name entity certificate order must be placed first, and subsequent intermediate certificates can be exchanged with each other. It is usually recommended to add intermediate certificates to the last. CER online reading tool

Input the first paragraph above into the online reading tool, and the output is as follows:

CER decoding result: common name: 0xfe.com.cn available domain name: DNS:0xfe.com.cn, DNS:www.0xfe.com.cn valid time period: 2019-08-16-2020-08-15 Serial number: 8239351073242680476627775209099171701 issuer: TrustAsia TLS RSA CA validity period: 2020-08-15 20:00:00

Input the second paragraph above into the online reading tool, and the output is as follows:

CER decoding result: common name: TrustAsia TLS RSA CA company organization name: TrustAsia Technologies, Inc. Valid period: 2017-12-08-2027-12-08 Serial number: 7311534772508790650765434802415791662 issuer: DigiCert Global Root CA validity period: 2027-12-08 20:28:26

As can be seen above, the base64 certificates at both ends correspond to domain name entity certificates and intermediate certificates respectively.

The above certificate trust chain is: 0xfe.com.cn

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report