CN1787525A - Method for application of double certificate in SSL protocol - Google Patents

Abstract

This invention relates to an application method for double certificates in SSL protocol characterizing that the stop certificates used by the service end are double, one of which is a signed one, the other is a ciphered one meeting the format of X509 sequence certificate, Server Key Exchange shake hands information is used to turn RSA public key generated temporarily to the public key of the ciphered certificate and the customer end uses it to cipher pre master secret, which has two advantages: smartly utilizing the expansion property of SSL protocol to combine the double certificates with it and no influence to the customer end due to altering the SSL service end only.

Description

The application process of double certificate in ssl protocol

Technical field

The present invention relates to computer and field of information security technology, relate in particular to the method that a kind of negotiation of adopting digital certificate to carry out authentication and key exchanges, the application process of particularly a kind of double certificate in ssl protocol.

Background technology

SSL (Secure Socket Layer) agreement is the secure transfer protocol that http protocol is encrypted that is used for of Netscape company design the earliest.Ssl protocol works on the reliable communications protocol that connects (in general all being Transmission Control Protocol), and the api interface that similar Berkeley Socket is provided will be realized the assurance of data confidentiality and integrality to application program in transmission course.The current version of ssl protocol is 3.0, after SSL obtains extensive success, IETF ( Www.ietf.org) SSL has been done standardization, standard is RFC2246, and is referred to as TLS (Transport Layer Security).SSL is widely used in E-Government, bank, security, e-commerce system, has become protection link data safety and user's authentication security standard protocols.

The high security of ssl protocol is to adopt digital certificate to carry out the negotiation exchange of authentication and key, but because this design of protocol must be early, so do not consider to introduce double certificate mechanism therein, also be to encryption and decryption pre_master_seceret with signature key when having caused SSL to carry out cipher key change, encrypted data flow just can not can't be reached the requirement that national password authority is used the PKI certificate by state supervision in the ssl protocol like this.

Double certificate mechanism is the expansion of the fundamental mode (digital signature/checking) of PKI, is that modern PKI system is built requisite PKI application model, under the approval and promotion of national password authority, also is the holotype that present China PKI builds.Use signing certificate to carry out authentication; use encrypted certificate to carry out the exchange and the protection of key; both made the PKI technology in application, bring into play it based on advantage that unsymmetrical key brought; having satisfied country again PKI is used the needs of the supervision of auditing, is the basic demand that national password authority is used the PKI certificate.

Summary of the invention

The purpose of this invention is to provide the application process of a kind of double certificate in ssl protocol, with on the basis of complete compatible original SSL/TLS agreement, realize the application of double certificate in ssl protocol, make ssl protocol be fit to the double certificate pattern of China, the relevant policies that meet country, and transparent fully to existing SSL client software (comprising the IE browser).

Purpose of the present invention can be achieved through the following technical solutions:

The application process of a kind of double certificate in ssl protocol, comprise the ssl protocol flow process the institute in steps, it is characterized in that: in the described ssl protocol flow process, the employed website certificate of service end is a double certificate, wherein a certificate is a signing certificate, another certificate is an encrypted certificate, and two certificates all meet X.509 series standard certificate format; And utilize Server KeyExchange handshake information, and the interim RSA PKI that produces is wherein replaced with the PKI of encrypted certificate in the double certificate, client is used the public key encryption pre_master_secret of this encrypted certificate.

Below the present invention is further illustrated, the application process of above-mentioned double certificate in ssl protocol comprises double certificate application process under the ssl protocol unidirectional authentication and the double certificate application process under the ssl protocol two-way authentication mode.

The double certificate application process under the ssl protocol unidirectional authentication wherein comprises following flow process:

1, client sends ClientHello message to service end, and information has comprised the version number of agreement, cryptographic algorithm, compression algorithm and key generative process that client is supported is used as the random number of importing;

2, service end sends ServerHello message to client according to the information of client, and information comprises version number, cryptographic algorithm, compression algorithm and random number as the input of key generative process of selecting from ClientHello information;

3, service end sends Certificate message to client, and information is the website signing certificate of service end;

4, service end uses the private key of website signing certificate that the PKI of website encrypted certificate is signed, and forms ServerKeyExchange information and sends to client;

5, service end sends ServerHelloDone message to client, shows that information has sent to finish;

6, client is verified the signing certificate of service end, uses the service end website certificate of verifying that the public key signature of service end website encrypted certificate is verified; Client produces the pre_master_seceret key at random, uses the PKI of the encrypted certificate of service end to encrypt, and forms ClientKeyExchange information and sends to service end;

7, client sends ChangeCipherSpec message to service end, shows that to service end algorithm and key agreement finish;

8, client uses key algorithm to calculate master_seceret according to client random number, service end random number, pre_master_seceret, and then use random number and master_seceret to calculate real data encryption key, then all handshake information summary back encryptions are formed Finished message and send to service end;

9, service end is used website encrypted certificate private key deciphering pre_master_seceret, adopt same algorithm computation master_seceret and the data encryption key of client, the correctness of checking Finished message, send ChangeCipherSpec message to client, algorithm and key agreement express one's approval;

10, service end sends all handshake information summary back encryption formation Finished message to client;

11, client and service end are used the secret key encryption application data that negotiation calculates respectively.

The double certificate application process of ssl protocol under authentication mode comprises following flow process:

1, client sends ClientHello message to service end, and information has comprised the version number of agreement, cryptographic algorithm, compression algorithm and key generative process that client is supported is used as the random number of importing;

2, service end sends ServerHello message to client according to the information of client, and information comprises version number, cryptographic algorithm, compression algorithm and random number as the input of key generative process of selecting from ClientHello information;

3, service end sends Certificate message to client, and information is the website signing certificate of service end;

4, service end transmission CertificateRequest message indication client is carried out client certificate, has indicated auth type (RSA) simultaneously;

5, service end uses the private key of website signing certificate that the PKI of website encrypted certificate is signed, and forms ServerKeyExchange information and sends to client;

6, service end sends ServerHelloDone message to client, shows that information has sent to finish;

7, client is verified the signing certificate of service end, and checking sends Certificate message by the back, and information is client's signing certificate;

8, client uses the service end website certificate of verifying that the public key signature of service end website encrypted certificate is verified; Client produces the pre_master_seceret key at random, uses the PKI of the encrypted certificate of service end to encrypt, and forms ClientKeyExchange information and sends to service end;

9, client uses the private key of signing certificate that the summary of handshaking information is signed, and forms CertificateVerify message and sends to service end; Client sends ChangeCipherSpec message to service end, shows that to service end algorithm and key agreement finish;

10, client uses key algorithm to calculate master_seceret according to client random number, service end random number, pre_master_seceret, and then use random number and master_seceret to calculate real data encryption key, then all handshake information summary back encryptions are formed Finished message and send to service end;

11, service end checking client certificate, the signature of the formal checking client of use client; Service end is used website encrypted certificate private key deciphering pre_master_seceret, adopt same algorithm computation master_seceret and the data encryption key of client, the correctness of checking Finished message, send ChangeCipherSpec message to client, algorithm and key agreement express one's approval;

12, service end sends all handshake information summary back encryption formation Finished message to client;

13, client and service end are used the secret key encryption application data that negotiation calculates respectively.

Key of the present invention is to define in the SSLv3/TLS1.0 agreement interim RSA mechanism and corresponding Server KeyExchange handshake information.Originally interim RSA mechanism is in order to satisfy the cryptographic algorithm outlet restriction of U.S. government at that time, use the shorter RSA key of figure place that pre_master_secret is encrypted, thereby in the SSL handshake information, added a new type Server Key Exchange, when using RSA Algorithm, it comprises the signature of the private key of an interim RSA PKI that produces and service end website certificate correspondence to it.Client uses this PKI to replace the PKI of service end website certificate to encrypt pre_master_secret.

The present invention utilizes Server Key Exchange handshake information, the RSA PKI of wherein interim generation is replaced with the PKI of encrypted certificate in the double certificate, just can make client use this public key encryption pre_master_secret, thereby make double certificate mechanism incorporate ssl protocol fully.

When though the SSLv3 agreement designs, the cryptographic algorithm outlet restriction of U.S. government stipulates that the right mould length of its interim RSA key can not be greater than 512, but present this restriction is cancelled, various general SSL clients all support to use 1024 or longer interim RSA key right, this just makes the present invention transparent fully to existing SSL client, possesses very high feasibility.

The present invention has following two advantages: the one, and the ingenious extended attribute that utilizes ssl protocol is finished combining of double certificate and ssl protocol.The 2nd, only the SSL service end is carried out corresponding change, to the not influence of original system client, it is convenient to implement.

Description of drawings

Fig. 1 is the flow chart under the existing ssl protocol unidirectional authentication;

Fig. 2 is the double certificate applicating flow chart under the ssl protocol unidirectional authentication of the present invention;

Fig. 3 is the flow chart under the existing ssl protocol two-way authentication mode;

Fig. 4 is the double certificate applicating flow chart under the ssl protocol two-way authentication mode of the present invention.

Embodiment

Describe the present invention below in conjunction with the drawings and specific embodiments.

