HTTPS and TLS certificate chain verification

Some time ago, I read x. 509 certificate structure and TLS certificate verification chain related knowledge, and now I feel that I have a basic understanding of it. I want to write an article to record my learning experience.

In practice, the scenario involving X.509 certificate structure and TLS certificate verification chain is HTTPS network request. This article starts from THE HTTPS network request, and describes the process of HTTPS key negotiation, TLS certificate verification, and TLS certificate chain verification.

HTTPS

Introduction to the HTTPS.

The TLS handshake

This section describes the HTTPS key negotiation process.

TLS Certificate verification
TLS certificate chain verification

HTTPS introduction

Secure Hypertext Transfer Protocol (HTTPS) is a Transfer Protocol used for Secure communication over a computer network. HTTPS uses SSL/TLS to encrypt packets and communicate over HTTP. The main purpose of its design is to provide identity authentication to the website server and protect the privacy and integrity of the data exchanged.

TLS/SSL

TLS and SSL refer to the same concept to some extent:

SSLSecure Socket Layer was developed by the browser in 1994NetscapeNetscape Communications pioneered research and development to provide security support for data communications, developing the first versions of SSL 1.0, SSL 2.0, and SSL 3.0.
TLSTransport LayerSecurity (SSL) was developed from 3.1 in 1999IETFInternet Engineering Task Force (Internet Engineering Task Force) was standardized and renamed to TLS 1.0, TLS 1.1 and TLS 1.2.

SSL3.0 and TLS1.0 are rarely used due to security vulnerabilities. TLS 1.3 is still in the draft stage due to major changes. Currently, TLS 1.1 and TLS 1.2 are widely used.

As shown in the figure above, TLS/SSL is a layer of security protocol between TCP and HTTP.

HTTP

HyperText Transfer Protocol (HTTP) HyperText Transfer Protocol. HTTP is a standard for requests and responses between clients (users) and servers. It was originally designed to provide a way to publish and receive HTML pages.

Note: the Http protocol is not this paper, interested students can refer to the article: Http protocol: blog.csdn.net/xiaxl/artic…

2. SSL/TLS handshake

The SSL/TLS handshake process can be summarized as follows: Use asymmetric encryption to transfer the key, and then use symmetric encryption to transfer data. The process of SSL/TLS handshake and key negotiation can be roughly divided into the following steps:

1, the Client Hello

Client — >Server The Client sends the Client Hello message to the Server.

2, Server Hello

Server — >Client The Server sends the Server Hello message to the Client.

3, Certificate

Server — >Client The Server delivers the public key certificate.

4. Server Key Exchange

Server — >Client The Server issues additional data for the key exchange.

5, Server Hello Done

Server — >Client The Server handshake information is sent.

6. Verify the validity of certificates

The Client verifies the validity of the public key certificate delivered by the Server.

7. Negotiate secret keys

Client — >Server Negotiates the encryption key enc_key used for communication between the Client and Server.

8. Change Cipher Spec Protocol

Server — >Client The Server tells the Client to use the negotiated secret key enc_key for encrypted communication with the algorithm.

Encrypted Handshake Message

Server — >Client The first encrypted message sent by the Server using enc_key encryption.

10 and Application Data

Client — >Server SSL/TLS The handshake is complete, and all subsequent communications are encrypted with the enc_key.

SSL/TLSThe flow chart of handshake and secret key negotiation is as follows:

Here toThe clienttoBaidu's home pageinitiateHttpsRequest, for exampleWireshark caughtEach link of SSL/TLS handshake is introduced, and the packet capture diagram is shown as follows:

2.1, the Client Hello

Client Hello (Client — >Server) : The Client sends a Client Hello message to the Server. The message contains the TSL version information of the client, the random number of the secret key, the candidate list of the encryption suite, the candidate list of the compression algorithm, and the extended fields. The related information is captured as follows:

The fields are described as follows:

