CA(openssl)

Table of contents

Create a private CA

1. Create the files required for CA

2. Generate CA private key

3. Generate CA self-signed certificate

Apply for a certificate and issue it

1. Generate a private key for the host that needs to use the certificate

2. Generate certificate application files for hosts that need to use certificates

3. Sign the certificate at the CA and issue the certificate to the requester

Change inspection strategy

4. View the information in the certificate

5. Introduction to index.txt and serial files

6. How to generate multiple certificates for the same csr (certificate signing request)

revoke certificate

Obtain the serial number of the certificate to be revoked on the client side

On the CA, based on the serial and subject information submitted by the customer, compare and verify whether it is consistent with the information in the index.txt file, and revoke the certificate.

Specify the number of the first revoked certificate

Update certificate revocation list

Generate certificate revocation list file

Generate certificate chain

Generate root certificate

Generate intermediate certificate

Generate server certificate

Generate certificate chain

format file


Create a private CA

1. Create the files required for CA

#Generate certificate index database file

touch /etc/pki/CA/index.txt

#Specify the serial number of the first issued certificate

echo 01 > /etc/pki/CA/serial

2. Generate CA private key

cd /etc/pki/CA/

(umask 066; openssl genrsa -out private/cakey.pem 2048)

3. Generate CA self-signed certificate

openssl req -new -x509 -key /etc/pki/CA/private/cakey.pem -days 3650 -out /etc/pki/CA/cacert.pem

Option description:

-new: Generate a new certificate signing request

-x509: Dedicated to CA generating self-signed certificates

-key: private key file used when generating requests

-days n: the validity period of the certificate

-out /PATH/TO/SOMECERTFILE: Certificate saving path

Country code: https://country-code.cl/

Example: Generate a self-signed certificate

[root@CentOS7 ~]# openssl req -utf8 -newkey rsa:1024 -subj "/CN=www.xiaobai.org" -keyout app.key -nodes -x509 -out app.crt

Generating a 1024 bit RSA private key

.......................++++++

.......................++++++

writing new private key to 'app.key'

#View certificate

[root@CentOS7 ~]# openssl x509 -in app.crt -noout -text

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            f5:42:e7:5a:cd:65:17:46

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: CN=www.xiaobai.org

        Validity

            Not Before: Jun 19 06:48:56 2023 GMT

            Not After : Jul 19 06:48:56 2023 GMT

        Subject: CN=www.xiaobai.org

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (1024 bit)

                Modulus:

·····

                Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Subject Key Identifier:

                36:BD:AE:68:3D:D8:48:09:7B:8D:B7:50:51:F8:0A:4A:92:F5:91:18

            X509v3 Authority Key Identifier:

                keyid:36:BD:AE:68:3D:D8:48:09:7B:8D:B7:50:51:F8:0A:4A:92:F5:91:18

            X509v3 Basic Constraints:

                CA:TRUE

    Signature Algorithm: sha256WithRSAEncryption

·····

[root@CentOS7 ~]#

Apply for a certificate and issue it

1. Generate a private key for the host that needs to use the certificate

(umask 066;openssl genrsa -out data/test.key 2048)

2. Generate certificate application files for hosts that need to use certificates

openssl req -new -key data/test.key -out data/test.csr

3. Sign the certificate at the CA and issue the certificate to the requester

openssl ca -in data/test.csr -out /etc/pki/CA/certs/test.crt -days 100

Note: The default requirement is that the country, province, and company name must be consistent with the CA, otherwise an error will be reported.

In OpenSSL, it is required that the organization information (Organization) in the certificate application must be consistent with the organization information in the certificate of the CA (Certificate Authority). This usually includes the country (Country), province (State), and company name (Organization Name), etc.

During the certificate application process, OpenSSL will automatically obtain the current system time zone information from the system, and require the applicant to provide the certificate's validity period, certificate serial number and other information. In addition, OpenSSL also requires applicants to provide the common name (Common Name) of the certificate, which is usually used to represent the host name or domain name of the certificate.

It should be noted that OpenSSL does not check whether the applicant is a legitimate organization or company, but only checks whether the organizational information provided by the applicant is consistent with the organizational information in the CA's certificate. Therefore, when applying for a certificate using OpenSSL, you need to carefully verify whether the organizational information provided by the applicant is correct to ensure the security of the certificate.

[root@CentOS7 ~]# openssl ca -in data/test.csr -out /etc/pki/CA/certs/test.crt -days 100

Using configuration from /etc/pki/tls/openssl.cnf //Using the configuration in /etc/pki/tls/openssl.cnf

Check that the request matches the signature //Check whether the request matches the signature

Signature ok //Signature successful

The stateOrProvinceName field needed to be the same in the

CA certificate (beijing) and the request (jiangshu) //The stateOrProvinceName field in the CA certificate (Beijing) and the request (Jiangsu) needs to be the same