The application process of a kind of double certificate in ssl protocol, comprise the ssl protocol flow process the institute in steps, in the ssl protocol flow process, the employed website certificate of service end is a double certificate, wherein a certificate is a signing certificate, another certificate is an encrypted certificate, and two certificates all meet X.509 series standard certificate format; And utilize Server Key Exchange handshake information, and the interim RSA PKI that produces is wherein replaced with the PKI of encrypted certificate in the double certificate, client is used the public key encryption pre_master_secret of this encrypted certificate.

Referring to Fig. 1, the flow process under the existing ssl protocol unidirectional authentication is:

1, client sends ClientHello message to service end, and information has comprised the version number of agreement, cryptographic algorithm, compression algorithm and key generative process that client is supported is used as the random number of importing;

2, service end sends ServerHello message to client according to the information of client, and information comprises version number, cryptographic algorithm, compression algorithm and random number as the input of key generative process of selecting from ClientHello information;

3, service end sends Certificate message to client, and information is the website certificate of service end;

4, service end sends ServerHelloDone message to client, shows that information has sent to finish.

5, client is verified the certificate of service end, and extracts the PKI of server.Client produces the pre_master_seceret key at random, uses the PKI of service end to encrypt, and forms ClientKeyExchange information and sends to service end;

6, client sends ChangeCipherSpec message to service end, shows that to service end algorithm and key agreement finish.

7, client uses key algorithm to calculate master_seceret according to client random number, service end random number, pre_master_seceret, and then use random number and master_seceret to calculate real data encryption key, then all handshake information summary back encryptions are formed Finished message and send to service end;

8, service end is used website certificate private key deciphering pre_master_seceret, adopt same algorithm computation master_seceret and the data encryption key of client, and the correctness of checking Finished message, send ChangeCipherSpec message to client, algorithm and key agreement express one's approval;

9, service end sends all handshake information summary back encryption formation Finished message to client;

10, client and service end are used the secret key encryption application data that negotiation calculates respectively.

Referring to Fig. 2, the flow process that the double certificate under the ssl protocol unidirectional authentication is used is:

1, client sends ClientHello message to service end, and information has comprised the version number of agreement, cryptographic algorithm, compression algorithm and key generative process that client is supported is used as the random number of importing;

2, service end sends ServerHello message to client according to the information of client, and information comprises version number, cryptographic algorithm, compression algorithm and random number as the input of key generative process of selecting from ClientHello information;

3, service end sends Certificate message to client, and information is the website signing certificate of service end;

4, service end uses the private key of website signing certificate that the PKI of website encrypted certificate is signed, and forms ServerKeyExchange information and sends to client;

5, service end sends ServerHelloDone message to client, shows that information has sent to finish;

6, client is verified the signing certificate of service end, uses the service end website certificate of verifying that the public key signature of service end website encrypted certificate is verified; Client produces the pre_master_seceret key at random, uses the PKI of the encrypted certificate of service end to encrypt, and forms ClientKeyExchange information and sends to service end;

7, client sends ChangeCipherSpec message to service end, shows that to service end algorithm and key agreement finish;

8, client uses key algorithm to calculate master_seceret according to client random number, service end random number, pre_master_seceret, and then use random number and master_seceret to calculate real data encryption key, then all handshake information summary back encryptions are formed Finished message and send to service end;

9, service end is used website encrypted certificate private key deciphering pre_master_seceret, adopt same algorithm computation master_seceret and the data encryption key of client, the correctness of checking Finished message, send ChangeCipherSpec message to client, algorithm and key agreement express one's approval;

10, service end sends all handshake information summary back encryption formation Finished message to client;

11, client and service end are used the secret key encryption application data that negotiation calculates respectively.

Referring to Fig. 3, the flow process under the existing ssl protocol two-way authentication mode is:

1, client sends ClientHello message to service end, and information has comprised the version number of agreement, cryptographic algorithm, compression algorithm and key generative process that client is supported is used as the random number of importing;

2, service end sends ServerHello message to client according to the information of client, and information comprises version number, cryptographic algorithm, compression algorithm and random number as the input of key generative process of selecting from ClientHello information;

3, service end sends Certificate message to client, and information is the website certificate of service end;

4, service end transmission CertificateRequest message indication client is carried out client certificate, has indicated auth type (RSA) simultaneously;

5, service end sends ServerHelloDone message to client, shows that information has sent to finish;

6, client is verified the signing certificate of service end, and checking sends Certificate message by the back, and information is client's signing certificate;

Client produces the pre_master_seceret key at random, uses the PKI of the certificate of service end to encrypt, and forms ClientKeyExchange information and sends to service end.

7, client uses the private key of signing certificate that the summary of handshaking information is signed, and forms CertificateVerify message and sends to service end;

8, client sends ChangeCipherSpec message to service end, shows that to service end algorithm and key agreement finish;

9, client uses key algorithm to calculate master_seceret according to client random number, service end random number, pre_master_seceret, and then use random number and master_seceret to calculate real data encryption key, then all handshake information summary back encryptions are formed Finished message and send to service end;

10, service end checking client certificate, the signature of the formal checking client of use client;

11, service end is used website certificate private key deciphering pre_master_seceret, adopt same algorithm computation master_seceret and the data encryption key of client, the correctness of checking Finished message, send ChangeCipherSpec message to client, algorithm and key agreement express one's approval;

12, service end sends all handshake information summary back encryption formation Finished message to client;

13, client and service end are used the secret key encryption application data that negotiation calculates respectively.

Referring to Fig. 4, the flow process that the double certificate under the ssl protocol two-way authentication mode is used is:

1, client sends ClientHello message to service end, and information has comprised the version number of agreement, cryptographic algorithm, compression algorithm and key generative process that client is supported is used as the random number of importing;

2, service end sends ServerHello message to client according to the information of client, and information comprises version number, cryptographic algorithm, compression algorithm and random number as the input of key generative process of selecting from ClientHello information;

3, service end sends Certificate message to client, and information is the website signing certificate of service end;

4, service end transmission CertificateRequest message indication client is carried out client certificate, has indicated auth type (RSA) simultaneously;

5, service end uses the private key of website signing certificate that the PKI of website encrypted certificate is signed, and forms ServerKeyExchange information and sends to client;

6, service end sends ServerHelloDone message to client, shows that information has sent to finish;

7, client is verified the signing certificate of service end, and checking sends Certificate message by the back, and information is client's signing certificate;

8, client uses the service end website certificate of verifying that the public key signature of service end website encrypted certificate is verified; Client produces the pre_master_seceret key at random, uses the PKI of the encrypted certificate of service end to encrypt, and forms ClientKeyExchange information and sends to service end;

9, client uses the private key of signing certificate that the summary of handshaking information is signed, and forms CertificateVerify message and sends to service end; Client sends ChangeCipherSpec message to service end, shows that to service end algorithm and key agreement finish;

10, client uses key algorithm to calculate master_seceret according to client random number, service end random number, pre_master_seceret, and then use random number and master_seceret to calculate real data encryption key, then all handshake information summary back encryptions are formed Finished message and send to service end;

11, service end checking client certificate, the signature of the formal checking client of use client; Service end is used website encrypted certificate private key deciphering pre_master_seceret, adopt same algorithm computation master_seceret and the data encryption key of client, the correctness of checking Finished message, send ChangeCipherSpec message to client, algorithm and key agreement express one's approval;

12, service end sends all handshake information summary back encryption formation Finished message to client;

13, client and service end are used the secret key encryption application data that negotiation calculates respectively.

Adopting above double certificate and client to carry out contents such as data that the data of unilateral authentication, SSL service end adopt above double certificate and client to carry out two-way authentication below by the encrypted certificate private key of the encrypted certificate of the signing certificate private key of the signing certificate of disclosed SSL service end, SSL service end, SSL service end, SSL service end and SSL service end helps those skilled in the art and understands the present invention, but should understand, these contents are exemplary, and the present invention does not limit to this.

The signing certificate of SSL service end is as follows:

-----BEGIN?CERTIFICATE-----

MIICjzCCAfgCCQDENX3DA2TnWjANBgkqhkiG9w0BAQUFADCBhzELMAkGA1UEBhMC

Q04xCzAJBgNVBAgTA1NIMREwDwYDVQQHEwhTaGFuZ2hhaTEWMBQGA1UEChMNS29h

bCBTb2Z0d2FyZTESMBAGA1UECxMJU1NMIEdyb3VwMQ8wDQYDVQQDEwZOZXN0Y2Ex

GzAZBgkqhkiG9w0BCQEWDHNzbEBrb2FsLmNvbTAeFw0wNTA5MjkwMjQwMTJaFw0w

NTEwMjkwMjQwMTJaMIGPMQswCQYDVQQGEwJDTjELMAkGA1UECBMCUOgxETAPBgNV

BAcTCFNoYW5naGFpMRYwFAYDVQQKEw1Lb2FsIFNvZnR3YXJlMRIwEAYDVQQLEwlT

U0wgR3JvdXAxFzAVBgNVBAMTDnd3dy5teXNpdGUuY29tMRswGQYJKoZIhvcNAQkB

Fgxzc2xAa29hbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMLtX8YJ

8BqL6DzcHawsh2tbe2PN46WDhLHX2qte64EAgpgqo3Q++U7RFIkaAR0kPToKAVvt

/4eZxwXmf08fw/3lWRCchPnfiuZsqYv5Qa2xyHPCtkSFGhCuU3BSgab80m1RYXA2