Version: indicates the highest TSL Version, in descending order. SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2.
Random: indicates a Random numberrandom_CUsed for subsequent key negotiation;
Session ID: If yes or no, the client can restore a Session by sending the ID of the previous Session.
Cipher Suite: indicates a list of password algorithms supported by the client for the server to select.
Compression Methods: a list of Compression algorithms supported by the client for subsequent information Compression and transmission;
Extensions: Extension field;

2.2, Server Hello

Server Hello (Server — >Client) : The Server sends a Server Hello message to the Client. The message contains the TSL protocol version selected by the server, encryption suite selected, compression algorithm selected, random number generated by the server, etc. Related information is captured as follows:

Version: indicates the Version selected by the server.
Random: indicates a Random numberrandom_SUsed for subsequent key negotiation;
Session ID: If yes or no, the client can restore a Session by sending the ID of the previous Session.
Cipher Suite: key algorithm selected by the server.
Compression Methods: Compression algorithm selected by the server;

Note: At this point both the client and server have two random numbers (random_C+ random_S), which will be used in the subsequent generation of symmetric keys.

2.3, Certificate

Certificate (Server — >Client) : The Server issues a public key Certificate to the Client. Packet capture information is as follows:

Certificate:Public key certificate of the server;

Note: The detailed structure of the public key Certificate is described in the following examples.

2.4. Server Key Exchange

Server Key Exchange (Server — >Client) : The purpose of this message is to carry additional data for the Key Exchange.

The message content varies for different negotiation algorithm suites:

For THE SSL handshake using the DHE/ECDHE asymmetric key negotiation algorithm, the server sends the DH parameters it uses.
The RSA algorithm does not continue the handshake process (DH and ECDH do not send the server key exchange).

2.5, Server Hello Done

Server Hello Done (Server — >Client) : notifies the Client that the Server has sent all handshake messages.

2.6 Certificate verification

After obtaining the public key certificate from the server, the client verifies the validity of the certificate. The verification content is as follows:

The credibility of the certificate chain;
Whether the certificate is revoked;
Validity period of the certificate;
Certificate domain name verification, check whether the certificate domain name matches the current access domain name;

Note: The certificate verification process will be described in detail in the following sections

2.7. Negotiate and encrypt the secret key

Client — >Server: This step consists of three steps. It is mainly to negotiate the encryption key for the communication between the Client and the Server.

Client Key Exchange

After the certificate is verified, the client generates a random pre-master number. Enc_key {enc_key=Fuc(random_C, random_S, pre-master)} Send the pre-master and enc_key to the server using the certificate public key encryption (asymmetric encryption algorithm).

Change Cipher Spec Protocol

The client notifies the server of the encrypted communication using the negotiated key enc_key and encryption algorithm.

Encrypted Handshake Message

Client: The client generates a summary of all previous handshake data (including receiving and sending). It is then encrypted with the secret key enc_key (symmetric encryption algorithm) and sent to the corresponding server. Server: After receiving the message, the server uses the secret key enc_key to decrypt the abstract information of the client. Then use the same algorithm with the client to generate the server side summary information, and finally compare the two summary information is the same, then the verification passes.

2.8. Change Cipher Spec Protocol

Change Cipher Spec Protocol (Server — >Client) : The Server also sends Change Cipher Spec Protocol to inform the Client that the encryption key enc_key is used for subsequent communication with the algorithm.

2.9. Encrypted Handshake Message

Encrypted Handshake Message (Server — >Client) : The Server will encrypt the Message summary generated during the Handshake process with the secret key enc_key, which is the first Encrypted Message sent by the Server. Client: After receiving, the client will decrypt it with the secret key enc_key. If the secret key can be solved, it indicates that the negotiated secret key is consistent.

2.10, Application Data (Client — >Server)

Application Data Client — >Server) : Both parties have securely negotiated the same secret key enc_key. All application-layer Data will be encrypted with this secret key and then transmitted reliably through TCP.

2.11 summarize

SSL/TLS handshake negotiation: Use asymmetric encryption to transfer keys, and then use the keys for symmetric encryption to transfer data.

