The two parties of two-way certificate authentication are called client and server. Certificates are first generated for client and server. Since you are just learning to use it yourself, you can build a CA locally, and then use the CA's certificate to issue the client and server certificates respectively. The creation and issuance of CAs uses OpenSSL.

Install OpenSSL in the windows environment, and then create the corresponding folders and files according to the configuration of [CA_default] in openssl.cnf in the OpenSSL directory

The serial file can be initially written Enter a row of records, including the two characters 01, indicating that the serial number used in the next issued certificate is 01

Next, generate the CA's own public/private key and generate a certificate signing request (CSR , Certificate Signing Request) file and self-sign the request

Run in the root directory of openssl

genrsa —- Generate public key and private key at the same time

Many people interpret genrsa as only generating private keys, which is wrong. You can use the following command to extract the public key from the file

Note that the last number 2048 represents the length of the generated RSA public and private keys

Certificate check in JDK7 requires the minimum length of the public key is 1024 bits, otherwise an exception will be thrown

java.security.cert.CertPathValidatorException: Algorithm constraints check failed

The length limit is configurable, and the configuration file path is JAVA_HOME/jre /lib/security/java.security

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

Then use the public and private key files generated above to create a certificate signing request file

req —- Create a CSR or certificate

-key —- openssl reads the private key from this file

The content format of careq.pem is

Finally, the request file will be signed by the CA organization, but now we want to build a CA locally, so we can self-sign the file ourselves.

In fact, the above two steps of generating the CSR and then doing the self-signing can be combined into one step.

At this point, we have established our own CA. Next, we will sign the client and server respectively. certificate.

Take creating a client certificate as an example. Since the keytool tool that comes with jdk can easily create key stores and public and private keys, the public and private keys and csr are created directly using keytool

The key store and trust store respectively correspond to their own certificates in the SSL handshake certificate authentication. The file formats of the two are the same as the list of certificates you trust. The difference is that the key store contains the public and private keys and certificates of the SSL handshake party. The trust store contains the certificates trusted by the SSL handshake party. Generally, these certificates do not correspond to The private key

In the client certificate, we want to add an extension of the certificate, such as client id, to distinguish the identity of the client, so an additional extension file client.cnf is needed, the content is as follows

Before importing, you need to import the CA's certificate into the keystore file

and then import the client's own certificate. Note that alias is a client and must match the production keystore and key pair

You can view the contents of the keystore file using

or use the visualization tool KeyStore Explorer

Because The server's certificate is also issued by the local CA, so as long as the client trusts the CA's certificate, it will naturally trust the certificate issued by the CA, so we only need to import the CA's certificate into the trust store

Since clienttruststore.keystore The file does not exist yet. This command first creates the file and imports the CA's certificate into the trust store

Since netty 5 now only has an alpha version, use the 4.0.24.final version of netty to be on the safe side.

Netty's SSLContext provides newClientContext to create an SSL context for the client. However, looking at its source code, it is not found that it supports two-way authentication. That is, the SSL context on the client side only receives a trust store and cannot specify its own certificate. Server-side verification. Modeled after the securechat ssl implementation under the netty example but with modifications

First create a tool class that can provide the ssl context of the client and server, and load the certificates in the key store and trust store of the server and client respectively< /p>

The constructor of the io.netty.example.securechat.SecureChatClientInitializer class receives an object of type io.netty.handler.ssl.SslContext. This SslContext object is ultimately used to create the SslHandler, and the one generated by the factory above It is the object of javax.net.ssl.SSLContext, so you can make the following changes

Finally, add the jvm parameter

to view the log of the SSL handshake process console

Please refer to the attached source code for specific implementation.

Modify in file

unique_subject=no

[ policy_match ]

countryName = match

organizationName = match

organizationalUnitName = optional

commonName = supplied

emailAddress = optional