NrmRCLW9INouhc2vypYDG5SXf7RtehRwjBUnAgMBAAEwDQYJKoZIhvcNAQEFBQAD

gYEAgdKReBB5+tMymI9PQmu0363vsjc9Fk8vzouUw3HhFsH4gz4ao3SgEp+Q8V6T

RP/+YWaJ8uz3/B/Cv9d2tHQu7ZZoe0fT5ymGkeoRyHAWshEO2MKPTruNHI5bOgvD

6tIanPpPwmiA4d+jxHbHBthEpkv7/Tgcky780EFBt6mbX6o＝

-----END?CERTIFICATE-----

The signing certificate private key of SSL service end is as follows:

-----BEGIN?RSA?PRIVATE?KEY-----

MIICXQIBAAKBgQDC7V/GCfAai+g83B2sLIdrW3tjzeOlg4Sx19qrXuuBAIKYKqN0

PvlO0RSJGgEdJD06CgFb7f+HmccF5n9PH8P95VkQnIT534rmbKmL+UGtschzwrZE

hRoQrlNwUoGm/NJtUWFwNja5kQilvSDaLoXNr8qWAxuUl3+0bXoUcIwVJwIDAQAB

AoGAYpMUGdwwtdwGp7BQuR8TpHDw5znZY3wtAJq+FGe+BNCzOixl2IV4IimNjv+9

jHUlGVKx+UFUNcjIYu17eBICVGJP8ksPcs2PGncEwVRXOmMxFPo8JOz6isEiWl3z

8EMHTyD/ZS8Rghy4eabzdGLd7RfqAB2360f5tphlUFxnUCECQQD1q85vhtvLI4kb

93jpSe1T/FXuaXCJINX1Qe50RxaQQj1/FYkBRWCRb9p+CfMdNbtyg5WG4T/xYLDh

pjr+Qb9PAkEAyx9nchTELRN2axp5UvrV5gsVgfscbgz5oBr7VSWFepwE+o079GSR

+KvqzsTgER/+ymxnJNWhoWuC44fGNwwWqQJBALRkqto0AZLhjh10E6fiE/X2tTay

j+LxjH6ichVi18voBQYvTwHy6p0AsESak70gJntI6fQ31Fcu89NN18W5i3sCQEVi

peCXbWgEdPgjI/yPiM+7S46KK+z/66mgbehpF86JSz4XTrquPBrZBy24nN3csxmM

rDMt8reEVULKF5CoRXkCQQDCG01AGaNtGCx45/a9EsT1CecN268jUuh1DAc46Uh/

91xq4NagOjSoaoSHOu2u+3jDuW6DSz8Fi+81kDbMHy/6

-----END?RSA?PRIVATE?KEY-----

The encrypted certificate of SSL service end is as follows:

-----BEGIN?CERTIFICATE-----

MIICjzCCAfgCCQDENX3DA2TnWzANBgkqhkiG9w0BAQUFADCBhzELMAkGA1UEBhMC

Q04xCzAJBgNVBAgTAlNIMREwDwYDVQQHEwhTaGFuZ2hhaTEWMBQGA1UEChMNS29h

bCBTb2Z0d2FyZTESMBAGA1UECxMJU1NMIEdyb3VwMQ8wDQYDVQQDEwZOZXN0Y2Ex

GzAZBgkqhkiG9w0BCQEWDHNzbEBrb2FsLmNvbTAeFw0wNTA5MjkwMjQwMjRaFw0w

NTEwMjkwMjQwMjRaMIGPMQswCQYDVQQGEwJDTjELMAkGA1UECBMCU0gxETAPBgNV

BAcTCFNoYW5naGFpMRYwFAYDVQQKEw1Lb2FsIFNvZnR3YXJlMRIwEAYDVQQLEwlT

U0wgR3JvdXAxFzAVBgNVBAMTDnd3dy5teXNpdGUuY29tMRswGQYJKoZIhvcNAQkB

Fgxzc2xAa29hbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANJMtkLr

6AF7ZYfdpsHSoSCRnw84dX9LbR9zixNz/fL3ixzfb0ShSMwNQNpMc2Kb5m/T5a+Q

kiAx5b19p3ehFRe+3mXLR50WgRaig+j826kkFFGg7ZpKI5cMvarLgIrGsnt4s3Fv

rMuFclwWLZcSvk0ha81vcdxJrbPnTJ/A9qyBAgMBAAEwDQYJKoZIhvcNAQEFBQAD

gYEAFWpiShXKsZJyalBAjMcFk/sD0KM+liQdE0a2LvHTmj/rmDh4xMf1n9VClYCj

TNyJmt/YlQfBTJs6seocA5igNZksEXjj6HAhQVMWbJqfuXUhhDD4yJwrQvZSF3GH

V8DYYfWlReMHd+6ikPRHuL9BMKi0jcyTy9tfdEsv/oi3Cjw＝

-----END?CERTIFICATE-----

The encrypted certificate private key of SSL service end is as follows:

-----BEGIN?RSA?PRIVATE?KEY-----

MIICXQIBAAKBgQDSTLZC6+gBe2WH3abB0qEgkZ8POHV/S20fc4sTc/3y94sc329E

oUjMDUDaTHNim+Zv0+WvkJIgMeW5fad3oRUXvt5ly0eTloEWooPo/NupJBRRo02a

SiOXDL2qy4CKxrJ7eLNxb6zLhXNcFi2XEr5DoWvJb3HcSa2z50yfwPasgQIDAQAB

AoGAIhto7/+cuCjQNbHgKs1DbqnPd0N74vJTt2cg5j3IsRAu0rb2L9ZMnTOFEiKW

ECciv35JYSj8WhZdoLDdaUyJw+3MxgG927B+/0p3snD4fBet7vbprT7cCiMkCXzh

T05oHeXinva98Dr2FGDOeGIRJOhWvgh3Fd23mFKEuoqBvCUCQQDyxWoxuh7c5qQh

X1Hkm6Tw1+Zb2eEJqgT6/tAGYNUY540kD0s27MbP79bBpyHEHq/F+tYgXoNDFIge

7mFRDGLbAkEA3cJUVz/qcbeMElPxkPEpEkWof2twBTgC2vK1eMd1I0T2bFQR9Rj3

FE4XjaJwxCVMYp1tMsXVhrIS8sGwi+U20wJBANAqTLOU9w/NSKFA/ZR7jUOrzB+o

RFkoCxs5USCW+UJgkdqArqrK/nKgIdJtP/vNoESvn9mjkQP83/c9yf5YE48CQQDd

jJ98h60vNsQfL3Rg7T6uPZ+opWrGG/5mRhNhRkxWDzjuY1OJfgajZ52KaCanH+hf

gY4uMo4wQspBc5bxPO/3AkBUDq/n66Ar0Whn3b6PSpHeRlMQrk+pX42+ctEgXUgD

bg+jXBbj1ZLen8W52AlCdfy0hviGoviuEj+2jBl1zgaz

-----END?RSA?PRIVATE?KEY-----

It is as follows that the SSL service end adopts above double certificate and client to carry out the data of unilateral authentication:

New?TCP?connection#2：192.168.40.77(1181)<->192.168.40.212(443)

21?0.0229(0.0229)?C＞SV3.1(65)Handshake

ClientHello

Version?3.1

random[32]＝

43?3b?55?87?f2?33?32?ab?cc?f9?ed?6c?04?26?00?f2

15?8c?d7?aa?f6?1e?08?03?8c?75?d5?9b?13?56?4a?c8

cipher?suites

TLS_RSA_WITH_RC4_128_MD5

TLS_RSA_WITH_RC4_128_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_DES_CBC_SHA

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

TLS_RSA_EXPORT_WITH_RC4_40_MD5

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS_DHE_DSS_WITH_DES_CBC_SHA

TLS_DHE_DSS_EXPORT1024_WITH_DE_CBC_SHA

compression?methods

NULL

Packet?data[70]＝

16?03?01?00?41?01?00?00?3d?03?01?43?3b?55?87?f2

33?32?ab?cc?f9?ed?6c?04?26?00?f2?15?8c?d7?aa?f6

1e?08?03?8c?75?d5?9b?13?56?4a?c8?00?00?16?00?04

00?05?00?0a?00?09?00?64?00?62?00?03?00?06?00?13

00?12?00?63?01?00

22?0.0459(0.0229)?S＞CV3.1(42)Handshake

ServerHello

Version?3.1

random[32]＝

43?3b?54?ac?e0?15?10?a6?ca?05?da?17?67?b4?13?b3

6d?b8?cf?97?48?b3?24?c6?a5?a7?9e?c2?5e?bb?c4?23

session_id[0]＝

cipherSuite?TLS_RSA_WITH_RC4_128_MD5

compressionMethod NULL

Packet?data[47]＝

16?03?01?00?2a?02?00?00?26?03?01?43?3b?54?ac?e0

15?10?a6?ca?05?da?17?67?b4?13?b3?6d?b8?cf?97?48

b3?24?c6?a5?a7?9e?c2?5e?bb?c4?23?00?00?04?00

23?0.0459(0.0000)?S＞CV3.1(669)?Handshake

Certificate

Packet?data[674]＝

16?03?01?02?9d?0b?00?02?99?00?02?96?00?02?93?30