Iii. Certificate verification

This section describes the certificate verification process mentioned in 2.6 Certificate Verification.

1. Example of x. 509 digital certificate structure
2. How does the client verify the public key certificate delivered by the server?

3.1. X.509 Digital Certificates

Before learning about the principle of certificate verification, learn about the structure of X.509 certificates.

X.509 is the standard format for public key certificates in cryptography. Currently, X.509 certificates are used in many network protocols, including TLS/SSL. A concrete X.509 V3 digital certificate structure looks like this:

// X.509 digital Certificate Certificate // Version Number Version Number // Serial Number Serial Number // Certificate Signature Algorithm ID // Certificate Issuer Name // Certificate Validity period // Certificate Subject Name // Certificate Subject Public Key information Subject Public Key Info // Certificate Public Key Algorithm Public Key Algorithm // Certificate Public Key Subject Public Key // Issuer Unique Identifier (optional) // Subject Unique Identifier (optional) // Extensions (optional) // Certificate Signature Algorithm // Certificate Signature value Certificate SignatureCopy the code

Here tobaidutheThe Tls certificateFor example:

Certificate: Data: Version: 3 (0x2) Serial Number: 72:58:78:36:6e:9f:56:e8:1d:41:88:48 Signature Algorithm: sha256WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 Validity Not Before: Apr 2 07:04:58 2020 GMT Not After : Jul 26 05:31:02 2021 GMT Subject: C=CN, ST=beijing, L=beijing, OU=service operation department, O=Beijing Baidu Netcom Science Technology Co., Ltd, CN=baidu.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c1:a9:b0:ae:47:1a:d2:57:eb:1d:15:1f:6e:5c: b2:e4:f8:0b:20:db:ea:00:df:29:ff:a4:6b:89:26: 4b:9f:23:2f:ec:57:b0:8a:b8:46:40:2a:7e:bc:dc: 5a:45:97:4f:ad:41:0e:bc:20:86:4b:0c:5d:55:21: 47:e2:31:3c:57:a7:ec:99:47:eb:47:0d:72:d7:c8: 16:54:75:ef:d3:45:11:0f:4b:ce:60:7a:46:5c:28: 74:ae:8e:1b:be:d8:70:66:7b:a8:93:49:28:d2:a3: 76:94:55:de:7c:27:f2:0f:f7:98:0c:ad:86:da:c6: ae:fd:9f:f0:d9:81:32:9a:97:e3:21:ee:04:92:96: e4:78:11:e5:c4:10:0e:10:31:7a:4a:97:a0:eb:c7: 9b:c4:da:89:37:a9:c3:37:d7:56:b1:7f:52:c7:d9: 26:0a:d6:af:38:16:b1:6d:fb:73:79:b1:68:79:03: 90:eb:88:7b:8c:48:91:98:51:a5:07:94:86:a5:78: 46:79:8f:58:9b:e9:35:59:a7:f1:7b:57:31:0a:90: cf:24:ce:0d:24:e7:92:b2:6a:e9:e6:96:37:0a:b8: 7c:87:2f:74:d2:5c:e8:4b:0a:5f:66:18:a7:41:86: cf:26:a6:08:8e:a5:49:17:92:53:b3:91:a5:cf:53: b0:31 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment Authority Information Access: CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2 X509v3 Certificate Policies: the Policy: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ Policy: 2.23.140.1.2.2 X509v3 Basic Constraints: CA:FALSE X509v3 CRL Distribution Points: Full Name: URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl X509v3 Subject Alternative Name: DNS:baidu.com, DNS:baifubao.com, DNS:www.baidu.cn, DNS:www.baidu.com.cn, DNS:mct.y.nuomi.com, DNS:apollo.auto, DNS:dwz.cn, DNS:*.baidu.com, DNS:*.baifubao.com, DNS:*.baidustatic.com, DNS:*.bdstatic.com, DNS:*.bdimg.com, DNS:*.hao123.com, DNS:*.nuomi.com, DNS:*.chuanke.com, DNS:*.trustgo.com, DNS:*.bce.baidu.com, DNS:*.eyun.baidu.com, DNS:*.map.baidu.com, DNS:*.mbd.baidu.com, DNS:*.fanyi.baidu.com, DNS:*.baidubce.com, DNS:*.mipcdn.com, DNS:*.news.baidu.com, DNS:*.baidupcs.com, DNS:*.aipage.com, DNS:*.aipage.cn, DNS:*.bcehost.com, DNS:*.safe.baidu.com, DNS:*.im.baidu.com, DNS:*.baiducontent.com, DNS:*.dlnel.com, DNS:*.dlnel.org, DNS:*.dueros.baidu.com, DNS:*.su.baidu.com, DNS:*.91.com, DNS:*.hao123.baidu.com, DNS:*.apollo.auto, DNS:*.xueshu.baidu.com, DNS:*.bj.baidubce.com, DNS:*.gz.baidubce.com, DNS:*.smartapps.cn, DNS:*.bdtjrcv.com, DNS:*.hao222.com, DNS:*.haokan.com, DNS:*.pae.baidu.com, DNS:*.vd.bdstatic.com, DNS:click.hm.baidu.com, DNS:log.hm.baidu.com, DNS:cm.pos.baidu.com, DNS:wn.pos.baidu.com, DNS:update.pan.baidu.com X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Authority Key Identifier: keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C X509v3 Subject Key Identifier: ......Copy the code

