OpenSSL, X509, CRT, CER, key, CSR, SSL, TLS what the hell is all this?

Today, when trying to build a Docker registry private warehouse on a Mac machine, the latest registry of the Cup has been forced to use SSL authentication for security reasons, so we have a detailed understanding of the use of OpenSSL on Linux/mac, and a new set of English abbreviations, Finishing in the following:

TLS: Transport Layer Security Protocol Transport

SSL: Abbreviation for Secure Sockets Layer Secure Socket Layers

TLS and SSL for a developer who is not a professional security, it can be considered to be similar, the two are tied relationship, detailed differences see http://kb.cnblogs.com/page/197396/

Key usually refers to the private key.

A CSR is an abbreviation for certificate Signing request, which is a certificate signing, which is not a certificate, it can be simply understood as a public key, and it is submitted to the authoritative certification authority when the certificate is generated.

The CRT is the abbreviation for certificate, which is the certificate.

A certificate format is one of the certificates. For the certificate, the authenticator is always the CA or the person specified by the CA, and a copy of the certificate is a collection of standard fields that contain information about the user or device and its corresponding public key.

The certificate file for the. CRT, usually ending in the, according to the content encoding format of the file, can be divided into the following two formats:

Pem-privacy Enhanced Mail, open the text format to start with "-----begin ...", End with "-----end ..." and the content is BASE64 encoded.
Apache and *nix servers tend to use this encoding format.

der-distinguished Encoding Rules, open look is binary format, unreadable.
Java and Windows servers tend to use this encoding format

OpenSSL is equivalent to an implementation of SSL, and if the SSL specification is regarded as an interface in Oo, then OpenSSL is considered an implementation of the interface. The interface specification itself is safe, but there may be imperfections in the implementation, such as the previous "Heart Bleed" vulnerability, which is a bug in OpenSSL.

Steps for OpenSSL to issue a certificate to itself:

Prerequisite: First build a cert directory, CD to the directory, the following all the current path of the command is the directory

1. Generate the private key key

1	openssl genrsa -des3 -out server.key 2048

After this step is completed, the Server.key file is generated under the Cert directory

2. Generate a certificate request file CSR

1	openssl req -new -key server.key -out server.csr

This command first enters interactive mode, allowing you to fill in a bunch of things, for reference:

Note that common name here, to fill in the use of SSL certificate (ie: HTTPS protocol) domain name or host name, otherwise the browser will be considered unsafe. For example: if you intend to use https://yjm-docker/xxx here to fill out Yjm-docker

3. Generate the CA's certificate

The certificate of the previous certificate is always the CA or the person specified by the CA, so Mr.

1	openssl req -new -x509 -key server.key -out ca.crt -days 3650

4. Finally, use the 3rd step of the CA certificate to issue yourself a certificate to play

123	openssl x509 -req -days 3650 -inserver.csr \  -CA ca.crt -CAkey server.key \  -CAcreateserial -out server.crt

After execution, the Cert directory SERVER.CRT is the certificate we need. Of course, if you want to display a secure green lock logo in a browser such as Google, the certificate issued by yourself is not good enough to be paid to a third-party authoritative certification authority (that is: The 4th step is to the authority to do, we only need to submit server.key, SERVER.CSR, Oh, and Grandpa Mao is all right.

OpenSSL, X509, CRT, CER, key, CSR, SSL, TLS what the hell is all this?