82?02?8f?30?82?01?f8?02?09?00?c4?35?7d?c3?03?64

e7?5a?30?0d?06?09?2a?86?48?86?f7?0d?01?01?05?05

00?30?81?87?31?0b?30?09?06?03?55?04?06?13?02?43

4e?31?0b?30?09?06?03?55?04?08?13?02?53?48?31?11

30?0f?06?03?55?04?07?13?08?53?68?61?6e?67?68?61

69?31?16?30?14?06?03?55?04?0a?13?0d?4b?6f?61?6c

20?53?6f?66?74?77?61?72?65?31?12?30?10?06?03?55

04?0b?13?09?53?53?4c?20?47?72?6f?75?70?31?0f?30

0d?06?03?55?04?03?13?06?74?65?73?74?63?61?31?1b

30?19?06?09?2a?86?48?86?f7?0d?01?09?01?16?0c?73

73?6c?40?6b?6f?61?6c?2e?63?6f?6d?30?1e?17?0d?30

35?30?39?32?39?30?32?34?30?31?32?5a?17?0d?30?35

31?30?32?39?30?32?34?30?31?32?5a?30?81?8f?31?0b

30?09?06?03?55?04?06?13?02?43?4e?31?0b?30?09?06

03?55?04?08?13?02?53?48?31?11?30?0f?06?03?55?04

07?13?08?53?68?61?6e?67?68?61?69?31?16?30?14?06

03?55?04?0a?13?0d?4b?6f?61?6c?20?53?6f?66?74?77

61?72?65?31?12?30?10?06?03?55?04?0b?13?09?53?53

4c?20?47?72?6f?75?70?31?17?30?15?06?03?55?04?03

13?0e?77?77?77?2e?6d?79?73?69?74?65?2e?63?6f?6d

31?1b?30?19?06?09?2a?86?48?86?f7?0d?01?09?01?16

0c?73?73?6c?40?6b?6f?61?6c?2e?63?6f?6d?30?81?9f

30?0d?06?09?2a?86?48?86?f7?0d?01?01?01?05?00?03

81?8d?00?30?81?89?02?81?81?00?c2?ed?5f?c6?09?f0

1a?8b?e8?3c?dc?1d?ac?2c?87?6b?5b?7b?63?cd?e3?a5

83?84?b1?d7?da?ab?5e?eb?81?00?82?98?2a?a3?74?3e

f9?4e?d1?14?89?1a?01?1d?24?3d?3a?0a?01?5b?ed?ff

87?99?c7?05?e6?7f?4f?1f?c3?fd?e5?59?10?9c?84?f9

df?8a?e6?6c?a9?8b?f9?41?ad?b1?c8?73?c2?b6?44?85

1a?10?ae?53?70?52?81?a6?fc?d2?6d?51?61?70?36?36

b9?91?08?b5?bd?20?da?2e?85?cd?af?ca?96?03?1b?94

97?7f?b4?6d?7a?14?70?8c?15?27?02?03?01?00?01?30

0d?06?09?2a?86?48?86?f7?0d?01?01?05?05?00?03?81

81?00?81?d2?91?78?10?79?fa?d3?32?98?8f?4f?42?6b

8e?df?ad?ef?b2?37?3d?16?4f?2f?ce?8b?94?c3?71?e1

16?c1?f8?83?3e?1a?a3?74?a0?12?9f?90?f1?5e?93?44

ff?fe?61?66?89?f2?ec?f7?fc?1f?c2?bf?d7?76?b4?74

2e?ed?96?68?7b?47?d3?e7?29?86?91?ea?11?c8?70?16

b2?11?0e?d8?c2?8f?4e?bb?8d?1c?8e?5b?3a?0b?c3?ea

d2?1a?9c?fa?4f?c2?68?80?e1?df?a3?c4?76?c7?06?d8

44?a6?4b?fb?fd?38?1c?93?2e?fc?d0?41?41?b7?a9?9b

5f?aa

24?0.0459(0.0000)?S＞CV3.1(269)Handshake

ServerKeyExchange

params

RSA?modulus[128]＝

d2?4c?b6?42?eb?e8?01?7b?65?87?dd?a6?c1?d2?a1?20

91?9f?0f?38?75?7f?4b?6d?1f?73?8b?13?73?fd?f2?f7

8b?1c?df?6f?44?a1?48?cc?0d?40?da?4c?73?62?9b?e6

6f?d3?e5?af?90?92?20?31?e5?b9?7d?a7?77?a1?15?17

be?de?65?cb?47?93?96?81?16?a2?83?e8?fc?db?a9?24

14?51?a0?ed?9a?4a?23?97?0c?bd?aa?cb?80?8a?c6?b2

7b?78?b3?71?6f?ac?cb?85?73?5c?16?2d?97?12?be?43

a1?6b?c9?6f?71?dc?49?ad?b3?e7?4c?9f?c0?f6?ac?81

RSA_exponent[3]＝

01?00?01

signature[128]＝

57?f7?c8?b3?78?93?0f?f4?bc?8c?d8?e7?a4?37?6f?79

40?75?c0?04?5a?4f?4a?8b?f3?00?fa?ea?ee?c9?cd?da

cb?17?5e?74?a1?2b?46?c4?93?ff?cd?b1?b8?e8?6b?3c

1f?c7?a4?cd?af?37?e1?2a?17?f7?5e?08?95?85?22?ca

7d?92?17?a6?08?a2?34?8a?cb?c8?4f?ec?e4?da?88?d7

5b?07?96?27?03?80?99?05?e5?d8?b6?71?85?7b?3b?7f

07?b8?56?5f?8b?6d?14?bc?39?b5?3c?0b?da?27?02?a4

f9?44?b3?4a?3f?3e?d1?61?2a?bc?c2?ca?b0?f2?7c?fc

Packet?data[274]＝

16?03?01?01?0d?0c?00?01?09?00?80?d2?4c?b6?42?eb

e8?01?7b?65?87?dd?a6?c1?d2?a1?20?91?9f?0f?38?75

7f?4b?6d?1f?73?8b?13?73?fd?f2?f7?8b?1c?df?6f?44

a1?48?cc?0d?40?da?4c?73?62?9b?e6?6f?d3?e5?af?90

92?20?31?e5?b9?7d?a7?77?a1?15?17?be?de?65?cb?47

93?96?81?16?a2?83?e8?fc?db?a9?24?14?51?a0?ed?9a

4a?23?97?0c?bd?aa?cb?80?8a?c6?b2?7b?78?b3?71?6f

ac?cb?85?73?5c?16?2d?97?12?be?43?a1?6b?c9?6f?71

dc?49?ad?b3?e7?4c?9f?c0?f6?ac?81?00?03?01?00?01

00?80?57?f7?c8?b3?78?93?0f?f4?bc?8c?d8?e7?a4?37

6f?79?40?75?c0?04?5a?4f?4a?8b?f3?00?fa?ea?ee?c9

cd?da?cb?17?5e?74?a1?2b?46?c4?93?ff?cd?b1?b8?e8

6b?3c?1f?c7?a4?cd?af?37?e1?2a?17?f7?5e?08?95?85

22?ca?7d?92?17?a6?08?a2?34?8a?cb?c8?4f?ec?e4?da

88?d7?5b?07?96?27?03?80?99?05?e5?d8?b6?71?85?7b

3b?7f?07?b8?56?5f?8b?6d?14?bc?39?b5?3c?0b?da?27

02?a4?f9?44?b3?4a?3f?3e?d1?61?2a?bc?c2?ca?b0?f2

7c?fc

25?0.0459(0.0000)?S＞CV3.1(4)Handshake

ServerHelloDone

Packet?data[9]＝

16?03?01?00?04?0e?00?00?00

26?0.0610(0.0151)?C＞SV3.1(134)Handshake

ClientKeyExchange

EncryptedPreMasterSecret[128]＝

cc?7d?8e?82?68?41?56?37?28?45?20?54?fa?52?e8?ca

43?fb?00?79?b6?e0?d8?b3?e1?d6?b8?0f?5b?cf?03?34

ff?22?7f?c8?38?b5?4a?62?59?ce?7f?11?d4?83?bf?7e

36?43?76?d3?94?72?55?c6?64?3c?92?54?da?f6?76?61

02?2f?68?45?02?f4?68?10?f7?12?41?c1?c4?44?df?c6

b8?a9?f5?48?3f?28?60?9e?5d?bc?d8?5f?74?69?4b?dc

0f?5d?ce?5b?aa?c2?83?51?c4?b7?c5?73?11?e7?97?d9

38?1c?81?5a?b2?a8?35?f9?8f?aa?56?b1?cf?98?7d?3b

Packet?data[139]＝

16?03?01?00?86?10?00?00?82?00?80?cc?7d?8e?82?68

41?56?37?28?45?20?54?fa?52?e8?ca?43?fb?00?79?b6

e0?d8?b3?e1?d6?b8?0f?5b?cf?03?34?ff?22?7f?c8?38

b5?4a?62?59?ce?7f?11?d4?83?bf?7e?36?43?76?d3?94

72?55?c6?64?3c?92?54?da?f6?76?61?02?2f?68?45?02

f4?68?10?f7?12?41?c1?c4?44?df?c6?b8?a9?f5?48?3f

