Some things about SSL certificates

As the network security situation becomes more and more serious, the entire Internet community seems to have reached a consensus: to do everything possible to improve the security of the site. There are many security technology, including SSL/TLS asymmetric encryption technology and corresponding PKI public key architecture system is one of the most important technologies. Due to the complexity of its branch of technology, there are only a few knowledge points to be done to help readers better understand SSL.

What is the process of applying for an HTTPS certificate to a Web site?

Before you start this topic, review the PKI architecture. User, server, CA, these three are the three roles in a PKI. The user receives the certificate issued by the server and verifies it through a list of trusted CAs (root certificates) that are included in the user's own client (the browser or other app), only to confirm that the HTTPS certificate provided by the server is issued by a trusted CA and that HTTPS communication can continue.

So our HTTPS certificate must be issued by a mainstream ca. Why do you emphasize "mainstream"? Because the list of trusted CAs used by different browsers is not the same. Ie,firefox,chrome, all with their own collection of root certificates. Large e-commerce sites are bound to use the most well-known CA institutions, such as VeriSign (which has been acquired by Symantec), Entrust, and so on.

When you apply for a certificate, you need to provide the CA agency with a certificate to issue a CSR file (certificate sigining request). Most Web service programs that support HTTPS can generate a CSR file. The steps are as follows:

1. Generate the public key pair according to the RSA algorithm. The private key is a file that needs to be kept secret, with the. Key suffix, and the public key in the. csr file. The CSR file also includes information such as the organization name, domain name, contact mailbox, and so on, entered during the build CSR process.

2. Send the CSR file to the certificate vendor, such as VeriSign. The supplier handles the CSR file, sets an expiration date, and makes the most critical action: signing with the vendor's own private key. This generates a valid HTTPS certificate.

3. After the user receives the certificate, the SSL configuration file is generated on the Web server (or device such as load balancer) with the previous private key file and the received public key certificate as the key pair, and is bound to the corresponding Web site.

What is the intermediate (intermediate) certificate?

SSL supports the certificate chain, so you can issue an intermediate certificate from a root certificate, and then issue a second-level intermediate certificate, and finally to the terminal certificate. This is mainly due to two considerations:

1. Extensibility: Issuing terminal certificates with the private key of different intermediate certificates according to different service levels

2. Security: The private key of any intermediate certificate is stolen, the intermediate certificate can be revoked immediately (revoke), and the other intermediate certificates can keep the security unaffected.

Examples of intermediate certificates:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/6E/1B/wKioL1V0GzXzRiK_AAEs0BfW5Ik568.jpg "title=" Intermediate_cert. PNG "alt=" Wkiol1v0gzxzrik_aaes0bfw5ik568.jpg "/>

Also, mention the EV (Extended Validation) certificate. This is also an intermediate certificate, and is more "secure" from the browser's performance. In the case of Chrome, a site that uses an EV certificate, the security icon to the left of its site name is a green box, slightly different from a normal intermediate certificate-issued site (blue without a box). The EV is exactly the same as the other intermediate certificates on the algorithm. The ability to reflect a "more secure" icon is also dependent on browser support. It can be understood that the VIP service of the CA vendor was purchased for the website.

The difference between certificate algorithm security and site's SSL/TLS algorithm security

There are many schools of encryption algorithms, and it is easy to confuse. Even experienced IT engineers will still be confused about which algorithms are provided by the certificate and which are provided by the site itself.

RSA: Certificate provided. Asymmetric encryption algorithm. Most HTTPS certificates use this algorithm to generate a public key pair. Used to encrypt/decrypt symmetric keys in SSL/TLS sessions.

MD5/SHA1/SHA2: Certificate provided. Hash/hash/digest algorithm. Used to verify signature authenticity. There is also a fingerprint fingerprint algorithm (generally used SHA1), this is the client browser to the certificate of the overall summary of the algorithm, is not related to the signature algorithm.

Des/aes: Site provided. symmetric encryption algorithm. For the actual data encryption transmission.

Figuring out these, in the current signature algorithm from SHA1 to SHA2 upgrade day, do not need to see the browser Information display certificate "Fingerprint algorithm for SHA1" and feel puzzled!

This article is from the "website Operation Technology Exchange" blog, please make sure to keep this source http://victor1980.blog.51cto.com/3664622/1659447

Some things about SSL certificates