For a public-facing website, if you want to encrypt the communication during the user's visit to the website and allow users to access it using HTTPS, the website itself needs to have its own private key and a certificate issued by a trusted organization. This is a technical architecture that uses HTTPS access.
A certificate issued by a trusted organization requires money. In some cases, we can issue certificates for ourselves. For example, developers develop their own tests; for example, for internal company use instead of public Internet access.
In the blog post I developed in Delphi based on Indy-based WebBroker or WebService server supporting https , I talked about using my own private key and certificate for Delphi Indy's Web Server program and WebServices program.
Let's briefly talk about the specific methods of using OpenSSL to make private keys and certificates.
This article reference: OpenSSL Certificate Authority
--------------------------------------
concept:
1. Use the browser to use https://website.com/ to visit a website. Compared with the simple http://website.com/ method, http communication is not encrypted. Use Sniffer packet capture tool or other The communication content is intercepted by the method and can be read directly. At the communication layer, https is an encrypted communication based on SSL. The intercepted communication content cannot be decrypted and read by the interceptor.
2. SSL encrypted communication is based on asymmetric encryption technology. Specifically for a website that supports HTTPS access, its website needs to have its own private key for asymmetric encryption and a certificate containing the public key for asymmetric encryption.
2.1. The certificate is issued by a trusted organization (such as Google or Microsoft or an organization that specializes in issuing certificates); therefore, the client can trust that the public key in the certificate is indeed the website, rather than being forged by an attacker.
2.2. How does the client determine that the certificate is trustworthy? Because the information contained in the certificate can be traced back to the root certificate of the organization that issued the certificate. The root certificate is added to the Windows operating system as a trusted certificate. Of course, users can also manually remove the trust of this root certificate.
3. Assuming that a person who needs to visit a website must provide a signed certificate to prove his identity (this kind of website is usually not for the general public), then an ordinary user can also have his own private key and certificate.
5. Certificate trust chain: As a trusted organization that specializes in issuing certificates, its own root certificate and private key are usually not used to issue certificates for users. The security of this root private key is very important, and it is usually not used. Therefore, the root private key and root certificate are used to make and issue some intermediate certificates. Then the intermediate certificate and private key are used to issue the certificate required by the user. This role similar to the [intermediary] can have multiple levels. This constitutes a chain of trust. That is, a final certificate, which can be traced back to the root certificate. Therefore, to verify whether a certificate is legal, it does not require an Internet connection to verify. As long as there is a trusted root certificate in the user's system, the validity of the certificate can be verified.
5.1. However, if a certificate is revoked (for example, its private key is stolen), you need to check it online. The certificate issuing authority has a server dedicated to providing such queries. Of course this is a standard protocol, and the computer system will automatically complete this process.
6. Users can make their own private key and a CSR (certificate signing request) for certificate signing. In this way, the user keeps his private key and only needs to send the CSR to the certificate issuing authority. The certificate issuing authority will sign this CSR into a real certificate. In this way, the user's private key will not be seen by any third party.
noun:
1. OpenSSL: OpenSSL is a free and open source encryption library that provides a number of command-line tools for processing digital certificates. Some of these tools can be used to act as a certification authority.
2. CA: certificate authority, is an entity that signs digital certificates.
3. The private key is called Key, the root key, and its corresponding file name: ca.key.pem; the public key is the certificate, and its corresponding file name (root certificate) ca.cert.pem; The cert here means certificate.
4. CSR: certificate signing request. The third party creates the private key and then sends the certificate signing request to the CA.
Practice:
Environment setup:
I use OpenSSL in the Linux subsystem of Windows 10. The Linux subsystem of my Windows 10 is Ubuntu installed. After the installation is complete, OpenSSL is already in it. If not, there are many articles on how to install OpenSSL under Linux. Or install the Win version of OpenSSL directly in Windows. I guess the command line operation should be the same.
In short, start Windows PowerShell and enter the bash command inside to enter Linux. So you can run OpenSSL directly in it.
operating:
1. Create a root private key and certificate pair
1. Prepare the working directory. I created a directory called ca under the current user. In Windows, it is actually in the directory of the current Windows user.
2. Create 3 folders under the ca directory:
mkdir certs crl newcerts private
3. Create two files in the ca directory and enter the command: ( Note: the current path of all the commands below is the ca directory )
3.1. touch index.txt
3.2. echo 1000 > serial
4. Change the permissions of the private directory: chmod 700 private
5. Create a root key: Enter the command: openssl genrsa -aes256 -out private/ca.key.pem 4096 to create a root key. After copying the above command, right-click in the powershell window with the mouse to paste it in. After pressing Enter, you will be prompted to enter the password. Enter a self-made password to create a root key.
5.1. root key is the private key of the root, its file is: ca.key.pem, in the private directory;
5.2. chmod 400 private/ca.key.pem
5.3. This ca.key.pem file is encrypted, and you need to enter a password every time you use it. This password is the password that the system prompts you to enter when it is created.
6. Create a root certificate: openssl.cnf is required to create a root certificate, which is a text configuration file.
6.1. In the reference link at the top of this article, there is the openssl.cnf template. Download it and use it with minor modifications or no changes.
6.2. Place openssl.cnf in the ca directory. Enter the following command:
openssl req -config openssl.cnf \
-key private/ca.key.pem \
-new -x509 -days 7300 -sha256 -extensions v3_ca \
-out certs/ca.cert.pem6.3. During the process of creating the certificate, I encountered an error message: unable to load Private Key . The reason is that the system prompts me to enter the password of ca.key.pem during the execution of the command, which is caused by my input error.
6.4. Verify the certificate just created: openssl x509 -noout -text -in certs/ca.cert.pem You can see the content of the certificate. At this point, the root private key and root certificate are created.
2. Create an intermediate certificate pair
1. mkdir ca/intermediate creates this directory to store intermediate certificates. So under the ca directory, we have an intermediate directory.
1.1. cd ca/intermediate
1.2. mkdir certs crl csr newcerts private Create 3 subdirectories for the intermediate directory. It looks like the structure is the same as the ca directory.
1.3. chmod 700 private
1.4. Create file: touch index.txt
1.5. Create file: echo 1000> serial
1.6. echo 1000> crlnumber This file is used to store the certificate revocation list.
2. Create the private key of the middleman, the following operations are in the ca directory:
2.1. Execute the following command to create the private key key (you will be prompted to enter the password during the execution of the command):
openssl genrsa -aes256 \
-out intermediate/private/intermediate.key.pem 4096 2.2. chmod 400 intermediate/private/intermediate.key.pem This intermediate.key.pem is the private key file of the middleman.
3. Make the certificate of the middleman.
3.1. First prepare the openssl.cnf file needed by the broker. Just copy the files under the previous ca to the intermediate directory.
3.2. Execute the following command to make a certificate CSR:
openssl req -config intermediate/openssl.cnf -new -sha256 \
-key intermediate/private/intermediate.key.pem \
-out intermediate/csr/intermediate.csr.pemWhen executing the above command, you will be prompted to enter the password of the middleman's private key.
It should be noted here that when creating the intermediate certificate, in the configuration .cnf file, A. The location of 0.organizationName in the configuration file must be the same name as the root certificate when the command requires you to enter it, both in upper and lower case. Can't be wrong. B. The commonName must be different from the root certificate. When you are asked to enter some names after executing the command, the commonName must be a different name from the root certificate.
3.3. Sign the intermediate certificate with the root certificate:
openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
-days 3650 -notext -md sha256 \
-in intermediate/csr/intermediate.csr.pem \
-out intermediate/certs/intermediate.cert.pem
3.4. chmod 444 intermediate/certs/intermediate.cert.pem
3.5. Verify this intermediate certificate:
openssl x509 -noout -text \
-in intermediate/certs/intermediate.cert.pem3.5. When an application (such as a web browser) tries to verify a certificate signed by an intermediate CA, it must also verify the intermediate certificate against the root certificate. To complete the trust chain, create a CA certificate chain to present to the application.
To create a CA certificate chain, connect the intermediate certificate and the root certificate together. We will use this file later to verify the certificate signed by the intermediate CA.
Execute the following commands:
cat intermediate/certs/intermediate.cert.pem \
certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
chmod 444 intermediate/certs/ca-chain.cert.pem3.6. Our certificate chain file must contain the root certificate, because no client application knows the certificate yet. A better option (especially in the case of intranet management) is to install a root certificate on each client that needs to connect. In this case, the chain file only needs to contain your intermediate certificate.
3. Create a certificate pair for the website
The certificate pair used by the website is issued with an intermediate certificate. The production process is exactly the same as the above two.
1. Create a key-the private key of the website:
openssl genrsa -aes256 \
-out intermediate/private/www.myhost.net.key.pem 20481.1. Note that the -aes256 in the first line here is the encryption password for this key. When the website loads the certificate for the first time, the key needs to be loaded and the password needs to be entered. If you don't want to enter the password when the web server loads this key, you don't need the -aes256 option.
1.2. The control TIdServerIOHandlerSSLOpenSSL provided by Indy of Delphi for using the OpenSSL certificate has an OnGetPassword event. The program can enter the password of the above key here for the program to use this key.
1.3. chmod 400 intermediate/private/mis.myhost.net.key.pem
2. Create a certificate for the website:
2.1. Execute the following command to create the CSR of the website:
cd /root/ca
# openssl req -config intermediate/openssl.cnf \
-key intermediate/private/mis.myhost.net.key.pem \
-new -sha256 -out intermediate/csr/www.myhost.net.csr.pem2.2. During the execution of the above command, you will be prompted to enter a bunch of information, such as name, email, etc. It must be noted here that where the commonName is entered, the address of the website must be entered, and it must not be the same as the commonName entered when creating the intermediate certificate. The same cannot be created successfully.
2.3. Use the intermediate certificate signature for the website certificate CSR to produce the final certificate to be used:
openssl ca -config intermediate/openssl.cnf \
-extensions server_cert -days 375 -notext -md sha256 \
-in intermediate/csr/mis.myhost.net.csr.pem \
-out intermediate/certs/mis.myhost.net.cert.pem2.4. chmod 444 intermediate/certs/mis.myhost.net.cert.pem
2.5. Verification:
openssl x509 -noout -text \
-in intermediate/certs/mis.myhost.net.cert.pemAt this point, a usable certificate is completed.
This certificate can be used for encrypted access to the website. In my blog post, I also talked about how to make Delphi programs use it.