Look TLS certificate from sslyze bit by bit

Throughout the moment, https has gone deep streets, become an integral part of the network of life. Mentioned https, we had to think of TLS (SSL), which referred to the TLS, we have to mention a people thing unpredictable: TLS certificate.

On the principle of the certificate, will not start here, in short, is the server so that clients rest assured, I'm you're looking for that, you do not believe that so and so look to open a letter of introduction.

In everyday use or development, sometimes we will inevitably need to analyze the diagnostic TLS certificate, and certificate of analysis of it, there is a very good open-source tool that you should not miss: sslyze

This article is intended to be a brief outline with everyone sslyze TLS certificates by using the analysis result of the diagnosis, so familiar under the certificate diagnosis of bits and pieces of knowledge. Certificate-related knowledge relatively complex, to say a little bit by bit shabby, at best, only some fur, be initiate it. Let us tentatively thinking along the sslyze, walking Liaoba.

1. Installation and Use

sslyze is a python project, installation is relatively easy:

pip install --upgrade sslyze

If you want to use it for the certificate for a domain corresponding to diagnose, for example, I would like to know www.baidu.com domain name corresponding certificate is not legitimate. As we all know, is the server certificate to the client, and at what time it passed, it was passed in the TLS handshake when we know TLS is built on top of TCP, TLS handshake to be, we must first have TCP connection, but to be a TCP connection, you must know the five-tuple (source and destination address, port and protocol), about the destination address, the article had to do, in case the host certificate is on a different server, corresponding to different ip it? For example, www.baidu.com domain name corresponds to a 10 ip, I updated certificate, but I'm not sure ip corresponds to a server certificate is not with the other as true, then I may need a specific ip diagnosis, let sslyze tell me that you talk to this ip communication, pass it on to get your certificate, see if it is correct. At this time, it is necessary to do so:

