openssl SSL is the most popular password database tool that provides a common, robust, full-featured suite of tools to support implementation of SSL / TLS protocol.
The following is the official experimental test generation process and do basic simulate the whole process of generating a certificate.
The first step, for the server and the client is ready to public, private
Generating the server private key
command:
openssl genrsa -out server_pri.key 1024
// generates a server public key
command:
openssl rsa -in server_pri.key -pubout -out server_pub.pem
The second step, to generate a CA certificate
// generate the CA private key
command:openssl genrsa -out ca.key 1024
command:openssl req -new -key ca.key -out ca.csr
// will fill out a data interface, Common Name this one, is the last domain can access the
command:
openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt
A third step of generating the server certificate
// server need to apply to a CA-signed certificate, still create their own CSR document signed certificate before applying
the command:
openssl req -new -key server_pri.key -out server.csr
// institutions to apply to their CA certificate, certificate and private key signing process required to participate in CA, and ultimately issue a certificate with a CA-signed
command:
openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.crt
The same information will be filled in, still wrote like
The fourth step is to generate cer file
// Use openssl to convert
commands:
openssl x509 -in server.crt -out server.cer -outform der
If completed, it will get so 9 files
Step fifth configuration to the server nginx
server {
listen 80;
server_name www.cc.com;
rewrite ^(.*)$ https://www.bb.com $1 permanent;
}
server {
listen 80;
server_name www.bb.com;
rewrite ^(.*)$ https://${server_name}$1 permanent;
}
server {
listen 443;
server_name www.test.com;
ssl on;
ssl_certificate /data/csr/server.crt;
ssl_certificate_key /data/csr/server_pri.key;
location / {
root /data/bb;
index index.html index.htm;
}
}
Certificate chain to solve the problem
Certificate chain links can have any length, so in three of the chain, the links can trust anchor CA certificate signing of an intermediate certificate; intermediate certificate owner can use their private key to another certificate signature. CertPath API can be used to traverse the certificate chain to verify the validity of these can also be used to construct a chain of trust.
Web browsers are preconfigured with a set of root CA certificate browser automatically trust. All certificate from other certificate authority must be accompanied by a certificate chain to test the validity of these certificates. A certificate chain is a certificate issued by a sequence of successive CA certificates, eventually a root CA certificate.
We usually have three kinds of certificates: RootCA.crt (rCA, trusted root certificates), IntermediateCA.crt (mCA, some vendors have multiple intermediate certificates), server.crt (sCA, signed by CSR to the certificate)
In order for browsers to trust our certificate, we need to configure a complete certificate chain, certificate chain and mCA constitute a sCA like, rCA browser is built, the server does not need to provide.
nginx configuration certificate chain when the certificate is to specify a file that contains all certificates like our entire certificate chain, certificate of time of the merger, the correct way is to merge mCA merged into sCA in. When there are multiple files MCA, MCA from the lower to the upper (uppermost root certificate) are sequentially incorporated into the sCA.
-----BEGIN CERTIFICATE-----
...... sCA ......
------END CERTIFICATE------
-----BEGIN CERTIFICATE-----
...... mCA (lower) ......
------END CERTIFICATE------
-----BEGIN CERTIFICATE-----
...... mCA (upper) ......
------END CERTIFICATE------
-----BEGIN CERTIFICATE-----
[ROOT CERTIFICATE]
-----END CERTIFICATE-----
Reproduced in: https: //www.jianshu.com/p/ca82b03d7d54