On the multi-level certificate based on OpenSSL, the issuance and management of multi-level Ca, and two-way authentication

Recent research openssl grant a certificate , Search the Internet for information about openssl Usage of 、 Information and so on , Always feel very scattered , And it's shallow , Although there are many articles , But lack of clarity that can really tell you , Just stay in “ It works ” On , Sigh with emotion , This how line , In the end, we do not understand or keep it secret ？

It is suggested to have a brief understanding of ：

tls The concept of 、 The process and difference between one-way authentication and two-way authentication 、 digital certificate 、CA Role of the organization 、openssl

1、 Do you need multi-level certificates ？

There are two core problems ：

a、 Do you need two-way authentication ？

The business cases I've seen , The customer accesses a service on the public network , Issue a certificate directly by yourself , On the server side , Customer https There's nothing wrong with the interview , Customers don't care much . But if your background service is to provide an interface to other companies , And customers require two-way authentication ？ Can you just have a server certificate ？

b、 Do you need multi-level ？

Or the example above , My backstage gives customers two-way authentication , I can build a root certificate by myself , The root certificate directly issues the server and client certificates , Then the server certificate will be given to myself , The client and root certificates are handed over to other companies , It can also be realized ？ Why do you need multi-level ？

2、 Why should there be multi-level certificates ？

I don't know how to analyze the theory , There are probably a few statements ：a、 Root certificate as the most authoritative 、 The certificate that needs confidentiality most , Be sure to be offline to ensure its security , Therefore, only the middle layer certificate is exposed , In this way, even if the intermediate certificate is accidentally lost , Can also rebuild a new middle tier Certificate .b、 And as a certificate of mutual recognition on the Internet , If it is all a root certificate to issue a set of client-side and server-side certificates of the product , How many root certificates do you need ？ That's too much , Out of control .c、 standard , standard , still tmd standard ！ Manage your multi-level certificates , Blow security away , It can be regarded as a technical threshold , Make your competitors shake their heads .

Another angle , From the results ： Now open the browser to see the certificate , Aren't they all multi-level certificates ？ There are still some 4 level , No matter why , Anyway, that's how it works in practical commercial applications .

3、 How can multi-level certificates be issued ？

does openssl or openssl Encapsulation , Say the pros and cons ：

Use native openssl：

advantage ： Functions can be customized , Capacity ceiling height , If you use it well, you can even write it on your resume

Inferiority ： You need to have a certain understanding of the certificate 、 Need to be right openssl Have a good understanding of the configuration file

be based on openssl Encapsulation ： for example easyrsa or xca

advantage ： It's easy to operate , Professional knowledge is not required , Simple scenes are friendly to novices

Inferiority ： Can't operate in batch , Poor customization , Difficult to integrate

After reading the advantages and disadvantages , The results are clear , Still be honest and practical openssl, Although it's a little difficult , Who asked your boss to pay you to study this ？ About one 1 Just a month , But it's best to turn Q Go to goo9le once .CSDN Now the quality is getting worse and worse .

4、 How are multi-level certificates used in enterprise applications （ User scenarios ）

Product side ：

Common structures of multi-level certificates, such as ： Root certificate —— Middle tier certificate —— Server side / Client certificate , there “A——B” Express “A yes B The upper certificate of ” perhaps “A Issued B”

This is the specific structure of the certificate , And for the issue subject , Structure is ： Authority at the top CA Institutions —— middle CA Institutions —— client / Server side . there “A——B” Express "A Responsible for auditing B And confirm whether it should be issued B Certificate "

The root certificate and the middle layer certificate are not used in our products , The final interaction and verification is the client and server certificates , Both the top-level certificate and the middle-level certificate are used to assist in verifying the presentation “ There is indeed an authority that knows you two （ Client and server ） Of a certificate ”.

Market side ：

Secure access to the public network ： If your company's products want to be safely accessed on the public network , for example HTTPS, Then you need to get your company's certificate to the authority （ Such as Global Sign） Go and verify , The authority will sign your certificate with its private key （Global Sign That's the money ）, The material you get back is your server certificate , Future customers pass https Visit your company's product background , Your background will first send this certificate to the customer in the handshake stage , The customer's computer has been installed with the root certificate of the authority at the time of production , The client's browser uses its own public key to verify the certificate , Verify that this certificate is indeed issued by the root certificate preset in your computer , Then this certificate is valid , This completes the verification of the certificate issued by the server to the client .

Secure server access ： This refers to the secure access between background services , Secure access is also required between services , Then multi-level certificate authentication is a technical threshold , This one mentioned earlier , Don't say （ Our overseas projects have such requirements ）

5、 How to issue multi-level certificates ？

I won't talk about the specific operation , The significance of this article does not lie in this , But to communicate with you, we are building our own CA Problems encountered when designing the scheme .

I signed the root certificate myself anyway 、 Issue the m-server certificate based on the root certificate , M-server certificate issuing client 、 Server side , Wrote a shell, hold openssl The command line encapsulates , Otherwise, you need to knock it manually every time , It's too troublesome .