3.2 Certificate verification

The client authenticates the certificate issued by the server in the following ways:

1. Check whether the certificate is validA trustedtheCA rootTo award by an issuing authority;
2. Check whether the certificate is in the superior certificateRevocation list;
3. Verify certificatesIs late;
4. Verify certificatesThe domain nameWhether or notconsistent.

3.2.1 Credibility of the certificate

Verify whether the certificate is trusted: Verify whether the certificate is issued by a trusted CA root certification authority.

To ensure that the public key obtained by the client is not tampered with, you need to introduce an authoritative third-party CA. The CA is responsible for verifying public key owner information, issuing certificates (signing public keys on the server), and providing certificate verification services for users.

Basic principles of CA certificate issuance:

The service sideGenerate a pair ofThe public key,The private key.
The service sideProvides its own public key toCA institution.
CA institutionverifyServer Public keyOwner Information:

Verify the authenticity of the information provided by the applicant, such as whether the organization exists, whether the enterprise is legal, whether the ownership of the domain name, etc.

CA institutionIssue certificate:

The CA organization calculates the public key summary information of the server and encrypts the summary information using the CA organization private key (a CA organization has a public key and a private key). The encrypted server public key containing the encrypted summary is a certificate issued by the CA.

The basic principle for the client to verify the server public key is as follows:

The clientObtain the serverThe public key:

The public key of the server is delivered to the requesting client during the TLS handshake.

The clientUse the one stored locallyThe public key of the CAforServer Public keyIn the correspondingIn this paper, informationDecrypt it and get itServer Public keytheSummary Information A;
The clientAccording to theServer Public keyAbstract calculation, getSummary Information B;
contrastIn this paper, informationA and BIf yes, the certificate is verified.

3.2.2 Certificate revocation

The CA authority can issue certificates, and there is also a mechanism to invalidate previously issued certificates. If the private key of the certificate applicant is lost or the certificate application is invalid, the CA must discard the certificate.

There are two types of mechanisms: CRL and OCSP.

CRL (Certificate Revocation List)

Certificate Revocation list: a separate file that contains the serial numbers and revocation dates of certificates that have been revoked by the CA. A certificate usually contains a URL CRL Distribution Point, which notifies the user where to download the CORRESPONDING CRL to verify whether the certificate is revoked. The advantage of this revocation mode is that the certificate does not need to be updated frequently, but the certificate cannot be revoked in time, because the CRL update usually takes several days, during which great losses may have been caused.

Online Certificate Status Protocol (OCSP)