28?60?9e?5d?bc?d8?5f?74?69?4b?dc?0f?5d?ce?5b?aa

c2?83?51?c4?b7?c5?73?11?e7?97?d9?38?1c?81?5a?b2

a8?35?f9?8f?aa?56?b1?cf?98?7d?3b

27?0.0610(0.0000)?C＞SV3.1(1)ChangeCipherSpec

Packet?data[6]＝

14?03?01?00?01?01

28?0.0610(0.0000)?C＞SV3.1(32)Handshake

Packet?data[37]＝

16?03?01?00?20?58?4b?8a?32?c3?ca?64?fd?17?7e?c3

9e?e8?02?c8?35?19?e1?af?d7?39?60?5e?92?a7?d0?3b

a4?d7?db?da?93

29?0.0809(0.0198)?S＞CV3.1(1)ChangeCipherSpec

Packet?data[6]＝

14?03?01?00?01?01

21?00.0809(0.0000)?S＞CV3.1(32)Handshake

Packet?data[37]＝

16?03?01?00?20?cf?0c?36?fa?92?f2?23?ff?d0?de?03

ae?33?c2?e7?d7?f5?3b?1b?3e?9d?fc?28?1d?bc?03?0c

a7?44?ad?b3?bf

211?0.0899(0.0090)?C＞SV3.1(396)application_data

Packet?data[401]＝

17?03?01?01?8c?87?b1?f4?07?9e?30?40?4e?5d?32?c8

8b?97?b4?ce?38?b4?03?8f?d2?ea?a2?ee?30?7e?64?dd

ae?0d?62?bc?00?f8?30?3c?90?f3?bf?2f?c6?41?b4?24

82?a4?ff?d0?c7?ba?83?dd?b0?96?6d?ee?17?16?1f?c1

26?6f?8d?f7?23?49?6c?d7?5a?9c?c4?c1?ac?85?49?ec

a3?75?40?5f?b6?c1?55?61?00?83?d6?8a?fc?08?ce?ea

df?60?cf?a2?fc?fb?a8?19?ee?78?3f?80?09?61?48?01

ff?52?fa?65?3f?95?31?a8?c6?19?2f?1d?33?8d?68?3f

71?37?15?33?f2?1a?5d?c9?73?78?38?ac?c1?8e?63?a7

aa?05?58?b1?21?76?91?58?da?20?80?6b?6c?f2?c8?df

41?d7?d2?ab?b8?4f?97?a4?f9?76?a0?62?20?ab?35?8e

a2?2e?5e?17?aa?b4?48?e4?3e?29?76?4c?74?9e?4a?82

b7?c6?6b?8b?29?46?72?e8?02?13?13?5e?1c?3b?c6?8c

cb?cc?d3?f8?1f?66?54?d1?98?fc?47?d6?06?f3?cb?72

5a?24?1a?90?82?18?a8?ac?c0?72?cb?e0?91?da?07?70

e4?e7?30?ac?f9?98?a0?51?50?64?63?68?60?22?57?22

a8?48?00?a5?d0?f5?43?fd?2c?2e?da?cf?db?72?b1?95

d4?4d?03?59?06?37?65?9b?26?8b?c4?14?e2?75?74?50

cc?8d?9c?10?53?70?67?dd?7f?2d?10?d5?04?25?b2?fc

77?1e?22?d0?42?01?d7?38?b6?ec?6d?55?76?66?11?df

73?0e?cf?3d?c8?ba?2e?ee?b5?1e?f9?27?65?ef?ba?6f

04?31?2a?1e?38?f7?24?df?d7?f0?18?b4?fb?28?39?8c

87?e7?a7?a2?ae?59?4d?85?2a?eb?53?e1?45?03?37?1e

73?07?8f?97?bc?f9?98?d8?2e?7a?50?b2?ed?f0?e8?76

de?d2?4d?ef?bb?6a?08?26?4f?bd?8c?0c?8a?66?5d?5c

88

It is as follows that the SSL service end adopts above double certificate and client to carry out the data of two-way authentication:

New?TCP?connection#1：192.168.40.77(1186)<->192.168.40.212(443)

11?0.0349(0.0349)?C＞SV3.1(65)Handshake

ClientHello

Version?3.1

random[32]＝

43?3b?56?d4?c9?ab?45?5f?fc?32?6f?28?3b?18?6d?36

85?2b?46?58?e5?ad?19?0c?df?f7?14?58?7d?9c?27?36

cipher?suites

TLS_RSA_WITH_RC4_128_MD5

TLS_RSA_WITH_RC4_128_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_DES_CBC_SHA

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

TLS_RSA_EXPORT_WITH_RC_440_MD5

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS_DHE_DSS_WITH_DES_CBC_SHA

TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA

compression?methods

NULL

Packet?data[70]＝

16?03?01?00?41?01?00?00?3d?03?01?43?3b?56?d4?c9

ab?45?5f?fc?32?6f?28?3b?18?6d?36?85?2b?46?58?e5

ad?19?0c?df?f7?14?58?7d?9c?27?36?00?00?16?00?04

00?05?00?0a?00?09?00?64?00?62?00?03?00?06?00?13

00?12?00?63?01?00

12?0.0511(0.0161)?S＞CV3.1(42)Handshake

ServerHello

Version?3.1

random[32]＝

43?3b?55?8c?f4?e2?1c?f6?92?86?9b?36?35?0a?eb?5d

ff?2b?69?9f?e4?f9?b5?76?12?42?93?24?91?ec?16?aa

session_id[0]＝

cipherSuite TLS_RSA_WITH_RC4_128_MD5

compressionMethod NULL

Packet?data[47]＝

16?03?01?00?2a?02?00?00?26?03?01?43?3b?55?8c?f4

e2?1c?f6?92?86?9b?36?35?0a?eb?5d?ff?2b?69?9f?e4

f9?b5?76?12?42?93?24?91?ec?16?aa?00?00?04?00

13?0.0511(0.0000)?S＞CV3.1(669)Handshake

Certificate

Packet?data[674]＝

16?03?01?02?9d?0b?00?02?99?00?02?96?00?02?93?30

82?02?8f?30?82?01?f8?02?09?00?c4?35?7d?c3?03?64

e7?5a?30?0d?06?09?2a?86?48?86?f7?0d?01?01?05?05

00?30?81?87?31?0b?30?09?06?03?55?04?06?13?02?43

4e?31?0b?30?09?06?03?55?04?08?13?02?53?48?31?11

30?0f?06?03?55?04?07?13?08?53?68?61?6e?67?68?61

69?31?16?30?14?06?03?55?04?0a?13?0d?4b?6f?61?6c

20?53?6f?66?74?77?61?72?65?31?12?30?10?06?03?55

04?0b?13?09?53?53?4c?20?47?72?6f?75?70?31?0f?30

0d?06?03?55?04?03?13?06?74?65?73?74?63?61?31?1b

30?19?06?09?2a?86?48?86?f7?0d?01?09?01?16?0c?73

73?6c?40?6b?6f?61?6c?2e?63?6f?6d?30?1e?17?0d?30

35?30?39?32?39?30?32?34?30?31?32?5a?17?0d?30?35

31?30?32?39?30?32?34?30?31?32?5a?30?81?8f?31?0b

30?09?06?03?55?04?06?13?02?43?4e?31?0b?30?09?06

03?55?04?08?13?02?53?48?31?11?30?0f?06?03?55?04

07?13?08?53?68?61?6e?67?68?61?69?31?16?30?14?06

03?55?04?0a?13?0d?4b?6f?61?6c?20?53?6f?66?74?77

61?72?65?31?12?30?10?06?03?55?04?0b?13?09?53?53

4c?20?47?72?6f?75?70?31?17?30?15?06?03?55?04?03

13?0e?77?77?77?2e?6d?79?73?69?74?65?2e?63?6f?6d

31?1b?30?19?06?09?2a?86?48?86?f7?0d?01?09?01?16

0c?73?73?6c?40?6b?6f?61?6c?2e?63?6f?6d?30?81?9f

30?0d?06?09?2a?86?48?86?f7?0d?01?01?01?05?00?03

81?8d?00?30?81?89?02?81?81?00?c2?ed?5f?c6?09?f0

1a?8b?e8?3c?dc?1d?ac?2c?87?6b?5b?7b?63?cd?e3?a5

83?84?b1?d7?da?ab?5e?eb?81?00?82?98?2a?a3?74?3e

f9?4e?d1?14?89?1a?01?1d?24?3d?3a?0a?01?5b?ed?ff

87?99?c7?05?e6?7f?4f?1f?c3?fd?e5?59?10?9c?84?f9

df?8a?e6?6c?a9?8b?f9?41?ad?b1?c8?73?c2?b6?44?85

1a?10?ae?53?70?52?81?a6?fc?d2?6d?51?61?70?36?36

b9?91?08?b5?bd?20?da?2e?85?cd?af?ca?96?03?1b?94

97?7f?b4?6d?7a?14?70?8c?15?27?02?03?01?00?01?30

0d?06?09?2a?86?48?86?f7?0d?01?01?05?05?00?03?81

81?00?81?d2?91?78?10?79?fa?d3?32?98?8f?4f?42?6b

8e?df?ad?ef?b2?37?3d?16?4f?2f?ce?8b?94?c3?71?e1

