1. Related concepts
Symmetric encryption : encrypt data through encrypted files, and decrypt data using the same encrypted files.
Asymmetric encryption : encrypt data through an encrypted file, and decrypt data using another encrypted file.
Encryption and decryption : Both the public key and the private key can be used to encrypt data. The situation where the public key is used to encrypt the data and then the private key is decrypted is called encryption and decryption.
Sign and verify signature : Use private key to encrypt data, public key decryption is generally called signature and verify signature.
Description:
-
The data encrypted with the public key can only be unlocked by its corresponding private key, so you can give the public key to others and let others encrypt the data they want to send to you. This data can only reach you with the private key. Only then can the useful data be unlocked. In the same way, if you use your private key to sign data, only the paired public key can unlock the data. Only you have the private key. So if the paired public key unlocks the data, it means this You send the data. On the contrary, it is not. This is called a signature.
-
In practical applications, you usually exchange the public key with the other party, and then the data you want to send to the other party is encrypted with his public key, and after he gets it, he decrypts it with his private key. The data he wants to send you is encrypted with your public key, and decrypted with your private key after you get it, so as to ensure maximum security.
Asymmetric encryption related algorithms
RSA : can be used for encryption and decryption. It can also be used for signature verification.
DSA : Can only be used for signatures.
SHA/MD5 : It is not used for encryption, decryption or signature. It is called a digest algorithm. A fixed-length summary is generated based on the data content, and this string of summary values has a corresponding relationship with the original data. However, this summary cannot be restored to the original data.
Description:
- In the actual application of SHA/MD5 encryption, because the data to be encrypted may be very large, the encryption is time-consuming and laborious. Therefore, the original data is generally digested first, then the digest value is encrypted, and the plaintext of the original data and the encrypted digest value are passed to you. In this way, you can unlock the encrypted digest value and compare it with the digest value of the data you get, you can know whether the data has been modified.
Notary CA
Question : The general public key will not be transmitted to others in plaintext. Under normal circumstances, a file will be generated. This file is the public key file, and then this file can be handed over to others to encrypt data. But if someone maliciously destroys during the transmission process, replace your public key with his public key, and then the party who obtains the public key encrypts the data, can't he use his own private key to decrypt and see the data?
Answer : In order to solve this problem, a notary party is needed to do this. Anyone can find it to confirm who issued the public key. This is the CA. The principle of the CA confirming the public key is also very simple. It releases its own public key to everyone, and then a person who wants to release his public key can send his public key and some identity information to the CA. CA uses its own private key for encryption, which can also be called a signature here. Then this file containing your public key and your information can be called a certificate file . In this way everyone who gets some public key files. The file can be decrypted by the public key of the CA. If it is decrypted normally, the information inside after decryption must be true, because the encryption party can only be a CA. In this way, you can unlock the public key file and look at the information inside to know if this is the public key you need to encrypt.
In practical applications, most people will not find a CA to sign. Because it collects money, you can make a self-signed certificate file yourself. It is to generate a pair of keys by yourself, and then use another pair of keys generated by yourself to sign the pair of keys. This is only for people who really need a signing certificate. Ordinary encryption and decryption of data can be done directly with public and private keys.
Suffix name format description
| Suffix name format | description |
| key | Private key |
| crt | Certificate file, abbreviation of certificate |
| csr | Certificate signing request (certificate request file), containing public key information, abbreviation for certificate signing request |
| crl | Certificate Revocation List, short for Certificate Revocation List |
| pem | The format of the certificate used when exporting and importing the certificate, with the format of the beginning and end of the certificate |
| crt.pem | Exportable certificate |
2. CA root certificate generation steps
- Generate CA private key (.key)
- Generate CA certificate request (.csr)
- Self-signed root certificate (.crt) (certificate issued by CA)
openssl genrsa -out ca.key 2048
openssl req -new -key ca.key -out ca.csr
openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
In actual software development work, the server often uses this self-signed method, because after all, finding a third-party signature agency requires money and also takes time.
3. Steps to generate user certificate
- Generate private key (.key)
- Generate certificate request (.csr)
- Sign the certificate with the CA root certificate (.crt)
Server user certificate
openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr
openssl ca -in server.csr -out server.crt -cert ca.crt -keyfile ca.key
Client user certificate
openssl genrsa -des3 -out client.key 1024
openssl req -new -key client.key -out client.csr
openssl ca -in client.csr -out client.crt -cert ca.crt -keyfile ca.key
Generate a pem format certificate
Sometimes you need to use a pem format certificate, you can combine the certificate file (crt) and the private key file (key) to generate
cat client.crt client.key > client.pem
cat server.crt server.key > server.pem
Result
Server certificate: ca.crt, server.key, server.crt, server.pem
Client certificate: ca.crt, client.key, client.crt, client.pem
4. Generate an SSL certificate in another way
01. Generate your own CA
in the misc directory of the openssl installation directory (or in the apps directory), run the script: ./CA.sh -newca (run under Windows: perl ca.pl -newca), when the prompt appears (Requires password + information). After running, a demonCA directory will be generated, which contains the CA certificate and its private key.
./CA.sh -newca
- After running this command, you will be prompted to enter a password. This process is to generate a CA key pair for signing the certificate request, which needs to be kept in mind.
- 1024, RSA represents the use of RSA algorithm to generate a 1024-bit key. If you need to enhance the key strength (such as generating a 2048-bit key), you can change the default_bits field in /usr/ssl/openssl.cnf to 2048.
- It is important to note that when generating a server-side certificate or a client-side certificate, you need to ensure that the information you fill in is consistent with that of the CA, otherwise the issuance will fail.
02. Generate client and server certificate applications
Generate certificate application:
openssl req -newkey rsa:1024 -out req2.pem -keyout server.key
- The user needs to supplement the information of the certificate, which must be consistent with the basic information of the CA certificate. Otherwise, the signature will fail.
- In practical applications, users can apply for a certificate by submitting a certificate request to a well-known CA. But here, what we need to establish is a root CA, and we can only sign the certificate request by ourselves. So we let OpenSSL use the key attached to the certificate request to sign the request, which is the so-called "self sign".
03. Issuing a certificate
Certificate issuance:
openssl ca -in req2.pem -out server.crt
- To use the generated CA certificate to sign a server certificate request, you need to enter the CA key, with the word "Data Base Update", which means that the certificate has been issued successfully.
04. Processing of key file password
When using the following command to generate a certificate application in step 2), a private key file will be generated at the same time:
openssl req -newkey rsa:1024 -out req2.pem -keyout server.key
When running, you will be prompted to enter a password. This password is used to encrypt the key file. In the future, you will need to enter the password whenever you need to read this file (via the command or API provided by openssl). If the storage environment of the file is sufficiently secure, or other You can also remove the password protection of the file. The command to remove password protection is:
openssl rsa -in server.key -out server.key
If you do not remove the password protection, in order for GaussDB to successfully load the file, you can use the gs_guc tool of GaussDB to set the protection password for the key file. Taking the password of the key file as gaussdb@123 as an example, just run the following command:
gs_guc encrypt –M server –K gaussdb@123
05. Failed to issue certificate
Question 1 : When issuing a certificate, even if the certificate information is correct, the word "Data Base Update" will not be output, which means the issuance is successful. In most cases, there will be words like "failed to update database".
There are two ways to solve this problem:
Method 1:
Modify index.txt.attr under demoCA and
change unique_subject = yes to unique_subject = no
Method 2:
Delete index.txt under demoCA, and touch
rm index.txt
touch index .TXT
Question 2 : "No such file or directory" error appears.
This type of error is generally caused by the incorrect path to execute the command. For the above errors, you can know whether there is demoCA under the current path. If not, switch the path to solve it.
5. SSL related settings of gaussdb
GaussDB server-side ssl function related parameters and configuration instructions :
ssl = off # (change requires restart)
ssl_cert_file = 'server.crt' # (change requires restart)
ssl_key_file = 'server.key' # (change requires restart)
ssl_ca_file = '' # (change requires restart)
ssl_crl_file = ''
If you want to use the ssl function, you first need to set ssl=on, and copy the server-side certificate and private key file to the data directory (the certificate and private key files are named server.crt and server.key by default, otherwise you need to modify ssl_cert_file and ssl_key_file The value of the private key file must not be greater than 0600, otherwise the startup will fail.
Client ssl function related environment variables and configuration instructions :
PGSSLCERT, PGSSLKEY, PGSSLROOTCERT, PGSSLCRL, PGSSLMODE. The specific functions and setting methods are as follows:
gaussdb database user and security management [Secure TCP/IP connection with SSL] [04]
https://blog.csdn.net/qq_42226855/article/details/109565179
Configure ssl authentication link
When the ssl function is configured, you can configure in pg_hba.conf which links pass ssl authentication and encrypted transmission, which links cannot use ssl authentication and encrypted transmission, etc.
gaussdb database user and security management [Client access authentication] [02]
https://blog.csdn.net/qq_42226855/article/details/109563367
Check related settings
- The primary and standby databases force ssl communication. Therefore, the expiration of the certificate will affect the two-machine synchronization, and the SSL certificate needs to be replaced.
- gsql -d dbname -U username -W password -h floatip -p port, indicating that a certificate is used.
SSL connection (cipher: AES256-SHA, bits: 256)
Type "help" for help.
XXXXXX=>
- Check whether the certificate name in the configuration file is consistent with the certificate CN value
grep repl_force postgresql.conf
repl_force_cert_check = ''
- View certificate CN value
openssl x509 -in server.crt -text
Related reference
gaussdb database user and security management [Secure TCP/IP connection with SSL] [04]
https://blog.csdn.net/qq_42226855/article/details/109565179