Some schemes for building multi-level certificates can be found on the Internet , But some orders are clearly wrong , But everyone is feeling the stone to cross the river , There is really no way to judge whether the certificate issued by yourself meets the requirements , How do you tell your leader “ I finished ”？ It's time to use , Suddenly found that the certificate cannot be used , There is no way to find a problem and locate it , It's too passive .

Here I recommend a video , On the Internet , Go over the wall and see （ Must see ）：

https://www.youtube.com/watch?v=d8OpUcHzTeg&list=PLkHWn6amxm3v1HomqB7RxkhQxTNDm_YkF&index=1&t=1371shttps://www.youtube.com/watch?v=d8OpUcHzTeg&list=PLkHWn6amxm3v1HomqB7RxkhQxTNDm_YkF&index=1&t=1371s

6、 What is a certificate chain

The certificate chain is said on the Internet , What is it , I didn't make it clear , There are two ways to understand the certificate chain ：

a、 In a broad sense , A chain is formed due to the issuing relationship of certificates , And the subsequent verification is carried out step by step from the end , Finally, we found that the root certificate is preset and trusted , So this chain is called “ Certificate chain ”, Most of the certificate chains on the Internet are generalized certificate chains .

b、 Specific understanding , The certificate chain is a file , Now whether it's java Framework 、curl Parameters 、openssl Client tools , Will let you specify a certificate file , Then the certificate file should be a certificate chain , How to make , It's simple , Just append a certificate file to the next Certificate , This is the certificate chain . But with what certificate 、 Which certificate comes first ？ They are all exquisite . Next 8 Let's move on to the next question .

7、 What does it look like when a multi-layer certificate is generated ？

Get a few files ：

Root certificate related ：root.crt、root.key

M-server certificate related ：intermediate.crt、intermediate.key

Client certificate ：client.crt、client.key

Server certificate ：server.crt、server.key

8、 How to verify the validity of these certificates ？

Usable Tools Yes ：

Server side ： Use nginx Turn on the two-way authentication function 、openssl Of s_server Tools 、 Internet search C It's based on openssl The service side 、java Ready made bag ,python Of ssl The package implements itself .

client ：curl Tools 、openssl Of s_client Tools 、 Internet search C It's based on openssl The client of 、java Ready made bag 、python Of ssl The package implements itself .

No more specific orders , According to the online order, the detailed explanation or documents are more or less quickly understood . Let's talk about the problem of certificate chain , These tools are on the server side 、 Almost without exception, the client must have three parameters ：

Parameters	name	effect
CAfile（ It's also called cacert Of ）	Trust authority certificate	Root certificate , Verify whether the certificate is issued by an authority
cert	client / Server certificate	Used in ssl Certificate for exchange verification in handshake phase
key	client / Server private key	A key used for symmetric encryption

The problem lies in ,cafile Who is it? ？cert Who is it? ？key Who is it? ？

Let me start with my conclusion ：“key Must be with cert The first certificate in ,cert May be server.crt+intermediate.crt or server.crt,cafile May be intermediate.crt+root.crt or root.crt”, Let's talk about it separately ：

key Must be with cert The first certificate in

If cert yes server.crt, that key Namely server.key This is easy to understand , If cert yes server.crt + intermediate.crt, Then it must be intermediate Append to server Behind , In this way, the service can start normally .

cert May be server.crt+intermediate.crt or server.crt

cert by server.crt The situation of , Just like the video tutorial I posted earlier , Server use openssl s_server, Appoint CA File for intermediate.crt,cert yes server.crt,key yes server.key, Client side usage curl No certificate specified , But because he manually root.crt Add to linux Trust anchors in the system , Therefore, it is equivalent to specifying root.crt, But notice , If he does not specify the client certificate , Then his communication must be one-way Authentication .

server.crt+intermediate.crt The situation of , The last demonstration of this video is like this one , Server use nginx, Appoint CA File for root.crt,cert yes server.crt+intermediate.crt,key yes server.key. The client is still curl, Still one-way Authentication .

cafile May be intermediate.crt+root.crt or intermediate.crt

I also saw a good one on the Internet C Implemented client 、 Server side , I posted the link

Openssl Implementation of two-way authentication tutorial （ With server client code ） - cloud + Community - Tencent cloud A recent product test report suggested that the product based on pki Method of authentication , Because the product has been realized https, After discussion, I think it means to use two-way authentication to deal with man in the middle attack .https://cloud.tencent.com/developer/article/1726029 Go up and get the code yourself , This code , It's two-way authentication , When the server starts ,CA The file must be specified as intermediate.crt+root.crt,cert File for server.crt,key File for server.key. On client startup ,CA The file must be specified as intermediate.crt+root.crt,cert File for client.crt,key File for client.key.

in addition , Use openssl s_server and s_client, It is also specified in this way , By the way, I'll post the order ：
 

openssl s_server -accept 443 -key server/private/server.key -cert server/certs/server.crt  -CAfile intermediate/certs/intermediate_root.crt -state -WWW 
openssl s_client -connect 127.0.0.1:443  -CAfile intermediate/certs/intermediate_root.crt -cert client/certs/client.crt -key client/private/client.key -showcerts 

For designated CAfile by intermediate.crt Of , So far, only in linux Under the curl The one-way authentication scenario can .

Conclusion ：

Stepping on the pit , You still have to try more , If you have time to add something about certificate revocation later