OpenSSL gen RSA-out ca . key 1024
We don't use des3 encryption here. You can add a -des3 parameter encryption, please refer to man genrsa for details).
OpenSSL req-new-x509-days 36500-key ca . key-out ca . CRT
(This step requires entering a lot of information at the prompt, including country code, province, city, company name, etc. )
Generate server-side private key:
OpenSSL gen RSA-out server . key 1024
Generate a req file on the server side (the req file generated in this step contains a public key certificate, plus identity information, such as country, province, company, etc. Submit it to ca for signature):
OpenSSL req- new key server
Sign the server's req file with CA's private key to get the server's certificate:
OpenSSL x509-req-days 3650-in server . CSR-CA CA . CRT-CAkey CA . key-cacreate serial-out server . CRT
(Note: If you use openssl for the first time, the report can't find some related files, so you may need to execute two commands first: touch /etc/pki/CA/index.txt and echo' 01'>/etc/PKI/CA/serial).
The server.crt obtained above is the certificate file of the server. (There are many softwares that require different certificate storage formats and may require various transformations. Such as PEM, P 12, etc. We also need to make a little transformation in our scene, which will be described below. Students who just started doing this may find the certificate and format confusing. What you can do at this time is to calm down and patiently understand the principles of TLS, RSA and so on. Look at the man documentation of openssl.
I don't know whether it is appropriate to CAll ca.crt the certificate file of ca, but what is certain is that the client can verify the identity of the server by using ca.crt, and the server will issue its own certificate during the SSL/TLS handshake, which is signed by ca. Ca uses its own private key when signing, and ca.crt contains CA's public key, which can be used to check this signature and confirm whether it is signed by itself.
The files that the server needs to use are: server private key and server certificate.
The files that the client needs to use are: ca file (CA certificate, which is used to verify the certificate issued by the server).
Our server uses java and uses a certificate in the format of p 12(PKCS 12). Openssl can be used for format conversion:
OpenSSL pkcs 12-export-clcerts-in server . CRT-in key server . key-out server . p 12
You can see that the output server.p 12 should contain the contents of server.key and server.crt
Our C language client directly uses CA file: ca.crt 。
We also wrote the client in java, which uses the CA file format as jks. Then a transformation may be needed, and the keytool in java's bin directory is used here:
keytool-import cert-alias CA-file CA . CRT-keystore CA . jks
Password is required for conversion. In this way, the ca.crt is converted into the ca.jks format.
Part of the code of socket server and java client is attached below. C will not be posted, use matrixssl.
Java server (mina) code snippet:
string file = "/file/path/server . p 12 "；
string key type = " pkcs 12 "； char[] password = "passwd "。 toCharArray()；
KeyStore ks = KeyStore . getinstance(key type)；
Ks.load (new file input stream (file), password);
KeyManagerFactory kmf = KeyManagerFactory . getinstance(
key manager factory . get default algorithm())；
Kmf.init(ks, password);
SSL context CTX = SSL context . getinstance(" TLS ")；
CTX . init(kmf . getkey manager()、null、null)；
SslFilter sslFilter = new sslfilter (CTX); Just add this filter to Mina's aeptor.
aeptor.getFilterChain()。 addLast("ssl "，new SSL filter(createsl context()))；
Java client (mina) code fragment: truststringfile = "/data/tmp/ca.jks";
String keyType = " jkschar[] password = " 123456 "。 toCharArray()；
KeyStore ks = KeyStore . getinstance(key type)；
Ks.load (new file input stream (file), password);
Trust Management Factory tmf = Trust Management Factory
. getInstance(trustmanagerfactory . getdefaultalgorithm())；
tmf . init(ks)；
SSL context SSL context = SSL context . getinstance(" TLS ")；
sslContext.init(null，tmf.getTrustManagers()，null)；
SslFilter sslFilter = new sslfilter (sslcontext);
SSL filter . setuseclientmode(true)； The server is addLast, but this is addFirst. This order can't be wrong
connector.getFilterChain()。 addFirst("sslFilter "，SSL filter)；
What is the difference between a self-generated ssl certificate and a purchased ssl certificate? 1. The self-generated ssl certificate is illegal and unverified. The purchased SSL certificate is an SSL certificate issued by CA institutions such as WoSign CA, and CA institutions must pass the international webtrust certification and electronic distribution law.
2. The browser does not trust the SSL certificate generated by itself, which will prevent access; The purchased SSL certificate is trusted by the browser, showing a green security lock;
3. Self-generated SSL certificates are easy to be forged and counterfeited, attacked by middlemen and unsafe. The purchased SSL certificate is more secure and credible.
For example:
Self-generated SSL certificates, just like self-made ID cards, can't be approved by anyone and institutions.
The purchased SSL certificate, just like the ID card issued by the Public Security Bureau, is globally recognized, and shopping, credit card and accommodation have passed smoothly. If you violate discipline, the Public Security Bureau can find your ID card revoked or marked.