Certificate Status Online query protocol: a method for checking whether a certificate is revoked in real time. The requester sends information about the certificate and requests a query, and the server returns to normal, revoked, or unknown. The certificate usually contains an OCSP URL address, which requires the query server to have good performance. Some oR most self-signed cas (root certificates) do not provide the CRL or OCSP address, which can be very troublesome to revoke the certificate.

3.2.3 The certificate expires

Check whether the Validity period of the certificate has expired: Check whether the Validity period field in the certificate has expired.

3.2.4 Certificate domain name

Certificate domain name verification: Verifies that the certificate domain name matches the current access domain name.

For example: whether the requested domain name www.baidu.com matches the domain name listed under the DNS label in the certificate file;

An incorrect way of writing:

In Android software development, we often encounter the following code to ignore the domain name authentication of the certificate, which is actually an unsafe way to write:

// For self-signed certificates, use the following code to ignore the certificate's domain name validation
HostnameVerifier hostnameVerifier = new HostnameVerifier() {
    @Override
    public boolean verify(String urlHostName, SSLSession session) {
		// Ignore domain name validation of the certificate
        return true; }};Copy the code

Iv. Certificate chain verification

The previous section describes the certificate verification scenarios. The Ca is the issuing authority for server certificates. In actual certificate application, the number of authoritative CA organizations is small. If all server certificates are applied to authoritative CA organizations, the workload of CA organizations is very heavy. Therefore, the CA authority manages certificate requests by authorizing secondary authorities, which can also issue server certificates.

4.1 Certificate chain verification

Certificate Issue:

Root certificateCA agencies use their ownThe private keyrightIn the middle of the certificateTo sign and authorizeintermediariesCertificate;
intermediariesUse one’s ownThe private keyrightServer certificateTo sign and authorizeServer certificate.

Certificate verification:

The clientthroughServer certificate 中Issuing Agency InformationTo obtain theIntermediate certificate Public Key; usingIntermediate certificate Public KeyforServer certificateFor signature verification.

A. The public key of the intermediate certificate decrypts the server signature to obtain the summary information of the certificate; B. Summary algorithm calculates the summary information of the server certificate; C. Then compare the two summaries.

The clientthroughIn the middle of the certificateIn theIssuing Agency InformationThe client is found locallyRoot certificate Public Key; usingRoot certificate Public KeyforIn the middle of the certificateFor signature verification.

4.2 How to obtain the Intermediate Certificate?

Here you may have a question, the root certificate is built in the terminal device or browser, then how to obtain the intermediate certificate?

Here, baidu’s Tls certificate is used as an example. The public key of baidu server certificate issuer (intermediate public key) can be obtained from the URI shown in the following figure:

Five, the reference

Standard: TSL tools.ietf.org/html/rfc524…

X. 509 standard: datatracker.ietf.org/doc/html/rf…

SSL/TSL principle: www.cnblogs.com/chenjingqua…

The TLS/SSL handshake: blog.csdn.net/hherima/art…

HTTPS and TLS certificate chain verification

HTTPS and TLS certificate chain verification

HTTPS introduction

TLS/SSL

HTTP

2. SSL/TLS handshake

2.1, the Client Hello

2.2, Server Hello

2.3, Certificate

2.4. Server Key Exchange

2.5, Server Hello Done

2.6 Certificate verification

2.7. Negotiate and encrypt the secret key

2.8. Change Cipher Spec Protocol

2.9. Encrypted Handshake Message

2.10, Application Data (Client — >Server)

2.11 summarize

Iii. Certificate verification

3.1. X.509 Digital Certificates

3.2 Certificate verification

3.2.1 Credibility of the certificate

3.2.2 Certificate revocation

3.2.3 The certificate expires

3.2.4 Certificate domain name

Iv. Certificate chain verification

4.1 Certificate chain verification

4.2 How to obtain the Intermediate Certificate?

Five, the reference

Related Posts

20. Valid parentheses | Swipe the question and punch in

A summary of several representative automated testing tools

Readhub Code Free Technology — Industry news integration