16?c1?f8?83?3e?1a?a3?74?a0?12?9f?90?f1?5e?93?44

ff?fe?61?66?89?f2?ec?f7?fc?1f?c2?bf?d7?76?b4?74

2e?ed?96?68?7b?47?d3?e7?29?86?91?ea?11?c8?70?16

b2?11?0e?d8?c2?8f?4e?bb?8d?1c?8e?5b?3a?0b?c3?ea

d2?1a?9c?fa?4f?c2?68?80?e1?df?a3?c4?76?c7?06?d8

44?a6?4b?fb?fd?38?1c?93?2e?fc?d0?41?41?b7?a9?9b

5f?aa

14?0.0511(0.0000)?S＞CV3.1(269)Handshake

ServerKeyExchange

params

RSA_modulus[128]＝

d2?4c?b6?42?eb?e8?01?7b?65?87?dd?a6?c1?d2?a1?20

91?9f?0f?38?75?7f?4b?6d?1f?73?8b?13?73?fd?f2?f7

8b?1c?df?6f?44?a1?48?cc?0d?40?da?4c?73?62?9b?e6

6f?d3?e5?af?90?92?20?31?e5?b9?7d?a7?77?a1?15?17

be?de?65?cb?47?93?96?81?16?a2?83?e8?fc?db?a9?24

14?51?a0?ed?9a?4a?23?97?0c?bd?aa?cb?80?8a?c6?b2

7b?78?b3?71?6f?ac?cb?85?73?5c?16?2d?97?12?be?43

a1?6b?c9?6f?71?dc?49?ad?b3?e7?4c?9f?c0?f6?ac?81

RSA_exponent[3]＝

01?00?01

signature[128]＝

82?4d?5b?b8?a8?34?d5?e1?69?c6?14?43?20?27?06?19

0f?c0?d3?f6?29?93?e3?a1?a5?62?97?fe?a9?37?12?be

f0?e8?21?16?08?59?95?6d?ce?aa?91?df?f6?c5?1d?eb

02?6b?9b?dd?78?e4?e6?f6?f2?1a?88?f8?45?75?82?b8

e8?61?6e?bf?00?32?0a?28?73?40?b5?8b?52?2a?2d?c9

18?79?ad?b4?5a?d9?b8?89?f5?f6?08?54?a2?e5?94?fa

5c?53?31?e3?01?71?4f?c5?1d?48?45?33?2f?02?42?fb

bd?93?32?03?66?4f?5d?ed?d2?64?3b?ad?e9?40?3a?82

Packet?data[274]＝

16?03?01?01?0d?0c?00?01?09?00?80?d2?4c?b6?42?eb

e8?01?7b?65?87?dd?a6?c1?d2?a1?20?91?9f?0f?38?75

7f?4b?6d?1f?73?8b?13?73?fd?f2?f7?8b?1c?df?6f?44

a1?48?cc?0d?40?da?4c?73?62?9b?e6?6f?d3?e5?af?90

92?20?31?e5?b9?7d?a7?77?a1?15?17?be?de?65?cb?47

93?96?81?16?a2?83?e8?fc?db?a9?24?14?51?a0?ed?9a

4a?23?97?0c?bd?aa?cb?80?8a?c6?b2?7b?78?b3?71?6f

ac?cb?85?73?5c?16?2d?97?12?be?43?a1?6b?c9?6f?71

dc?49?ad?b3?e7?4c?9f?c0?f6?ac?81?00?03?01?00?01

00?80?82?4d?5b?b8?a8?34?d5?e1?69?c6?14?43?20?27

06?19?0f?c0?d3?f6?29?93?e3?a1?a5?62?97?fe?a9?37

12?be?f0?e8?21?16?08?59?95?6d?ce?aa?91?df?f6?c5

1d?eb?02?6b?9b?dd?78?e4?e6?f6?f2?1a?88?f8?45?75

82?b8?e8?61?6e?bf?00?32?0a?28?73?40?b5?8b?52?2a

2d?c9?18?79?ad?b4?5a?d9?b8?89?f?5f6?08?54?a2?e5

94?fa?5c?53?31?e3?01?71?4f?c5?1d?48?45?33?2f?02

42?fb?bd?93?32?03?66?4f?5d?ed?d2?64?3b?ad?e9?40

3a?82

15?0.0511(0.0000)?S＞CV3.1(222)Handshake

CertificateRequest

certificate_types rsa_sign

certificate_types dss_sign

certificate_types unknown?value

certificate_authority

30?58?31?0d?30?0b?06?03?55?04?06?1e?04?00?43?00

4e?31?19?30?17?06?03?55?04?08?1e?10?00?73?00?68

00?61?00?6e?00?67?00?68?00?61?00?69?31?11?30?0f

06?03?55?04?0a?1e?08?00?6b?00?6f?00?61?00?6c?31

19?30?17?06?03?55?04?03?1e?10?00?6e?00?65?00?77

00?73?00?75?00?62?00?63?00?61

certificate_authority

30?70?31?0d?30?0b?06?03?55?04?06?1e?04?00?43?00

4e?31?0d?30?0b?06?03?55?04?08?1e?04?00?73?00?68

31?0d?30?0b?06?03?55?04?07?1e?04?00?73?00?68?31

11?30?0f?06?03?55?04?0a?1e?08?00?6b?00?6f?00?61

00?6c?31?11?30?0f?06?03?55?04?0b?1e?08?00?74?00

65?00?73?00?74?31?1b?30?19?06?03?55?04?03?1e?12

00?52?00?4f?00?4f?00?54?00?43?00?41?00?47?00?45

00?4e

ServerHelloDone

Packet?data[227]＝

16?03?01?00?de?0d?00?00?d6?03?01?02?05?00?d0?00

5a?30?58?31?0d?30?0b?06?03?55?04?06?1e?04?00?43

00?4e?31?19?30?17?06?03?55?04?08?1e?10?00?73?00

68?00?61?00?6e?00?67?00?68?00?61?00?69?31?11?30

0f?06?03?55?04?0a?1e?08?00?6b?00?6f?00?61?00?6c

31?19?30?17?06?03?55?04?03?1e?10?00?6e?00?65?00

77?00?73?00?75?00?62?00?63?00?61?00?72?30?70?31

0d?30?0b?06?03?55?04?06?1e?04?00?43?00?4e?31?0d

30?0b?06?03?55?04?08?1e?04?00?73?00?68?31?0d?30

0b?06?03?55?04?07?1e?04?00?73?00?68?31?11?30?0f

06?03?55?04?0a?1e?08?00?6b?00?6f?00?61?00?6c?31

11?30?0f?06?03?55?04?0b?1e?08?00?74?00?65?00?73

00?74?31?1b?30?19?06?03?55?04?03?1e?12?00?52?00

4f?00?4f?00?54?00?43?00?41?00?47?00?45?00?4e?0e

00?00?00

16?0.0720(0.0209)?C＞SV3.1(2121)Handshake

Certificate

ClientKeyExchange

EncryptedPreMasterSecret[128]＝

b8?8c?92?e7?61?b0?56?07?bd?a9?dc?e0?6e?5b?cf?0b

c9?f8?cf?3a?9b?54?7c?16?5e?b2?d6?0f?a2?b3?ad?31

87?ee?91?19?c7?44?f0?d6?0d?c3?e7?2e?8f?37?5d?09

a4?9f?3e?72?25?60?aa?e6?59?eb?db?2e?27?b3?5c?67

17?ee?28?22?11?fd?4a?a9?ed?ac?e6?7b?10?0d?5a?f9

72?4a?a9?73?c5?0c?55?00?38?24?4f?d6?c5?e2?05?fb

08?14?59?ae?90?72?97?b8?d4?c3?70?a4?b1?15?72?d8

fe?d8?f9?af?34?da?c7?ca?74?14?e5?9a?a2?95?e4?f5

CertificateVerifv

Signature[64]＝

90?4c?de?b1?20?45?9a?5f?09?2b?a5?6a?2a?50?f8?cf

e2?5a?66?cc?15?b9?0a?8e?f3?0e?00?9e?31?b3?da?6c

5c?be?8b?d3?7d?70?b7?f5?3b?bd?f5?ed?6c?8d?3f?2e

31?22?23?da?b8?18?c8?e8?e8?9c?aa?44?6a?4d?d9?52

Packet?data[2126]＝

16?03?01?08?49?0b?00?07?79?00?07?76?00?03?f7?30

82?03?f3?30?82?03?5c?a0?03?02?01?02?02?0c?50?f3

4c?c7?f4?e3?1c?d5?e0?c7?3e?c6?30?0d?06?09?2a?86

48?86?f7?0d?01?01?05?05?00?30?58?31?0d?30?0b?06

03?55?04?06?1e?04?00?43?00?4e?31?19?30?17?06?03

55?04?08?1e?10?00?73?00?68?00?61?00?6e?00?67?00

68?00?61?00?69?31?11?30?0f?06?03?55?04?0a?1e?08

00?6b?00?6f?00?61?00?6c?31?19?30?17?06?03?55?04

03?1e?10?00?6e?00?65?00?77?00?73?00?75?00?62?00

63?00?61?30?1e?17?0d?30?35?30?39?32?33?30?31?35

31?32?37?5a?17?0d?30?37?30?39?32?33?30?31?35?31