sslyze --certinfo www.baidu.com} {36.152.44.96

Wherein, 36.152.44.96 is corresponding to one of ip www.baidu.com.

As for the output is what, we will say it again.

2. Output resolve

We usually use sslyze, you might use two kinds of output. One is the general command-line output, the advantage, concise and readable. Alternatively it is JSON output, this output format machine-friendly, easy to program resolved, and therefore indispensable.

Would have it, two kinds of output format in the common sense should not just be the difference, the result should be a new name now. However, both the output content sslyze really is not the same, but the difference is not small, though not enough on complementary, but enough to make it difficult for beginners on-one correspondence. So we have separately said he said.

We need to explain that our output is based on the following sslyze version 2.1.4, and openssl version is 2.8.3.

2.1 command-line text output

In the above, we have mentioned this command, under repeated here:

sslyze --certinfo www.baidu.com} {36.152.44.96

The output is as follows:

 1  AVAILABLE PLUGINS
 2  -----------------
 3 
 4   SessionRenegotiationPlugin
 5   OpenSslCipherSuitesPlugin
 6   FallbackScsvPlugin
 7   CertificateInfoPlugin
 8  HeartbleedPlugin 9  SessionResumptionPlugin 10  EarlyDataPlugin 11  CompressionPlugin 12  OpenSslCcsInjectionPlugin 13  RobotPlugin 14  HttpHeadersPlugin 15 16 17 18  CHECKING HOST(S) AVAILABILITY 19 ----------------------------- 20 21 www.baidu.com:443 => 36.152.44.96 22 23 24 25 26 SCAN RESULTS FOR WWW.BAIDU.COM:443 - 36.152.44.96 27 ------------------------------------------------- 28 29 * Certificate Information: 30  Content 31  SHA1 Fingerprint: d1f6323db6f2ec81e7023690f49b2d91e0c3993a 32  Common Name: baidu.com 33 Issuer: GlobalSign Organization Validation CA - SHA256 - G2 34 Serial Number: 13905183944940287882518820211 35 Not Before: 2019-05-09 01:22:02 36 Not After: 2020-06-25 05:31:02 37  Signature Algorithm: sha256 38  Public Key Algorithm: RSA 39 Key Size: 2048 40 Exponent: 65537 (0x10001) DNS 41 Subject Alternative Names: [ 'baidu.com' 'click.hm.baidu.com' 'cm.pos.baidu.com' 'log.hm.baidu.com' 'update.pan.baidu .com ',' wn.pos.baidu.com ',' * .91.com ',' * .aipage.cn ',' * .aipage.com ',' * .apollo.auto ',' * .baidu .com ',' * .baidubce.com ',' * .baiducontent.com ',' * .baidupcs.com ',' * .baidustatic.com ',' * .baifae.com ',' * .baifubao.com ',' .bce.baidu.com * ',' * .bcehost.com '' .bdimg.com * ',' * .bdstatic.com '' .bdtjrcv.com * ',' * .bj.baidubce .com ',' * .chuanke.com ',' * .dlnel.com ',' * .dlnel.org ',' * .dueros.baidu.com ',' * .eyun.baidu.com ',' * .fanyi.baidu.com ',' * .gz.baidubce.com ',' * .hao123.baidu.com ',' *.hao123.com ',' .hao222.com * ',' * .im.baidu.com ',' .map.baidu.com * ',' * .mbd.baidu.com ',' * .mipcdn.com ' , '.news.baidu.com *', '* .nuomi.com', '.safe.baidu.com *', '* .smartapps.cn', '.ssl2.duapps.com *', '*. su.baidu.com ',' .trustgo.com * ',' * .xueshu.baidu.com ',' apollo.auto ',' baifae.com ',' baifubao.com ',' dwz.cn '' mct.y.nuomi.com ',' www.baidu.cn ',' www.baidu.com.cn 'xueshu.baidu.com', 'apollo.auto', 'baifae.com', 'baifubao.com', 'dwz.cn', 'mct.y.nuomi.com', 'www.baidu.cn', 'www.baidu.com.cn'xueshu.baidu.com', 'apollo.auto', 'baifae.com', 'baifubao.com', 'dwz.cn', 'mct.y.nuomi.com', 'www.baidu.cn', 'www.baidu.com.cn'] 42 43  Trust 44 Hostname Validation: OK - Certificate matches www.baidu.com 45 Android CA Store (9.0.0_r9): OK - Certificate is trusted 46 Apple CA Store (iOS 13, iPadOS 13, macOS 10.15, watchOS 6, and tvOS 13):OK - Certificate is trusted 47 Java CA Store (jdk-13.0.2): OK - Certificate is trusted 48 Mozilla CA Store (2019-11-28): OK - Certificate is trusted 49 Windows CA Store (2019-11-10): OK - Certificate is trusted 50 Symantec 2018 Deprecation: WARNING: Certificate distrusted by Google and Mozilla on September 2018 51 Received Chain: baidu.com --> GlobalSign Organization Validation CA - SHA256 - G2 52 Verified Chain: baidu.com --> GlobalSign Organization Validation CA - SHA256 - G2 --> GlobalSign Root CA 53 Received Chain Contains Anchor: OK - Anchor certificate not sent 54 Received Chain Order: OK - Order is valid 55 Verified Chain contains SHA1: OK - No SHA1-signed certificate in the verified certificate chain 56 57  Extensions 58 OCSP Must-Staple: NOT SUPPORTED - Extension not found 59 Certificate Transparency: WARNING - Only 2 SCTs included but Google recommends 3 or more 60 61  OCSP Stapling 62 NOT SUPPORTED - Server did not send back an OCSP response 63 64 65 SCAN COMPLETED IN 0.85 S 66 ------------------------

1-14 line, is sslyze some of the plugin they can use, if you do not intend to enable or write plugin, we will skip it for the time being.

Lines 18-21, indicates that the current diagnostic www.baidu.com domain name corresponding ip is 36.152.44.96, there is no controversy about this, because we are pre-assigned, if we do not specify, it probably makes sense here, and will you look out through the DNS resolution of ip address that our current diagnosis which ip.

Line 29 downward Certificate Information, is what we want to know, let us look at each viewing.

Contents

Located at the output of 30-41 lines, mainly to tell us something about the certificate itself, we need to know, all the public certificates are issued by an authoritative institution for the issuance of the agency called CA (certificate authority), it is a public third-party, third-party organization to have some credibility.

We know that our system or browser in the factory when it built a number of CA, for example, I use a MacBook, arrived in the hands had built a series of CA recognized some of the world for me, so you can avoid the Some unsafe place to get them, because these are all trusted CA origin, they are not safe, then all of the TLS will not be safe. The role of the CA is to verify that these certificates are not issued its own or trust. If a CA, such as GlobalSign Organization Validation CA tell you that, no problem, this is my issued, you can rest assured. Then you can believe it.

Since so many built-in CA, we end with the former TLS communications services, received a certificate, you know how to find what CA to verify it? Unlikely to have all of the CA verify it again? And will not, as too inefficient, and each certificate you receive will tell you that you should verify who to turn to, where to tell it? There is a line 33 Issuer field. We are here GlobalSign Organization Validation CA - SHA256 - G2, tell us the GlobalSign CA issued, SHA256 signature, and that behind the G2 What does it mean? "G" on behalf of Generation, if the CA would like to change a chain, then directly into G2, G3 enough.

We can also see this certificate only during the 2019-05-09 01:22:02 to 2020-06-25 05:31:02 is legitimate, it is very easy to want to forge a certificate illegal, as long as you are to change the system time on it than this. RSA is a public key, and the signature is SHA256.

The most interesting is the bottom of the DNS Subject Alternative Names, you can see so many domain name and use the "www.baidu.com" the same certificate.

Hostname Validation

This is actually openssl built a basic function, the purpose is to verify the certificate says the hostname is not consistent with what you request. For example, you or a certificate A, the certificate is legitimate, but it is not baidu.com certificate, what was seen through, you can not use it to server communications and the baidu.com.

Android/Apple/Java/Mozilla CA Store

We have previously said that an open platform or any browser, it must provide a range of CA collection, the vast majority of general users to easily connect to the network security. In this way, each platform's own set of CA on more or less with the other platforms have differences in this collection CA, CA is simulated here sslyze collection of these systems or browsers to test hypotheses users on these platforms through these systems or platform comes with a set of CA, the certificate is not trusted to get results.

Symantec 2018 Deprecation

Each certificate I've ever seen such a WARNING verify appear in this will, therefore, be concluded that you do not worry about it. In fact, this one involves the very idea that a story, Symantec was originally a relatively large
of CA suppliers, in 2018, when Symantec issued a certificate to the way Google has been very unhappy with the last straw, and thus, released a statement that the decision in 2018 to a point in time, it is determined on your browser Symantec's certificate is not legitimate, then was echoed Mozilla, and Symantec is more passive, your certificate has been issued two browser resisted Well, then desperation, had to put their
issuing certificates to sell this business, since then indicate quit, do not play that much. You now see the Symantec certificate is another company already in operation, and, you do not have to worry, since 2018 long gone, originally issued by the Symantic been identified as illegal or rectification of the certificate has expired or , so, everything out in the certificate that you do not have to worry about this matter.

Received/Verified Chain

To understand these two Chain, we come to understand what the chain of trust (Trust Chain). We have just mentioned, this world famous top-CA also then a few more, but the certificate that the world can be described as difficult to count, if the application and maintenance of each certificate by the CA to complete several top this, then, the top CA really tired. At this time, the idea of partition came, that was the big top CA coffee ah, he certified a number of younger, and those who are looking for him, he would say to me big line, little things do not look for me, to find my little brother go with me to find similar results. His younger brother here these are his endorsement to the credit nature not to say that you trust the top-CA, it is naturally trust his younger brother. The younger brother also called intermediate certificate (Intermediate Certificate), provides a path to guide users to the top-level CA, and possibly more than a little brother, little brother little brother can trust, which formed a chain, the chain is called the "chain of trust . "

This particular operation is how it? We look at the chart:

When users visit baidu.com, first through the DNS resolution to get a server IP, to connect to a server, the TLS handshake process, first obtain a certificate baidu.com user a look at its Issuer, is the GlobalSign Organization Validation CA - SHA256 - G2, but this is not known top-level CA, and then asked the server to GlobalSign Organization Validation CA - SHA256 - G2 certificate (actually sent to the user along with baidu.com certificate, just to let everyone here easy to understand a little), look at its Issuer, saw a GlobalSign Root CA, which he knows is a top-CA, then stop here, do not have to bother the server. And then look back, we have just received several certificates? A total of twice, baidu.com -> GlobalSign Organization Validation CA - SHA256 - G2, twice reached the top CA, this chain is called Received Chain. Thus, not only to save the certificate server baidu.com domain name corresponding to this, but also save intermediate certificate, because users need to get it from here.

Certificates have to live together, that is used to doing it? It is used to verify the nature. First is to verify the validity of baidu.com, know its Issuer field, it is by GlobalSign Organization Validation CA - SHA256 - G2 issued, then we get the GlobalSign Organization Validation CA - SHA256 - G2 certificate, get it public key, and then use the public key algorithm to verify the signature baidu.com, due to the rigor of public and private key algorithm, the signature is very difficult to counterfeit, if we verify the signature is correct, it can be considered that the certificate is GlobalSign Organization validation CA - SHA256 - G2 issued to. But the GlobalSign Organization Validation CA - SHA256 - G2 is just your server had won, this does not mean you prove that you own it, it does not matter, you can verify its Issuer, namely GlobalSign Root CA, this is the top CA, locally there its certificate, that take over according to the above approach to a pass, you can know GlobalSign Organization validation CA - SHA256 - G2 is not GlobalSign Root CA for the issuance of, and verified by, that proof is that GlobalSign Root CA issued GlobalSign Organization Validation CA - SHA256 - G2, and GlobalSign Organization Validation CA - SHA256 - G2 has issued baidu.com, so you get baidu.com prove to be effective. We just completed a chain, it is baidu.com -> GlobalSign Organization Validation CA - SHA256 - G2 -> GlobalSign Root CA, in order to verify but to do so is a Verifed Chain.

The above process is simplified and rough, if we can say so, and does not dizzy, then we take a look at an actual certificate and more detailed analytical results of it. Locally run the following openssl command:

openssl s_client -showcerts -connect www.baidu.com:443

Output:

 1 CONNECTED(00000006)
 2 depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
 3 verify return:1
 4 depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2
 5 verify return:1
 6 depth=0 C = CN, ST = beijing, L = beijing, OU = service operation department, O = "Beijing Baidu Netcom Science Technology Co., Ltd", CN = baidu.com
 7 verify return:1
 8 ---
 9 Certificate chain
10  0 s:/C=CN/ST=beijing/L=beijing/OU=service operation department/O=Beijing Baidu Netcom Science Technology Co., Ltd/CN=baidu.com
11    i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
12 -----BEGIN CERTIFICATE-----
13 MIIJrzCCCJegAwIBAgIMLO4ZPBiCeOo+Q3VzMA0GCSqGSIb3DQEBCwUAMGYxCzAJ
14 BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH
15 // ... 省略若干行...
16 oZ0B5qslIww7JAJAWCT/NAKLlGEQaC+2gOPQX0oKpwLSwJg+HegCyCdxJrKoh7bb
17 nRBHS8ITYjTG0Dw5CTklj/6i9PP735snPfzQKOht3N0X0x8=
18 -----END CERTIFICATE-----
19  1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
20    i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
21 -----BEGIN CERTIFICATE-----
22 MIIEaTCCA1GgAwIBAgILBAAAAAABRE7wQkcwDQYJKoZIhvcNAQELBQAwVzELMAkG
23 A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
24 b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
25 // ... 省略若干行...
26 K1pp74P1S8SqtCr4fKGxhZSM9AyHDPSsQPhZSZg=
27 -----END CERTIFICATE-----
28 ---
29 Server certificate
30 subject=/C=CN/ST=beijing/L=beijing/OU=service operation department/O=Beijing Baidu Netcom Science Technology Co., Ltd/CN=baidu.com
31 issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
32 ---
33 No client certificate CA names sent
34 Server Temp Key: ECDH, P-256, 256 bits
35 ---
36 SSL handshake has read 4265 bytes and written 322 bytes
37 ---
38 New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
39 Server public key is 2048 bit
40 Secure Renegotiation IS supported
41 Compression: NONE
42 Expansion: NONE
43 No ALPN negotiated
44 SSL-Session:
45     Protocol  : TLSv1.2
46     Cipher    : ECDHE-RSA-AES128-GCM-SHA256
47     Session-ID: 42FD0DF68EDA274407EC33AD8B9E98177D10CBE8DA1F07E03F6E03A0CDB58FC3
48     Session-ID-ctx:
49     Master-Key: F863A3EB7527D0EC1F752C26CF8670749F7C02BFE451584E16CAAED22A414374DA5F06A24434CA1B7B69781D7C14AB7D
50 the      TLS Session Ticket:
 51      0000 - B9 E4 F4 7d Ab 8a 32 7d-F3 56 1b 04 B6 62  89 F9 ....}. 2 } . B .. V. ...
 52      0010 - FF C0 8b 14  Dd 2e 87  94 -6c 16 C6 28 5a Bd a1 's E0 ........ l'.. ( the Z ...
 53      0020 - .ae C7 20 C8 7b C5 10  57 -f5 6d 7f 40 A9 75 ed . 7b ... {.. Wm @ .u. {
 54      0030 - the cd 3d 3e 1b C0 C586 c7-24 55 ff d4 2c b2 58 e1   .=>.....$U..,.X.
55     0040 - 48 7f b9 e7 b5 c5 e9 0e-3b df 44 ce 5e 1c 03 9f   H.......;.D.^...
56     0050 - 92 a1 9a ec 93 d1 bd f3-f1 89 81 a7 d0 f4 ce 38   ...............8
57     0060 - 4d 87 17 99 d9 d4 eb 4c-46 75 8f e2 4b 62 03 18   M......LFu..Kb..
58     0070 - 63 86 83 e9 d6 54 0b ea-b8 ea bf 87 cc e6 4b c6   c....T........K.
59     0080 - 34 19 0f b0 25 2c a2 66-a4 5f 99 90 bd 61 00 74   4...%,.f._...a.t
60     0090 - 3e 45 f7 92 e9 2e f9 6c-12 c1 35 8e 4f 3c dd 7a   >E.....l..5.O<.z
61 
62     Start Time: 1585465282
63     Timeout   : 7200 (sec)
64     Verify return code: 0 (ok)
65 ---
66 closed

Line 9 openssl to see more than the output of the following, Certificate chain where we can see here received two certificates from the server side, we should note the following:

Name (Subject) 0 certificate is baidu.com (CN), issuer (Issuer) is the GlobalSign Organization Validation CA - SHA256 - G2
1 certificate is the name of the certificate issuer 0, which is the issuer GlobalSign Root CA
I did not receive GlobalSign Root CA certificates
Received Chain Contains Anchor

Here, the term includes Anchor, in fact, is transmitted from the server to the client's certificate, including the root certificate. This is not allowed, if it contains the root certificate, it will be like, the root certificate is self-signed, that is, it is possible to verify their own, and are passed over with your server to verify that what this verify the value of it? So, seeing this, the certificate must be out of the question, tell the administrator certificate, the root certificate Chain in to remove the root certificate where some clients, servers do not need trouble.

Received Chain Order

If you understand Received / Verified Chain in say, that here it is easy to understand. Tell your order is received Chain of wrong. We will not speak of what order wrong, we first talk about what is in it:

The first is the certificate corresponding domain name
Followed by the intermediate certificate
After the Issuer before a certificate of a certificate must correspond Subject
The last Issuer certificate must be a Root CA

Then we come to discuss an unequal situation, that is, if my server is in a certain purpose, you need multiple Certificate Path, that is the ultimate Root CA is more. Baidu.com hypothetical example above, the Root CA is now the GlobalSign Root CA, the server if there is no want this Root CA as a local user to do something, for example, he would like to add a Baltimore CyberTrust Root, so long as the user has two a CA is a verification will be successful. And we know the role of the intermediate certificate is to form a connected domain Chain and Root CA certificate, then this will form two paths, may receive two different intermediate certificate, which is reasonable, but contrary to our more that is to say after the desired sequence of, Issuer certificate i.e. two previous intermediate certificate does not correspond to a Subject, and thus is determined as "certificate chain out of order!".

Verified Chain contains SHA1

More than we already know, is the "signature" to build a chain of trust between the certificate. Thus, the "signature" is the core of the trust chain security, and "signature" a certificate, the issuer is required to have a top-secret private key known only to himself and a public, private key used to verify the validity of signatures, also need a one-way hash algorithm, such needs with their public key and signature content through the hashing algorithm to arrive at a signature, anyone can open a public key to verify, in order to determine the certificate was not issued by him . Just mention this one-way hash algorithm is very important because, if very easy to figure out the private key and public key by signature, then it can be any of the forged certificates. In comparison, this SHAl hash algorithm is weak, while SHA256 other relatively strong, difficult to defeat. We look at this check entry representing in the process of verification of the certificate, whether to include the certificate issued to SHA1, and if so, to prove the chain of trust is not safe enough.

OCSP Must-Staple

To understand this, we must first understand OCSP. That OCSP Online Certificate Status Protocol, This is used to doing it, it had to start from history. Saying, owned TLS certificate when there is a problem that could have been a case of legitimate certificate leaked (Leak), become unsafe, the owner of the certificate is to use the TLS certificate with customers those sites dealing with peer server owner, the first thing they have to do is inform the certificate issuing authority, help me to revoke the certificate, lest criminals are posing with his client communications. Certificate issuing authority (CA) will mark the certificate was revoked (Revoke). How to know which client certificate is revoked it? At this time, CA provide a mechanism that is regularly put all certificates revoked by his pack, and then download the client on a regular basis, when the client next time to get a certificate, it will be compared with the revocation of the collection, to confirm certificate whether it has been revoked. The question is, periodically download, it too often, clients find it troublesome, do not frequent it, it is easy to miss one has just been revoked, and that the certificate has been revoked thousands and thousands every day, these certificates corresponding to the original site may the vast majority of users will not visit this inefficiency is evident. How to do it? You may have thought of improvement measures, that is, after each user get a certificate, the CA to validate myself to see if there has not been revoked, which formed the OCSP, so users can really avoid downloading too much useless the certificate, but also to avoid because of the timeliness of the problems caused by the new revoked miscarriage of justice. However, this is not without cost, each time a user needs to access the TLS session to CA inspections, too inefficient for the user, there is also pressure on the CA server, and users need to read what the site once the CA report, that is the same as CA can always monitor network behavior of the user, so the user is not happy. Under that such improvement, we do not have to check a client, server it put this burden to the server from time to time there are reports to the CA under, let him give the same as issuing a certificate issued by a proven, indicating that the certificate has not expired , each time the client to access the server put the proof together with the certificate to the client, the client to take a relaxed CA's public key to verify know the truth, do not take requests CA server, the server side also As long as so often before going to request a CA will be able to prove this to ensure that users do not get the certificate expired, it is not that happy. Here's the proof we called Staple, this is the TLS certificate extensions OCSP Must-Staple. When users TLS handshake, see this mark, and you know pass over the server certificate contains staple, verify that the client click on it.

Certificate Transparency

The so-called Certificate Transparency, in fact, an open standard to limit or require CA chaos will not issue a certificate, a certificate for a particular domain name be associated with the issuance of chaos, such as a certificate issued by the CA to baidu.com, if he give another organization issued next.baidu.com, which may mess, so baidu.com administrator needs to have some way to monitor (or in a sense is to supervise) this CA, Yaoan routine. In order to ensure the transparency of the certificate, the certificate industry out of a "Justice League", it launched a Certificate Transparency Project, mainly to achieve the following objectives:

Let a CA impossible or very difficult to issue certificates under a domain name without the domain administrator is found
Providing an audit and monitoring platform, so that administrators and CA domain name you can easily find a certificate has been wrongly or maliciously issued
Easy to tell the user, a domain name is mistakenly or maliciously use

How it is to ensure that work? The core of this project is to use a system append-only log to save all records of certificates, each certificate at the time of issuance of the certificate must be accountable to submit records of the system, so each time a certificate issued by a record in successful return certificate receipt is Signed certificate Timestamp (SCT), which is a voucher, log indicates that the system has accepted the credentials of the information.

Google's Chrome as a pioneer in this convenient, is recognized by the industry, he advocated a number of normative CA, and conclude the following main points:

Certificate Extension: certificate to include in the SCT
TLS Extension: SCT a TLS extension information field contained in the TLS handshake signed_certificate_timestamp
OCSP Stapling: CA domain managers must support the use of OCSP Stapling

If this certificate is missing one or several functions, you might see something like this message "WARNING - Only 2 SCTs included but Google recommends 3 or more".

OCSP Stapling

This one above OCSP Must-Staple has been introduced before, OCSP Must-Staple is in fact an extension of the certificate, and OCSP Stapling is a function of the server, that is not the time to issue stapled OCSP request to the server at the client give the appropriate response.

2.2 JSON output

We also mentioned earlier, JSON output easy to parse the code, so use extra scene even in sslyze this command line tool output. Corresponding to the above example, here again we use the output JSON:

sslyze --certinfo --json_out=- www.baidu.com

The results are as follows (Note: This result is very detailed, but also very lengthy, in order not to affect the viewing of certain content to do the folding, please note that the line numbers):

Excluding several one can know the contents of the output of the above, we can see that there are two certinfo and server_info content, of which both are server server_info some information about itself or another TLS handshake to get information, and certificate itself is not associated with, and therefore, we focus on certinfo it.

leaf_certificate_has_must_staple_extension

With the output of the command " the OCSP Must-Staple " corresponding to, indicates that the certificate if it contains OCSP must-staple extension.

leaf_certificate_is_ev

Certificates we encounter can be divided into three categories, namely Domain Validated (DV), Organization Validated (OV) and Extended Validated (EV), let's contrast of their differences:

- DV:
  - Single domain-level certification
  - Inexpensive
- OV:
  - CA verification company information at the time of issuing this certificate
  - High security than DV
  - Slightly more expensive than DV
- EV：
  - Ratio of the two safety above all high
  - The company name will be displayed when the user types in a browser, and is displayed in green (see browser)
  - expensive

After comparing the above, I do not say it, EV is the best user, for service providers, in addition to expensive, others are good.

leaf_certificate_signed_certificate_timestamps_count

About Signed Certificate Timestamp (SCT) above it has been introduced, where the text can be considered to keep up with the " Certificate Transparency " Similarly, SCT inspection indicates how many items contain.

leaf_certificate_subject_matches_hostname

That matches the domain name with the certificate, to keep up with the text " Hostname Validation " is similar.

ocsp_response/ocsp_response_is_trusted/ocsp_response_status

When a user asks the server to send Stapled OCSP, the server returns and how to verify the results of local, concrete argument on the command line output " OCSP Stapling of" we mentioned before, they are similar.

path_validation_error_list/path_validation_result_list

At the command line output analysis, we have already mentioned, Root CA on a different set of platforms may be different from the domain Certificates - Root CA's path may differ> -> intermediate certificates. "Path_validation" is in fact a simulation platform or through the results of each system to verify its path, if validation fails, it will be appended to the " path_validation_error_list ", if successful, will naturally be in the " path_validation_result_list " in.

received_certificate_chain

About " Received Chain ", I think the above has been a lot of La La weave, you feel irritable before I decided to stop there. Need to see the detailed Received Chain, there is provided a more friendly way, without having to use the openssl.

received_chain_contains_anchor_certificate

And command output " Received the Contains Anchor Chain " in the meaning is the same.

received_chain_has_valid_order

And command output " Received the Order Chain " similar.

verified_certificate_chain

Select a path verification result, which one can see the detailed above mentioned Certificate Chain.

verified_chain_has_legacy_symantec_anchor

And command line output in the " Received the Contains Anchor Chain consistent."

verified_chain_has_sha1_signature

And command line output in the " Verified Chain the contains SHA1 " consistent.

3. References

[1] https://docs.microsoft.com/en-us/windows/win32/seccrypto/certificate-chains

[2] https://blog.qualys.com/ssllabs/2017/09/26/google-and-mozilla-deprecating-existing-symantec-certificates

[3] https://cheapsslsecurity.com/p/what-is-ssl-certificate-chain/

[4] https://knowledge.digicert.com/solution/SO16297.html

[5] https://scotthelme.co.uk/ocsp-must-staple/

[6] https://www.globalsign.com/en/blog/what-is-certificate-transparency

[7] https://comodosslstore.com/resources/dv-vs-ov-vs-ev-ssl-which-certificates-are-good-for-site-security/