In the previous article, we introduced some basic knowledge of digital signature and digital certificate, but we did not mention how to manage digital certificate, such as the file format of digital certificate, application and rotation of digital certificate, etc. This article will introduce the management of digital certificate.

Speaking of digital certificate management, we have to mention a proper noun: PKI (Publick Key Infrastructure), which is a key management platform following established standards and can provide cryptographic services such as encryption and digital signature and the necessary key and certificate management system for all network applications. In simple terms, it can be understood as providing cryptographic services such as encryption and digital signature and the related key and certificate management system for applications using the previously mentioned public and private key asymmetric cryptography.

PKI is neither a protocol nor a software. It is a standard, and the technologies developed under this standard to achieve the purpose of security infrastructure services are collectively called PKI.

Components of PKI

PKI, as an implementation standard, consists of a series of components:

  1. CA (Certificate Authority): It is the “core” of PKI, i.e. the application and issuing authority of digital certificate, CA must have authoritative characteristics, it is responsible for managing the issuance of certificates of all users (including various applications) under the PKI structure, bundling the public key of the user with other information of the user, verifying the identity of the user on the Internet, CA is also responsible for the blacklist registration and blacklist release of the user certificate.
  2. X.509 Directory Server: The X.500 Directory Server is used to “publish” user certificates and blacklist information so that users can query their own or others’ certificates and download blacklist information via the standard LDAP protocol.
  3. Secure Socket Layer (SSL) based secure web server: Originally developed by Netscape, the Secure Socket Layer (SSL) protocol has become a global standard used by the web to identify websites and web surfers, and to encrypt communications between browser users and web servers.
  4. Web Secure Communication Platform: Web has two parts: Web client and Web server, which guarantees the confidentiality, integrity and authentication of client-side and server-side data through SSL protocol with high-strength cryptographic algorithms.
  5. Self-developed Security Applications: Self-developed security applications refer to various specific applications developed by various industries, such as banking and securities applications, etc. The complete PKI includes:
    • Authentication policy development
    • Authentication rules
    • The development of the operational system
    • The content of the legal relationship between the parties involved
    • Implementation of the technology, etc.

Certificate Authority

Certificate Authority, also known as CA, is an authority responsible for issuing and managing digital certificates, and as a trusted third party in e-commerce transactions, it assumes the responsibility of verifying the legitimacy of public keys in the public key system. CA issues a digital certificate for each user who uses the public key to realize the distribution of the public key and prove its legitimacy. As the core part of PKI, CA implements some important functions in PKI:

  1. receiving applications to verify end-user digital certificates
  2. determining whether to accept the application for end-user digital certificate - approval of certificate
  3. issuing and refusing to issue digital certificate to the applicant - certificate issuance
  4. receiving and processing the end-user’s digital certificate renewal request - certificate renewal
  5. receiving end-user digital certificate inquiry and revocation
  6. generating and issuing certificate revocation list
  7. archiving of digital certificates.
  8. key archiving.
  9. archiving of historical data.

X.509 Certificate Standard

There are many format standards in the whole PKI system, and the standards of PKI stipulate the design, implementation and operation of PKI and the “rules of the game” for various roles of PKI. If two PKI applications want to interact with each other, the interaction can only be carried out properly if they understand each other’s data meaning, and the role of standards is to provide a common agreement on data syntax and semantics. The most important standard in PKI, it defines the basic structure of public key certificates.

X.509 is the basic standard that defines the structure of public key certificates, and is a very common certificate format at present.

X.509 plays a pivotal role in PKI, which has grown from small to large, from a closed network environment to a distributed open environment. It can be said that the X.509 standard is the prototype of PKI.

RFC5280 specifies the standard format of x.509 certificate as shown in the following figure.

RFC5280

For X.509-compliant digital certificates, it must be ensured that the public key and the name of its owner (Subject) are the same, and that the certificate issuer (Issuer) is always a CA or a person designated by a CA. An X.509 digital certificate is a collection of standard fields that contain information about the user or device and its corresponding public key. The X.509 standard defines what information should be contained in the certificate and describes how such information is encoded (i.e. data format). All X.509 certificates contain the certificate issuer’s information in addition to the certificate owner’s public key, some basic information of the certificate owner and digital signature. Specifically, it contains the following data.

  1. Version: indicates which version of X.509 standard (Version 1, Version 2 or Version 3) is used in the certificate, the version number affects some specific information in the certificate, the latest version is Version: 3.
  2. Serial Number: a unique integer that identifies the certificate and is assigned by the certificate issuer as the unique identifier of this certificate.
  3. Signature Algorithm Identifier: the algorithm identifier used for the visa certificate, consisting of an object identifier plus relevant parameters to indicate the digital signature algorithm used for this certificate. For example, the sha256WithRSAEncryption object identifier is used to indicate that the digital signature is a hash encryption of sha256 using RSA.
  4. Validity period (Validity): the certificate start date and time and termination date and time; specify that the certificate is valid within these two times.
  5. Subject Information: the unique identifier (or DN) of the certificate holder which name should be unique on the Internet.
  6. Public Key Information (Subject Public Key Info): including the certificate holder’s public key, algorithm (specifying which cryptosystem the key belongs to) identifier and other relevant key parameters.
  7. Issuer Unique Identifier (Issuer): identifier - unique identifier of the certificate issuer, required only in versions 2 and 3, and is optional.
  8. Certification Authority Digital Signature: this is a signature generated using the certificate issuer’s private key to ensure that this certificate has not been altered after it has been issued.
  9. Certification Authority: The identifiable name (DN, Distinguished Name) of the certificate issuer, which is the X.509 name of the unique CA of the entity issuing this certificate. Use of this certificate implies trust in the entity that issued the certificate. (Note: In some cases, such as root or top-level CA certificates, the issuer issues the certificate itself).