32?37?5a?30?81?e3?31?11?30?0f?06?03?55?04?0a?1e

08?00?6b?00?6f?00?61?00?6c?31?0d?30?0b?06?03?55

04?07?1e?04?53?57?4e?ac?31?1f?30?1d?06?03?55?04

03?1e?16?00?77?00?75?00?78?00?69?00?6e?00?31?00

36?00?39?00?37?00?38?00?36?31?13?30?11?06?03?55

04?2a?1e?0a?00?77?00?75?00?78?00?69?00?6e?31?11

30?0f?06?03?55?04?0b?1e?08?00?74?00?65?00?73?00

74?31?27?30?25?06?09?2a?86?48?86?f7?0d?01?09?01

1e?18?00?77?00?75?00?78?00?40?00?6b?00?6f?00?61

00?6c?00?2e?00?63?00?6f?00?6d?31?0f?30?0d?06?03

55?04?08?1e?06?6c?5f?82?cf?77?01?31?0d?30?0b?06

03?55?04?06?1e?04?00?43?00?4e?31?2d?30?2b?06?03

55?04?01?1e?24?00?33?00?30?00?34?00?35?00?37?00

32?00?33?00?30?00?34?00?38?00?39?00?35?00?37?00

30?00?32?00?33?00?38?00?39?30?5c?30?0d?06?09?2a

86?48?86?f7?0d?01?01?01?05?00?03?4b?00?30?48?02

41?00?9c?63?86?ad?d1?b8?ce?3f?53?fb?20?fa?9d?3a

27?c0?08?a0?db?83?ea?25?7f?71?e4?38?97?78?79?46

00?d0?9d?6a?78?4b?56?5d?bc?d4?6c?3b?89?a7?1d?95

a3?51?58?90?0c?27?97?7b?41?7b?7a?30?3d?d2?4a?1d

a4?89?02?03?01?00?01?a3?82?01?78?30?82?01?74?30

0f?06?03?55?1d?13?01?01?00?04?05?30?03?01?01?00

30?0e?06?03?55?1d?0f?01?01?00?04?04?03?02?00?e8

30?16?06?03?55?1d?25?01?01?00?04?0c?30?0a?06?08

2b?06?01?05?05?07?03?02?30?81?b4?06?03?55?1d?1f

01?01?00?04?81?a9?30?81?a6?30?68?a0?66?a0?64?a4

62?30?60?31?0f?30?0d?06?03?55?04?0a?13?06?6b?6f

61?6c?63?61?31?1c?30?1a?06?03?55?04?0b?13?13?43

52?4c?44?69?73?74?72?69?62?75?74?65?50?6f?69?6e

74?73?31?11?30?0f?06?03?55?04?0b?13?08?6e?65?77

73?75?62?63?61?31?1c?30?1a?06?03?55?04?03?13?13

65?6e?74?69?74?79?69?64?31?33?67?72?6f?75?70?69

64?31?30?30?3a?a0?38?a0?36?86?34?68?74?74?70?3a

2f?2f?77?77?77?2e?6b?6f?61?6c?2e?63?6f?6d?2f?64

6f?77?6e?6c?6f?61?64?2f?65?6e?74?69?74?79?69?64

31?33?67?72?6f?75?70?69?64?31?30?2e?63?72?6c?30

81?81?06?08?2b?06?01?05?05?07?01?01?01?01?00?04

72?30?70?30?36?06?08?2b?06?01?05?05?07?30?02?86

2a?68?74?74?70?3a?2f?2f?77?77?77?2e?6b?6f?61?6c

2e?63?6f?6d?2f?64?6f?77?6e?6c?6f?61?64?2f?52?4f

4f?54?43?41?47?45?4e?2e?63?65?72?30?36?06?08?2b

06?01?05?05?07?30?02?86?2a?68?74?74?70?3a?2f?2f

77?77?77?2e?6b?6f?61?6c?2e?63?6f?6d?2f?64?6f?77

6e?6c?6f?61?64?2f?52?4f?4f?54?43?41?47?45?4e?2e

63?65?72?30?0d?06?09?2a?86?48?86?f7?0d?01?01?05

05?00?03?81?81?00?55?49?fc?18?51?96?52?6b?12?99

a8?28?92?da?2f?93?90?f6?24?27?ba?b3?21?17?36?85

a4?18?3d?67?ff?97?4e?77?df?81?32?d6?86?de?c1?b3

42?f9?fe?72?82?7e?37?30?dd?21?1e?24?b1?e0?94?f3

ff?61?e3?4c?32?0c?1f?48?c6?09?58?c3?31?93?9c?06

0c?25?30?52?a9?bb?ef?56?8f?02?d9?d1?b4?66?06?97

c0?bc?aa?77?49?32?db?2a?2e?68?f8?9a?c2?e1?d7?b5

f3?82?99?a0?4f?7e?30?88?dd?0b?95?a8?95?8f?e8?50

0a?b4?5a?a8?69?6a?00?03?79?30?82?03?75?30?82?02

de?a0?03?02?01?02?02?0c?26?b0?57?3f?02?89?2f?2b

6f?29?33?0e?30?0d?06?09?2a?86?48?86?f7?0d?01?01

05?05?00?30?70?31?0d?30?0b?06?03?55?04?06?1e?04

00?43?00?4e?31?0d?30?0b?06?03?55?04?08?1e?04?00

73?00?68?31?0d?30?0b?06?03?55?04?07?1e?04?00?73

00?68?31?11?30?0f?06?03?55?04?0a?1e?08?00?6b?00

6f?00?61?00?6c?31?11?30?0f?06?03?55?04?0b?1e?08

00?74?00?65?00?73?00?74?31?1b?30?19?06?03?55?04

03?1e?12?00?52?00?4f?00?4f?00?54?00?43?00?41?00

47?00?45?00?4e?30?1e?17?0d?30?35?30?39?30?34?31

38?33?34?34?38?5a?17?0d?31?36?30?38?31?37?31?38

33?34?34?38?5a?30?58?31?0d?30?0b?06?03?55?04?06

1e?04?00?43?00?4e?31?19?30?17?06?03?55?04?08?1e

10?00?73?00?68?00?61?00?6e?00?67?00?68?00?61?00

69?31?11?30?0f?06?03?55?04?0a?1e?08?00?6b?00?6f

00?61?00?6c?31?19?30?17?06?03?55?04?03?1e?10?00

6e?00?65?00?77?00?73?00?75?00?62?00?63?00?61?30

81?9f?30?0d?06?09?2a?86?48?86?f7?0d?01?01?01?05

00?03?81?8d?00?30?81?89?02?81?81?00?aa?46?c7?f0

a0?69?5e?a2?dd?f6?2f?72?5f?ea?cd?6c?1d?c2?2a?1e

8d?e0?e6?43?cd?46?98?a8?96?ea?73?32?4f?da?a1?d4

dd?cb?b4?b9?29?19?48?7e?84?62?40?24?31?05?a9?d5

d4?4a?b9?d9?5b?63?dd?ad?c8?b0?ec?17?8a?e2?3a?39

5b?69?81?7c?a9?8e?54?46?bf?c5?07?85?fa?4e?ba?70

09?98?f9?55?64?cf?21?30?ab?ef?82?32?37?a2?3f?87

c2?56?7b?a6?85?03?55?31?b4?82?2a?38?f3?d1?07?6f

45?5b?fd?3c?ab?df?fe?55?c3?34?09?5d?02?03?01?00

01?a3?82?01?2a?30?82?01?26?30?0e?06?03?55?1d?0f

01?01?00?04?04?03?02?00?86?30?0f?06?03?55?1d?13

01?01?00?04?05?30?03?01?01?ff?30?81?a1?06?03?55

1d?1f?01?01?00?04?81?96?30?81?93?30?5f?a0?5d?a0

5b?a4?59?30?57?31?0f?30?0d?06?03?55?04?0a?13?06

6b?6f?61?6c?63?61?31?1c?30?1a?06?03?55?04?0b?13

13?43?52?4c?44?69?73?74?72?69?62?75?74?65?50?6f

69?6e?74?73?31?12?30?10?06?03?55?04?0b?13?09?52

4f?4f?54?43?41?47?45?4e?31?12?30?10?06?03?55?04

03?13?09?52?4f?4f?54?43?41?47?45?4e?30?30?a0?2e

a0?2c?86?2a?68?74?74?70?3a?2f?2f?77?77?77?2e?6b

6f?61?6c?2e?63?6f?6d?2f?64?6f?77?6e?6c?6f?61?64

2f?52?4f?4f?54?43?41?47?45?4e?2e?63?72?6c?30?14

06?09?60?86?48?01?86?f8?42?01?01?01?01?00?04?04

03?02?00?04?30?49?06?08?2b?06?01?05?05?07?01?01

01?01?00?04?3a?30?38?30?36?06?08?2b?06?01?05?05

07?30?02?86?2a?68?74?74?70?3a?2f?2f?77?77?77?2e

6b?6f?61?6c?2e?63?6f?6d?2f?64?6f?77?6e?6c?6f?61

64?2f?52?4f?4f?54?43?41?47?45?4e?2e?63?65?72?30

0d?06?09?2a?86?48?86?f7?0d?01?01?05?05?00?03?81

81?00?39?13?02?e5?84?0b?d5?86?3e?f6?70?fe?81?b8