Change inspection strategy

[root@CentOS7 ~]# vim /etc/pki/tls/openssl.cnf

# A few difference way of specifying how similar the request should look

# For type CA, the listed attributes must be the same, and the optional

# and supplied fields are just that :-)

//There are a few different ways of specifying how similar the requested lookup type CA is, the properties listed must be the same, the optional fields and the provided fields are the only ones :-)

policy          = policy_match

# For the CA policy

[ policy_match ]

countryName             = match

stateOrProvinceName     = match

organizationName        = match

organizationalUnitName  = optional

commonName              = supplied

emailAddress            = optional

# For the 'anything' policy

# At this point in time, you must list all acceptable 'object'

# types.

//At this point, you must list all acceptable `object` types.

[ policy_anything ]

countryName             = optional

stateOrProvinceName     = optional

localityName            = optional

organizationName        = optional

organizationalUnitName  = optional

commonName              = supplied

emailAddress            = optional

Certificate is to be certified until Sep 27 06:56:04 2023 GMT (100 days)

Sign the certificate? [y/n]:y

//The certification deadline is September 27, 2023 06:56:04 GMT (100 days)

Signing certificate?[y/n]: y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

1 / 1 certificate requires authentication, submit? [y / n] y

Write to database and add 1 new entry

Database update

4. View the information in the certificate

openssl x509 -in /PATH/FROM/CERT_FILE -noout -text|issuer|subject|serial|dates

#View the certificate status of the specified number

openssl ca -status SERIAL

5. Introduction to index.txt and serial files

OpenSSL is an open source encryption library that provides a series of encryption algorithms and protocols, including SSL, TLS, RSA, DSA, AES, SHA, etc. When using OpenSSL for certificate signing, you need to use index.txt and serial files.

The index.txt file is a text file used to store certificate requests and certificate information. Each certificate request or certificate has a unique serial number that is automatically incremented by a number in the serial file. The format of the index.txt file is as follows:

```

V 200101010000Z 01 unknown /CN=example.com

V 200101010000Z 02 unknown /CN=example.org

```

Among them, each line represents a certificate request or certificate, and the meaning of each field is as follows:

- The first column: Certificate status, V means valid, R means revoked.

- The second column: the start time of the certificate's validity period, in the format YYYYMMDDHHMMSSZ.

- The third column: the serial number of the certificate, which is automatically generated by the number in the serial file.

- The fourth column: the revocation status of the certificate, unknown means not revoked.

- The fifth column: the subject information of the certificate, in the format /CN=example.com.

The serial file is a text file used to store the serial number of the certificate. The serial number is automatically incremented each time you sign. The format of the serial file is as follows:

```

01

02

```

Among them, each line represents the serial number of a certificate.

When using OpenSSL for certificate signing, you need to create the index.txt and serial files first, and add the certificate request to the index.txt file. Then, use the openssl ca command to sign the certificate, and the signed certificate will be added to the index.txt file. After each signature, the serial number in the serial file will be automatically incremented for the next signature.

6. How to generate multiple certificates for the same csr (certificate signing request)

If you use the same csr to generate a certificate, there will be errors.

failed to update database

TXT_DB error number 2

Change the following configuration

[root@CentOS7 ~]# vim /etc/pki/CA/index.txt.attr

将unique_subject = yes

Change to unique_subject = no

revoke certificate

Obtain the serial number of the certificate to be revoked on the client side

openssl x509 -in /PATH/FROM/CERT_FILE -noout -serial -subject

[root@CentOS7 ~]# openssl x509 -in test_2.crt -noout -serial -subject

serial=03

subject= /C=CN/ST=beijing/O=it/OU=it01/CN=it

On the CA, based on the serial and subject information submitted by the customer, compare and verify whether it is consistent with the information in the index.txt file, and revoke the certificate.

openssl ca -revoke /etc/pki/CA/newcerts/SERIAL.pem

[root@CentOS7 ~]# openssl ca -revoke test_2.crt

Using configuration from /etc/pki/tls/openssl.cnf

Revoking Certificate 03.

Data Base Updated

[root@CentOS7 CA]# vim index.txt

V       230928024718Z           01      unknown /C=CN/ST=beijing/O=it/OU=it01/CN=it

V       230928025156Z           02      unknown /C=CN/ST=beijing/O=it/OU=it01/CN=it

R       230928035209Z   230620035512Z   03      unknown /C=CN/ST=beijing/O=it/OU=it01/CN=it

[root@CentOS7 ~]# openssl ca -status 03

Using configuration from /etc/pki/tls/openssl.cnf

03=Revoked (R)

Specify the number of the first revoked certificate

echo 01 > /etc/pki/CA/crlnumber

Note: This is only required before updating the certificate revocation list for the first time.