In addition to the above fields, X.509 certificates can include optional standard and specialized extensions (only available in versions 2 and 3), which are not described here.

Here is the information about my personal certificate created using openssl.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

$ openssl x509 -in certificate.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4096 (0x1000)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=CN, ST=Beijing, O=XXX, OU=XXX, CN=XXX/emailAddress=test@mail.com
        Validity
            Not Before: Mar 23 11:52:23 2019 GMT
            Not After : Apr  1 11:52:23 2020 GMT
        Subject: C=CN, ST=Beijing, L=XXXXX, O=XXX, OU=XX, CN=XXX/emailAddress=test@mail.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a4:1a:a9:4b:aa:6e:a9:18:28:e6:35:bc:c3:6f:
                    ec:4c:7f:81:63:34:ce:57:a0:96:3f:2c:95:c8:01:
                    02:e9:75:54:f4:a4:22:d2:71:61:0e:8a:7a:bc:25:
                    d3:4d:cf:f0:9c:16:6f:0f:33:87:0e:f5:88:a4:25:
                    a8:67:b2:3e:a7:d1:b7:0d:6c:22:90:7a:ee:7a:53:
                    00:4d:5d:2e:3b:6d:48:5d:8d:a9:79:25:58:ca:0b:
                    ae:42:f6🆎9f:a6:e8:e8:c7:06:ca:c3:92:09:ae:
                    19:a5:2b:68:1c:09:91:20:30:4f:44:5c:f0:49:fe:
                    26:29:90:7a:7b:4e:5f:93:93:49:da:a1:a1:da:4d:
                    e1:7c:86:67:05:ea:ce:64:b7:bb:fc:e0:10:f7:2e:
                    8f:9e:1f:82:4e:b6:d1:97:8d:a7:d2:0b:19:e4:bc:
                    ad:46:3f:ad:32:47:f9:47:bf:29:88:b4:3f:1d:02:
                    d4:93:e5:aa:76:13:83:52:7f:5d:33:f4:fa:73:85:
                    20:d7:7b:b9:a6:a9:35:dd:9f:e4:53:12:d3:db:33:
                    b0:1f:27:a1:9e:c0:aa:41:4b:ad:b1:74:8e:a3:c9:
                    e6:19:3d:39:2d:13:a7:e6:dc:e7:c6:88:06:70:60:
                    4b:5b:8a:cf:d3:45:23:b2:4e:17:c6:fe:06:c5:49:
                    a9:c9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Cert Type:
                SSL Server
            Netscape Comment:
                OpenSSL Generated Server Certificate
            X509v3 Subject Key Identifier:
                30:B7:57:E0:1A:07:69:DB:47:8C:B2:BC:21:14:7D:D2:71:A8:96:5D
            X509v3 Authority Key Identifier:
                keyid:E8:42:1C:63:92:76:AD:2C:62:2C:C1:71:92:40:24:B5:76:53:9A:1C
                DirName:/C=CN/ST=Beijing/L=XXXXX/O=XXX/OU=XXX/CN=XXX/emailAddress=test@mail.com
                serial:10:00

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
    Signature Algorithm: sha256WithRSAEncryption
         98:8e:dd:8b:b7:af:c0:8d:41:76:0e:0a:5c:61:d6:39:a0:60:
         f4:56:4b:ea:b3:0d:09:c4:54:72:f7:45:b8:ba:f3:c9:f9:7c:
         7a:2b:81:82:dc:25:fd:b0:2c:b6:c9:d4:ad:c6:85:52:0c:0e:
         68:a2:fe:14:04:e1:95:a9:a0:b2:7a:8c:8a:25:20🆎2d:62:
         a6:d7:e8:20:a2:9a:b4:8d:53:b1:ff:b0:d2:33:0d🆎c3:fb:
         9c:03:59:73:cb:4f:dd:3f:bc:66:8c:c3:2b:32:23:a8:96:9e:
         a5:9d:f3:db:06:0c:a4:10:52:d6:3f:92:f8:ca:88:30:75:b6:
         d6:16:1a:5b:0f:f9:d6:2d:f2:94:2a:bd:c5:d9:b2:f9:5d:f5:
         02:01:4a:2a:10:45:a4:48:83:30:c0:a4:27:2f:73:72:73:93:
         ed:34:8f:66:53:0a:b4:93:05:61:00:22:0c:89:da:b6:46:17:
         a9:3e:28:37:2f:f3:7e:3f:69:a7:36:62:ff:c5:b2:ed:c2:0c:
         55:34:d3:c1:a6:71:77:9a:84:3a:b6:1a:9d:46:5c:6f:11:cf:
         f0:ef:52:f5:c9:ac:8f:dd:40:0f:28:69:44:3b:c9:c1:c7:45:
         9c🇩🇪fb:48:95:89:90:9e:9e:74:e2:10:3a:52:e8:e0:30:ce:
         81:80:77:57:d9:32:02:fd:06:bd:72:e8:83:d8:3a:4e:6f:da:
         a5:07:44:cf:ba:3f:be:f1:79:ed:aa:01:65:a8:ea:f5:f6:ca:
         f0:dc:04:dd:8e:2e:78:93:75:31:c9:8f:c3:9b:40:19:fe:9b:
         fb:49:ca:b3:4e:81:39:d6:41:48:d6:80:30:a5:08:77:f6:24:
         93:d2:d0:67:5b:96:69:6a:12:f5:7c:5a:a3:f0:b2:2a:c1:69:
         76:f8:7f:b1:6c:d6:6c:a8:a9:62:aa:7a:7b:66:d0:52:bc:44:
         f5:4d:5d:1e:47:f0:00:ec:66:8a:05:43:a9:8c:23:1b:7c:ad:
         0d:24:9f:b9:5c:27:ca:e7:42:bb:10:02:e8:bf:1b:35:57:e8:
         6a:67:97:d5:dc:e0:6e:5e:fc:43:f9:26:d4:f1:32:87:15:86:
         8a:28:66:00:be:8f:fd:33:a4:50:97:35:56:a1:41:11:a4:92:
         5c:30:e3:6d:80:42:ef:a7:d7:f8:cb:ba:08:93:2e:61:73:b3:
         0c:c5:35:2f:9a:c9:9d:38:94:4c:43:15:fb:65:b7:f0:f6:7f:
         01:4b:6a:5b:a7:7c:f9:c2:a8:5c:dc:d3:30:41:1c:da:0e:e1:
         36:50:9c:6f:4a:e7:99:23:83:dd:c8:01:26:2d:e0:33:04:2a:
         0a:34:8b:78:47:bc:09:3b