df?a2?5a?77?9f?ff?fa?ac?01?66?04?b5?8b?58?39?82

36?44?1d?b8?f7?04?73?82?81?43?6d?46?8a?39?e0?16

b8?71?7e?48?ca?32?be?8a?b5?15?fa?ba?5d?1b?2c?ba

df?df?8e?6f?a3?f6?df?27?5b?48?e5?09?cc?0a?a2?af

0c?6f?c6?c6?2b?3c?94?9a?1f?04?65?63?68?fd?c9?d7

33?54?9b?66?51?ca?5d?a3?14?cd?9c?13?cc?e8?28?21

6a?b4?35?98?31?2d?17?3e?fd?86?06?c2?79?09?03?db

8f?84?10?00?00?82?00?80?b8?8c?92?e7?61?b0?56?07

bd?a9?dc?e0?6e?5b?cf?0b?c9?f8?cf?3a?9b?54?7c?16

5e?b2?d6?0f?a2?b3?ad?31?87?ee?91?19?c7?44?f0?d6

0d?c3?e7?2e?8f?37?5d?09?a4?9f?3e?72?25?60?aa?e6

59?eb?db?2e?27?b3?5c?67?17?ee?28?22?11?fd?4a?a9

ed?ac?e6?7b?10?0d?5a?f9?72?4a?a9?73?c5?0c?55?00

38?24?4f?d6?c5?e2?05?fb?08?14?59?ae?90?72?97?b8

d4?c3?70?a4?b1?15?72?d8?fe?d8?f9?af?34?da?c7?ca

74?14?e5?9a?a2?95?e4?f5?0f?00?00?42?00?40?90?4c

de?b1?20?45?9a?5f?09?2b?a5?6a?2a?50?f8?cf?e2?5a

66?cc?15?b9?0a?8e?f3?0e?00?9e?31?b3?da?6c?5c?be

8b?d3?7d?70?b7?f5?3b?bd?f5?ed?6c?8d?3f?2e?31?22

23?da?b8?18?c8?e8?e8?9c?aa?44?6a?4d?d9?52

17?0.0720(0.0000)?C＞SV3.1(1)ChangeCipherSpec

Packet?data[6]＝

14?03?01?00?01?01

18?0.0720(0.0000)?C＞SV3.1(32)Handshake

Packet?data[37]＝

16?03?01?00?20?86?02?0a?c9?43?85?5e?74?e3?fc?6b

78?b0?da?80?65?a7?74?70?c8?92?21?01?9a?e3?df?ff

1e?44?fc?fb?a2

19?0.0953(0.0232)?S＞CV3.1(1)ChangeCi?pherSpec

Packet?data[6]＝

14?03?01?00?01?01

110?0.0953(0.0000)?S＞CV3.1(32)Handshake

Packet?data[37]＝

16?03?01?00?20?ef?f5?0a?69?ad?be?6a?47?39?61?d2

4d?d6?a2?47?dc?00?6d?dc?07?f0?5a?96?62?f9?ae?a3

a5?ed?8b?e8?1d

111?0.1100(0.0146)?C＞SV3.1(235)application_data

Packet data[240]＝

17?03?01?00?eb?21?18?6c?a4?b3?ff?7b?6a?d8?ee?01

04?a5?7d?56?e0?33?74?89?d0?3a?a2?0d?35?d1?4e?7e

24?00?c6?50?85?53?c3?a6?ea?a4?da?1c?e9?7c?b5?ce

69?e5?a4?06?0e?a9?ad?df?92?5c?a5?c6?52?bc?f9?77

d6?e7?e9?d2?b4?f4?77?12?d2?e7?81?4a?ae?4b?17?fb

e4?da?f5?ee?21?b1?27?2c?df?0a?32?49?c7?7a?a6?94

44?88?70?45?1a?81?98?11?a7?7a?72?6c?66?5d?da?fa

0b?16?c5?9a?ef?11?87?6d?4b?05?c1?8d?9e?58?44?17

1f?aa?39?3d?7c?1f?96?d2?38?f8?1f?93?70?32?73?2b

96?6f?a3?62?e6?bd?1e?b1?53?f2?87?a0?8c?8b?1a?d8

8f?6b?fe?32?df?f9?39?c8?bc?67?a6?27?a1?1a?5d?78

46?49?af?8d?cf?e0?0e?d6?5f?07?a1?8f?d9?5a?57?fc

fc?2e?6b?bf?8a?34?35?e5?af?79?9f?b1?ad?36?d7?5f

85?b2?b5?36?2d?bc?67?f7?aa?99?b9?dd?ca?41?f6?c7

36?20?0e?89?cb?8a?61?8d?8a?62?47?e7?69?30?3f?66

Claims (4)

1, the application process of a kind of double certificate in ssl protocol, comprise the ssl protocol flow process the institute in steps, it is characterized in that: in the described ssl protocol flow process, the employed website certificate of service end is a double certificate, wherein a certificate is a signing certificate, another certificate is an encrypted certificate, and two certificates all meet X.509 series standard certificate format; And utilize Server KeyExchange handshake information, and the interim RSA PKI that produces is wherein replaced with the PKI of encrypted certificate in the double certificate, client is used the public key encryption pre_master_secret of this encrypted certificate.

2, the application process of a kind of double certificate as claimed in claim 1 in ssl protocol is characterized in that: comprise double certificate application process under the ssl protocol unidirectional authentication and the double certificate application process under the ssl protocol two-way authentication mode.

3, the application process of a kind of double certificate as claimed in claim 2 in ssl protocol, it is characterized in that: the double certificate application process under the described ssl protocol unidirectional authentication comprises following flow process:

[1], client sends ClientHello message to service end, information has comprised the version number of agreement, cryptographic algorithm that client is supported, compression algorithm and the key generative process random number as input;

[2], service end sends ServerHello message to client according to the information of client, information comprises version number, cryptographic algorithm, compression algorithm and random number as the input of key generative process of selecting from ClientHello information;

[3], service end sends Certificate message to client, information is the website signing certificate of service end;

[4], service end uses the private key of website signing certificate that the PKI of website encrypted certificate is signed, form ServerKeyExchange information and send to client;

[5], service end sends ServerHelloDone message to client, show that information has sent to finish;

[6], client verifies that to the signing certificate of service end the service end website certificate that use was verified is verified the public key signature of service end website encrypted certificate; Client produces the pre_master_seceret key at random, uses the PKI of the encrypted certificate of service end to encrypt, and forms ClientKeyExchange information and sends to service end;

[7], client sends ChangeCipherSpec message to service end, shows that to service end algorithm and key agreement finish;

[8], client uses key algorithm to calculate master_seceret according to client random number, service end random number, pre_master_seceret, and then use random number and master_seceret to calculate real data encryption key, then all handshake information summary back encryptions are formed Finished message and send to service end;

[9], service end is used website encrypted certificate private key deciphering pre_master_seceret, adopt same algorithm computation master_seceret and the data encryption key of client, the correctness of checking Finished message, send ChangeCipherSpec message to client, algorithm and key agreement express one's approval;

[10], service end sends all handshake information summary back encryption formation Finished message to client;

[11], client and service end are used the secret key encryption application data that negotiation calculates respectively.

4, the application process of a kind of double certificate as claimed in claim 2 in ssl protocol is characterized in that: the double certificate application process of described ssl protocol under authentication mode comprises following flow process:

[1], client sends ClientHello message to service end, information has comprised the version number of agreement, cryptographic algorithm that client is supported, compression algorithm and the key generative process random number as input;

[2], service end sends ServerHello message to client according to the information of client, information comprises version number, cryptographic algorithm, compression algorithm and random number as the input of key generative process of selecting from ClientHello information;

[3], service end sends Certificate message to client, information is the website signing certificate of service end;

[4], service end sends CertificateRequest message indication client and carries out client certificate, indicated auth type (RSA) simultaneously;

[5], service end uses the private key of website signing certificate that the PKI of website encrypted certificate is signed, form ServerKeyExchange information and send to client;

[6], service end sends ServerHelloDone message to client, show that information has sent to finish;

[7], client verifies that to the signing certificate of service end send Certificate message after checking is passed through, information is client's signing certificate;

[8], client uses the service end website certificate of verifying that the public key signature of service end website encrypted certificate is verified; Client produces the pre_master_seceret key at random, uses the PKI of the encrypted certificate of service end to encrypt, and forms ClientKeyExchange information and sends to service end;

[9], client uses the private key of signing certificate that the summary of handshaking information is signed, form CertificateVerify message and send to service end; Client sends ChangeCipherSpec message to service end, shows that to service end algorithm and key agreement finish;

[10], client uses key algorithm to calculate master_seceret according to client random number, service end random number, pre_master_seceret, and then use random number and master_seceret to calculate real data encryption key, then all handshake information summary back encryptions are formed Finished message and send to service end;

[11], service end checking client certificate, use the signature of the formal checking client of client; Service end is used website encrypted certificate private key deciphering pre_master_seceret, adopt same algorithm computation master_seceret and the data encryption key of client, the correctness of checking Finished message, send ChangeCipherSpec message to client, algorithm and key agreement express one's approval;

[12], service end sends all handshake information summary back encryption formation Finished message to client;

[13], client and service end are used the secret key encryption application data that negotiation calculates respectively.

Images