Update certificate revocation list

openssl ca -gencrl -out /etc/pki/CA/crl.pem

Generate certificate revocation list file

[root@CentOS7 ~]# openssl ca -gencrl -out /etc/pki/CA/crl/crl.pem

Using configuration from /etc/pki/tls/openssl.cnf // Using the configuration in /etc/pki/tls/openssl.cnf

/etc/pki/CA/crlnumber: No such file or directory // /etc/pki/CA/crlnumber: No such file or directory

error while loading CRL number // Error while loading CRL number

140067035502480:error:02001002:system library:fopen:No such file or directory:bss_file.c:402:fopen('/etc/pki/CA/crlnumber','r')

140067035502480:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:404:

//140067035502480: error: 02001002: system library: fopen: No such file or directory: bss_file.c:402: fopen('/etc/pki/CA/crlnumber', 'r')

140067035502480: Error: 20074002: BIO routine: FILE_CTRL: system lib: bss_file.c: 404:

[root@CentOS7 ~]# echo 01 > /etc/pki/CA/crlnumber

[root@CentOS7 ~]# cat /etc/pki/CA/crlnumber

02 //This is 02 because a certificate has been revoked above (the file will increase automatically)

[root@CentOS7 ~]# openssl ca -gencrl -out /etc/pki/CA/crl.pem

Using configuration from /etc/pki/tls/openssl.cnf

[root@CentOS7 ~]# cat /etc/pki/CA/crl/crl.pem

-----BEGIN X509 CRL-----

MIIB7TCB1gIBATANBgkqhkiG9w0BAQsFADB+MQswCQYDVQQGEwJDTjEQMA4GA1UE

CAwHYmVpamluZzEQMA4GA1UEBwwHYmVpamluZzELMAkGA1UECgwCaXQxDTALBgNV

BAsMBGl0MDExEjAQBgNVBAMMCWNhLml0LmNvbTEbMBkGCSqGSIb3DQEJARYMcm9v

·····

·····

fWlVXNdTBy5NpqwmAgR0eNwJ+2lsnAT0PQBwPsxp9aloc60xBSAGmAzdZVhfNCe0

BdNog5gAo/x5VbNGmz8dNYI=

-----END X509 CRL-----

Generate certificate chain

To generate a certificate chain, you need multiple certificate files, including root certificates, intermediate certificates, and server certificates. Here are the steps to generate a certificate chain using openssl:

Generate root certificate

To use openssl to generate a root certificate, you can refer to the following command:

```

openssl req -x509 -newkey rsa:2048 -keyout root.key -out root.crt -days 3650

```

Generate intermediate certificate

If you need to generate an intermediate certificate, you can use the following command:

```

openssl req -newkey rsa:2048 -keyout intermediate.key -out intermediate.csr

openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key -CAcreateserial -out intermediate.crt -days 3650

```

Generate server certificate

Generate the server certificate using the following command:

```

openssl req -newkey rsa:2048 -keyout server.key -out server.csr

openssl x509 -req -in server.csr -CA intermediate.crt -CAkey intermediate.key -CAcreateserial -out server.crt -days 3650

```

Generate certificate chain

Merge the root certificate, intermediate certificate, and server certificate into one file to generate a certificate chain:

```

cat server.crt intermediate.crt root.crt > certificate-chain.crt

```

Among them, certificate-chain.crt is the generated certificate chain file.

Note: When generating a certificate chain, you need to merge the certificate files in order, that is, the server certificate is first, the intermediate certificate is in the middle, and the root certificate is last.

format file

CSR (Certificate Signing Request) format file

A CSR file is a file format used to apply for a digital certificate from a Certificate Authority (CA). It contains the applicant's public key and some identity information, such as country, organization, unit, domain name, etc. CSR files usually exist in the form of text files with the suffix .csr.

KEY format file

KEY file is a file format used to store private keys. The private key is the key used to encrypt and decrypt data, so it must be kept safe. KEY files usually exist in the form of text files with the suffix .key.

PEM (Privacy-Enhanced Mail) format file

PEM file is a common certificate file format, which can store certificates, private keys, CSR and other information. PEM files are Base64 encoded and can be opened and viewed through a text editor. PEM files usually exist with .crt, .pem, .key and other suffix names.

PFX/P12 (Personal Information Exchange) format file

The PFX/P12 file is a common certificate file format that can store certificates, private keys and other information, and can be password protected. PFX/P12 files are usually in binary format with the suffix .pfx or .p12.

DER (Distinguished Encoding Rules) format file

A DER file is a binary format certificate file that is commonly used to transmit certificates over the network. DER files cannot be opened directly with a text editor, but they can be parsed through some tools. DER files usually exist with suffix names such as .crt and .der.

Guess you like

Origin blog.csdn.net/m0_74204829/article/details/133469810