Digital Certificate Formats

A digital certificate is embodied as an associated encrypted data file or a series of associated encrypted data files, commonly used in the following formats.

  • Conforms to the PKI ITU-T X509 standard, legacy standard (.DER .PEM .CER .CRT)
  • Compliant with the PKCS#7 encrypted message syntax standard (.P7B .P7C .SPC .P7R)
  • Compliant with PKCS#10 Certificate Request Standard (.p10)
  • Conforms to PKCS#12 Personal Information Exchange Standard (.pfx *.p12)

Of course, these are only a few of the commonly used standards, of which there are two other encoding forms for X509 certificates.

  • X.509 DER (Distinguished Encoding Rules) encoding with the suffix: .DER .CER .CRT
  • X.509 BASE64 encoding, suffix is: .PEM .CER .CRT

X.509 is the basic standard for digital certificates, while P7 and P12 are the two implementation specifications, P7 for digital envelopes and P12 for certificates with private keys. The contents of the generated digital certificate may be different depending on the adopted standard. The following is a summary of what the certificate contains/may contain, and the general certificate features are as follows

  • Storage format: binary or ASCII
  • whether to include the public key, private key
  • contains a certificate or multiple certificates
  • whether to support password protection (for the current certificate)

Among them.

  • DER, CER, CRT holds the certificate in binary form, with only the public key and no private key.
  • CSR certificate request.
  • PEM stores the certificate in Base64 encoded form, encapsulated with --BEGIN CERTIFICATE-- and --END CERTIFICATE-- encapsulation, public key only.
  • -PFX and -P12 also store certificates in binary form, containing public and private keys and including protection passwords. The storage formats of PFX and P12 are exactly the same, only the extensions are different.
  • P10 certificate request.
  • P7R is CA’s reply to certificate request, generally doing digital envelope.
  • P7B/P7C certificate chain, which can contain one or more certificates.

For example, PFX and P12 also store the certificate in binary form; DER indicates the certificate and has signature, in actual use, there is DER encoded private key without signature, which is actually just a “middleware”; in addition, the certificate signature request generally uses CSR extension, but its format may be PEM or DER format, but they all represent the certificate request, and the real certificate can be obtained only after CA issuance.