WO2022116734A1 - 数字证书签发的方法、装置、终端实体和*** - Google Patents

数字证书签发的方法、装置、终端实体和*** Download PDF

Info

Publication number
WO2022116734A1
WO2022116734A1 PCT/CN2021/125960 CN2021125960W WO2022116734A1 WO 2022116734 A1 WO2022116734 A1 WO 2022116734A1 CN 2021125960 W CN2021125960 W CN 2021125960W WO 2022116734 A1 WO2022116734 A1 WO 2022116734A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
terminal entity
entity
proxy device
terminal
Prior art date
Application number
PCT/CN2021/125960
Other languages
English (en)
French (fr)
Inventor
易孟
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2022116734A1 publication Critical patent/WO2022116734A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3249—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using RSA or related signature schemes, e.g. Rabin scheme
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]

Definitions

  • the embodiments of the present invention relate to the fields of information technology and communication technology, and in particular, to a method, an apparatus, a terminal entity and a system for issuing a digital certificate.
  • Communication between communication devices usually requires mutual trust, trusting communication between communication devices can be considered as cross-trust domain communication, and communication devices can also be referred to as network entities (NEs).
  • NEs network entities
  • the communication between multiple boards in a communication device is considered to belong to the communication in the same trust domain, and the communication between boards does not provide any security function.
  • transport layer security TLS
  • datagram transport layer security DTLS
  • internet protocol security IPSEC
  • MACSEC media access control layer security protocol
  • MACSEC media access control security protocol
  • CA certificate authority
  • the embodiments of the present invention provide a method, device, terminal entity and system for issuing a digital certificate.
  • the CA server authorizes the proxy device to send the intermediate certificate, and the proxy device issues the terminal entity certificate of each terminal to each terminal entity.
  • each terminal entity does not need to request the issuance of the digital certificate from the authorized certification CA server, thus reducing the burden on the CA server.
  • a first aspect provides a method for issuing a digital certificate.
  • the method includes: the terminal entity pre-generates a key pair of its own first terminal entity public key and the first terminal entity private key, and the proxy device pre-generates its own first terminal entity public key. A key pair of the proxy device public key and the first proxy device private key.
  • the proxy device receives the terminal entity certificate authorization request sent by the terminal entity.
  • the terminal entity certificate authorization request includes the public key of the first terminal entity. Since the proxy device itself has an intermediate certificate, it can issue a digital certificate for the terminal entity.
  • the authorization request generates a first terminal entity certificate for the first terminal entity public key, digitally signs the first terminal entity certificate using the first proxy device private key, obtains the digital signature value of the first terminal entity certificate, and generates a terminal entity certificate authorization response , and returns a terminal entity certificate authorization response to the terminal entity, thus realizing the issuance of the first terminal entity certificate by the proxy device.
  • the terminal entity certificate authorization response includes the first terminal entity certificate and the certificate chain of the first terminal entity certificate, the first terminal entity certificate includes the first terminal entity public key and the digital signature value of the first terminal entity certificate, and the first terminal entity certificate includes the first terminal entity public key and the digital signature value of the first terminal entity certificate.
  • the certificate chain of the certificate is used to verify whether the digital signature value of the first terminal entity certificate is correct, the certificate chain of the first terminal entity certificate includes the CA root certificate and the first intermediate certificate, and the first intermediate certificate is issued by the CA server to the proxy device,
  • the first intermediate certificate contains the public key of the first proxy device, so that the proxy device possessing the first intermediate certificate can issue a digital certificate for the terminal entity.
  • the proxy device possessing the intermediate certificate can issue digital certificates to each terminal entity.
  • there is only one CA server in a digital certificate management system and there can be multiple proxy devices, which avoids a large number of end entities from requesting a unique CA server for digital certificate authentication for end entities, thus reducing the risk of It reduces the load on the CA server and saves network bandwidth resources.
  • the proxy device since there may be a plurality of proxy devices, and the proxy devices can be set near the terminal entity, the proxy device can provide the terminal entity with a very secure, fast and convenient digital certificate authentication.
  • the method further includes: the proxy device sends an intermediate certificate authorization request including the public key of the first proxy device to the CA server, and the proxy device receives an intermediate certificate authorization response sent by the CA server, where the intermediate certificate authorization response includes the first intermediate certificate and the certificate chain of the first intermediate certificate, wherein the first intermediate certificate includes the public key of the first proxy device and the digital signature value of the first intermediate certificate, and the certificate chain of the first intermediate certificate includes the CA root certificate , the CA root certificate contains the CA root public key, the digital signature value of the first intermediate certificate is obtained by the CA server using the CA root private key to digitally sign the first intermediate certificate, and the CA root public key and the CA root private key are all A pair of key pairs generated by the CA server; the proxy device uses the certificate chain of the first intermediate certificate to verify that the digital signature value of the first intermediate certificate is correct. Therefore, the CA server can issue an intermediate certificate to the proxy device, so that the proxy device possessing the intermediate certificate can issue the digital certificate of the terminal entity to each terminal entity.
  • the method further includes: when the terminal entity needs to update its own terminal entity certificate, the terminal entity will generate a new key pair: the second terminal entity public key and the second terminal entity private key.
  • the proxy device receives a first certificate update request containing the public key of the second terminal entity sent by the terminal entity, the proxy device generates a second terminal entity certificate for the second terminal entity public key according to the first certificate update request, and uses the first certificate update request to generate a second terminal entity certificate for the public key of the second terminal entity.
  • a proxy device private key digitally signs the certificate of the second terminal entity, obtains the digital signature value of the certificate of the second terminal entity, generates and sends a first certificate update response to the terminal entity, wherein the first certificate update response contains the second terminal entity
  • terminal entity certificate needs to be updated, it is not necessary to go to the CA server to request to update the terminal entity certificate, but only need to request the proxy device located near the terminal entity to update the terminal entity certificate. In this way, a large number of terminal entities are prevented from going to the unique CA server to request the renewal of the digital certificate authentication, which reduces the load of the CA server and saves network bandwidth resources.
  • the method further includes: when the proxy device needs to update the intermediate certificate, the proxy device will generate a new key pair: the second proxy device public key and the second proxy device private key.
  • the proxy device sends a second certificate update request containing the public key of the second proxy device to the CA server, and the proxy device receives a second certificate update response sent by the CA server, wherein the second certificate update response contains the second intermediate certificate and the second intermediate certificate
  • the certificate chain of the certificate, the second intermediate certificate contains the public key of the second proxy device and the digital signature value of the second intermediate certificate, and the digital signature value of the second intermediate certificate is used by the CA server to use the CA root private key for the second intermediate certificate.
  • the certificate is obtained by digitally signing the certificate; when the proxy device uses the certificate chain of the second intermediate certificate to verify that the digital signature value of the second intermediate certificate is correct, the proxy device replaces the first intermediate certificate with the second intermediate certificate Intermediate certificate.
  • the proxy device requests the CA server to update the intermediate certificate in time, thus realizing the timely update of the intermediate certificate.
  • the method further includes: after the intermediate certificate is updated, the terminal entity needs to update and re-issue the terminal entity certificate to the proxy device, and the proxy device receives the first terminal entity public key sent by the terminal entity and contains the first terminal entity public key.
  • the proxy device generates a third terminal entity certificate for the first terminal entity public key according to the third certificate update request, and uses the second proxy device private key to digitally sign the third terminal entity certificate to obtain the third terminal entity certificate
  • the digital signature value of the entity certificate generate and send a third certificate update response to the terminal entity, wherein the third certificate update response contains the third terminal entity certificate and the certificate chain of the third terminal entity certificate, and the third terminal entity certificate contains the first The public key of the terminal entity and the digital signature value of the certificate of the third terminal entity.
  • the certificate chain of the certificate of the third terminal entity is used to verify whether the digital signature value of the certificate of the third terminal entity is correct.
  • the certificate chain of the certificate of the third terminal entity contains the CA root certificate. and the second intermediate certificate. After the intermediate certificate is updated, the proxy device re-issues a new terminal entity certificate for the terminal entity, and at this time, the validity of the terminal entity certificate is extended.
  • the method further includes: using the certificate chain of the second intermediate certificate to verify that the digital signature value of the second intermediate certificate is correct, specifically: the proxy device uses the CA root public key to verify the CA Whether the digital signature value of the root certificate is correct, when verifying that the digital signature value of the CA root certificate is incorrect, determine that the second intermediate certificate is incorrect; when verifying that the digital signature value of the CA root certificate is correct, use the CA root certificate key to verify whether the digital signature value of the second intermediate certificate is correct, when verifying that the digital signature value of the second intermediate certificate is incorrect, the second intermediate certificate is determined to be incorrect; when verifying that the digital signature value of the second intermediate certificate is incorrect When correct, it is determined that the second intermediate certificate is correct.
  • the present invention provides a method for issuing a digital certificate, including: the terminal entity pre-generates a key pair of its own first terminal entity public key and the first terminal entity private key, and the proxy device pre-generates its own key pair. A key pair of the first proxy device public key and the first proxy device private key.
  • the terminal entity sends the entity certificate authorization request including the public key terminal of the first terminal entity to the proxy device, and the terminal entity receives the terminal entity certificate authorization response sent by the proxy device, wherein the terminal entity certificate authorization response includes the first terminal entity certificate and the first terminal entity certificate.
  • the certificate chain of the entity certificate, the first terminal entity certificate contains the first terminal entity public key and the digital signature value of the first terminal entity certificate, and the certificate chain of the first terminal entity certificate is used to verify the digital signature of the first terminal entity certificate Whether the value is correct; use the certificate chain of the first terminal entity certificate to verify whether the digital signature value of the first terminal entity certificate is correct.
  • the proxy device possessing the intermediate certificate can issue digital certificates to each terminal entity.
  • there is only one CA server in a digital certificate management system and there can be multiple proxy devices, which avoids a large number of end entities from requesting a unique CA server for digital certificate authentication for end entities, thus reducing the risk of It reduces the load on the CA server and saves network bandwidth resources.
  • the proxy device since there may be a plurality of proxy devices, and the proxy devices can be set near the terminal entity, the proxy device can provide the terminal entity with a very secure, fast and convenient digital certificate authentication.
  • the method further includes: regenerating a key pair at the terminal entity: the public key of the second terminal entity and the private key of the second terminal entity, and the terminal entity sends the proxy device a key pair containing the public key of the second terminal entity.
  • the terminal entity receives the first certificate update response sent by the device, wherein the first certificate update response contains the second terminal entity certificate and the certificate chain of the second terminal entity certificate, and the second terminal entity certificate contains all the certificates.
  • the certificate chain of the second terminal entity certificate is used to verify whether the digital signature value of the second terminal entity certificate is correct; using the certificate chain of the second terminal entity certificate
  • the first terminal entity certificate is replaced with the second terminal entity certificate.
  • the method further includes: when the proxy device needs to update the intermediate certificate, the proxy device will generate a new key pair: the second proxy device public key and the second proxy device private key.
  • the terminal entity sends a third certificate update request containing the public key of the first terminal entity to the proxy device, and the terminal entity receives a third certificate update response sent by the proxy device, wherein the third certificate update response contains the third terminal entity certificate and the third certificate update response.
  • the certificate chain of the terminal entity certificate, the third terminal entity certificate contains the first terminal entity public key and the digital signature value of the third terminal entity certificate, and the certificate chain of the third terminal entity certificate is used to verify the digital signature value of the third terminal entity certificate Is it correct?
  • the proxy device When verifying that the digital signature value of the third terminal entity certificate is correct by using the certificate chain of the third terminal entity certificate, replace the first terminal entity certificate with the third terminal entity certificate. After the intermediate certificate is updated, the proxy device re-issues a new terminal entity certificate for the terminal entity, and at this time, the validity of the terminal entity certificate is extended.
  • the method further includes: the certificate chain of the first terminal entity certificate includes an authorized certification CA root certificate and a first intermediate certificate, and the first terminal entity certificate is verified by using the certificate chain of the first terminal entity certificate Whether the digital signature value of the CA root certificate is correct, specifically: using the CA root public key to verify whether the digital signature value of the CA root certificate is correct, and when verifying that the digital signature value of the CA root certificate is incorrect, determine that the first terminal entity certificate is incorrect.
  • verifying that the digital signature value of the CA root certificate is correct use the CA root public key to verify whether the digital signature value of the first intermediate certificate is correct, and when verifying that the digital signature value of the first intermediate certificate is incorrect, then determine that the first intermediate certificate is correct.
  • the terminal entity certificate is incorrect; when verifying that the digital signature value of the first intermediate certificate is correct, use the first proxy device public key included in the first intermediate certificate to verify whether the digital signature value of the first terminal entity certificate is correct.
  • the digital signature value of the first terminal entity certificate is incorrect, it is determined that the first terminal entity certificate is incorrect; when it is verified that the digital signature value of the first terminal entity certificate is correct, it is determined that the first terminal entity certificate is correct of.
  • the present application provides an apparatus for issuing a digital certificate, the apparatus including one or more units for implementing the method for issuing a digital certificate described in the first aspect.
  • the present application provides a terminal entity, where the terminal entity includes one or more modules for implementing the method for issuing a digital certificate described in the second aspect.
  • the present application provides a computer-readable storage medium, in which a computer program or instruction is stored, and when the computer program or instruction is executed by a proxy device, the proxy device is made to execute the above-mentioned first aspect or the first aspect.
  • a method in any possible implementation of an aspect.
  • the present application provides a computer-readable storage medium
  • the computer program product includes a computer program or instruction, which, when the computer program or instruction is executed by a terminal entity, causes the terminal entity to perform the above-mentioned second aspect or the second aspect method in any possible implementation of .
  • FIG. 1 is a schematic diagram of a chain relationship of a certificate chain provided by an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a digital certificate management system provided by an embodiment of the present invention.
  • FIG. 3 is a flowchart of a digital certificate issuance provided by an embodiment of the present invention.
  • FIG. 5 is a flowchart of a digital certificate update provided by an embodiment of the present invention.
  • FIG. 6 is a schematic structural diagram of an apparatus for issuing a digital certificate according to an embodiment of the present invention.
  • FIG. 7 is a schematic structural diagram of a terminal entity according to an embodiment of the present invention.
  • FIG. 8 is a schematic structural diagram of an apparatus for issuing a digital certificate according to an embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of a terminal entity according to an embodiment of the present invention.
  • Symmetric encryption algorithm The encryption and decryption parties use the same rules to encrypt and decrypt information.
  • Asymmetric encryption algorithm also known as public key cryptography or two-key cryptography.
  • Asymmetric encryption algorithms require two keys: a public key (public key, referred to as public key) and a private key (private key, referred to as private key).
  • the public key and the private key are a pair. If the data is encrypted with the public key, it can only be decrypted with the corresponding private key. If the data is encrypted with the private key, only the corresponding public key can be decrypted. Because encryption and decryption use two different keys.
  • the current typical asymmetric encryption algorithm is the RSA algorithm, designed by three mathematicians Rivest, Shamir and Adleman.
  • RSA cryptosystem is a public key cryptosystem, the public key is public, the private key is kept secret, and its encryption and decryption algorithms are public. Content encrypted by the public key can and only be decrypted by the private key, or content encrypted by the private key can and only be decrypted by the public key. That is to say, the pair of public and private keys of RSA can be used to encrypt and decrypt, and the encrypted content of one party can be decrypted by and only by the other party.
  • Digital signature also known as public key digital signature
  • digital signature is a piece of content appended to the data unit, or a cryptographic transformation of the data unit, which can prove that the data unit has not been modified. This data or transformation allows the recipient of the data unit to confirm the origin of the data unit and the integrity of the data unit and to protect the data from forgery by a person (eg, the recipient). It is a method of signing messages in electronic form, and a signed message can be transmitted over a communication network. Digital signatures can be obtained based on both public key cryptosystems and private key cryptosystems.
  • PKI Public key infrastructure
  • CA public key infrastructure
  • RA Registration Authority
  • the RA agency ensures the public key and personal identity link, which is non-repudiation.
  • PKI usually consists of the following parts: CA organization, RA organization, certificate store, key backup and recovery system, certificate revocation processing system, application system interface and certificate.
  • CA agency is the core executive agency of PKI, also known as certification authority or CA server.
  • the CA agency is the agency responsible for issuing certificates, certifying certificates and managing the issued certificates. Specifically, the CA agency can formulate policies and specific steps to verify, identify the user's identity, and sign the user's certificate to ensure the certificate holder's identity. Ownership of identity and public key, CA is an authoritative, trustworthy and impartial third-party organization.
  • the CA organization also has a hierarchical structure. In a large-scale PKI facility, due to the large number of users, using a CA organization for certificate verification and issuance services may be overloaded, so it is necessary to carry out the hierarchical deployment of the CA organization. In the hierarchical deployment of CA agencies, a top-down trust certificate chain needs to be established between CA agencies. The lower-level CA agency trusts the upper-level CA agency. Hierarchical relationships can be seen in the certificate chain.
  • RA organization It is an integral part of the CA organization, and is the application registration, approval, proofreading and management organization of the certificate.
  • the RA organization is also called the hierarchical structure.
  • RA is the general registration center, which is responsible for the summary of certificate application registration.
  • the RA agency is the window of the CA agency to the user. It is responsible for receiving the user's certificate application and verifying the user's identity.
  • the RA organization in PKI usually does not exist independently, but is merged with the CA organization.
  • Digital certificate a certificate for short, a certificate is a file issued by an issuing authority that contains the public key owner information and public key, and is digitally signed by the issuing authority, which is the technical basis for digital signatures.
  • the certificate generally contains the certificate version, certificate serial number, certificate signature algorithm, issuer information, certificate validity period, public key and user information.
  • the certificate serial number is issued by the issuing authority and is guaranteed to be unique within the scope of use of the certificate; the certificate The validity period includes the valid time of the certificate and the expiration time of the certificate; the issuer information is determined by the issuing authority, and the user information is determined by the certificate applicant.
  • a certificate can also contain key usage, certificate type, extended key usage, and certificate revocation list distribution point, where key usage indicates the functions and services that the certificate's public key can support, such as certificate signature, Key encryption (key encipherment), data encryption (data encipherment), key agreement (key agreement), certificate revocation list (Certification Revocation List, CRL) signature.
  • certificate signature and certificate revocation list signature can only be used by CA certificates. Therefore, although the key usage extension field is optional, it is an indispensable key extension for the root CA. item, and must have the two key usages of certificate signature and Certification Revocation List (CRL) signature.
  • the certificate types are root certificate (root certificate), intermediate certificate (intermediate certificate), and end-entity certificate (end-entity certificate).
  • the root certificate is a certificate issued by the CA agency to itself, and the digital signature of the root certificate is the root private certificate. Therefore, the root public key is required to verify the root certificate signature.
  • the digital signature of the root certificate is called a self-signature.
  • the intermediate certificate is issued by the CA agency.
  • the intermediate certificate contains the name of the root certificate.
  • the signature of the intermediate certificate is digitally signed with the root private key. Therefore, the validity of the intermediate certificate needs to be verified with the root public key.
  • the end entity certificate is signed by the owner of the intermediate certificate.
  • the end entity certificate contains the name of the intermediate certificate.
  • the digital signature of the end entity certificate is issued by the intermediate private key. Therefore, the validity of the end entity certificate needs to be verified with the intermediate public key. .
  • the root certificate or intermediate certificate has the ability to issue a certificate for its lower-level certificate.
  • the intermediate certificate has only one level.
  • the intermediate certificate can be called the second-level certificate, but the intermediate certificate can also have multiple levels.
  • the terminal entity certificate does not have the authorization ability to issue certificates, but only has the function of proving the identity of the terminal entity. It should be noted that the terminal entity here includes mobile phones, computers, single boards, servers, and network equipment. Various terminal entity certificates are used. A device to identify yourself.
  • a certificate chain is an ordered list of certificates and a trust relationship between certificates.
  • a certificate chain usually includes a three-level structure, a root certificate, an intermediate certificate, and an end-entity certificate, as shown in Figure 1.
  • the end entity certificate is at the bottom.
  • the end entity certificate contains the end entity information, the end entity public key and the digital signature value.
  • the upper level of the end-entity certificate is the intermediate certificate, that is, the end-entity certificate is issued by the authority that owns the intermediate certificate.
  • the intermediate certificate is authorized and issued by the CA authority.
  • Figure 1 shows only one intermediate certificate, but the certificate chain can have multiple intermediate certificates.
  • the top-level intermediate certificate is issued by the root certificate
  • the bottom-level intermediate certificate is used to issue the end entity certificate
  • the root certificate is issued by the CA issued by the institution.
  • the legitimacy of each certificate issuer of the entire certificate chain needs to be verified. Find the issuer's certificate layer by layer according to the certificate chain until the self-signed root certificate is found, and then verify the correctness of the digital signature value of the next level through the corresponding public key. If verified to be correct, the end-entity certificate is correct.
  • Certificate Management Protocol is an Internet protocol used for the behavior between the client (certificate owner and user) and the CA (certificate issuer) during certificate application and renewal operations in the PKI system .
  • CMP developed to the second version, referred to as CMPv2.
  • a network system architecture provided by an embodiment of the present invention includes: a CA server and a plurality of NEs, wherein the NEs may further include a service board (service board) and a control board (main control board).
  • a certificate management agent can be installed on the service board and the control board.
  • the security of communication between different network elements is increased by means of an encryption algorithm.
  • each service board in the NE can independently request a certificate issuance or certificate update service from the CA server.
  • the specific process of the certificate service may include the following: All the boards including the service board and the control board will be pre-set with an initial terminal entity certificate and an initial certificate chain indicating the identity of the board when they leave the factory.
  • the initial intermediate certificate and initial root certificate of the terminal certificate, the initial terminal entity certificate is usually issued by the network equipment manufacturer, not by the CA server.
  • the service veneer and the control veneer use the preset initial terminal entity certificate as the identity credential to establish the secure communication channel. DTLS/MACSEC.
  • control board and the service board can respectively request the CA server to issue a new certificate (ie, the terminal entity certificate certified by the CA server), and the CA server returns the certified certificate to the control board and the service board respectively.
  • the control board and the service board use the authenticated terminal entity certificate to replace the preset initial terminal entity certificate, so that the authenticated terminal entity certificate can be used as the authentication credential for communication between the control board and the service board.
  • an embodiment of the present invention discloses a new method for obtaining a certificate.
  • different stages of certificate obtaining are divided into four different embodiments for description below.
  • the device manufacturer can pre-configure the device's own initial end-entity certificate and initial certificate chain for each end-entity (such as a service board) and an agent device (such as a control board).
  • the initial certificate chain includes the initial intermediate certificate and the initial root certificate for issuing the initial terminal certificate.
  • the administrator can load the CA root certificate of the CA server itself for the proxy device in the network device.
  • the CA root certificate contains the CA root public key.
  • the CA root certificate is used by the CA server to contain the first key pair.
  • the CA root private key is a self-signed digital certificate, the first key pair is generated by the CA server, and the first key pair includes the CA root public key and the CA root private key.
  • the CA root public key can be used to verify whether the digital signature value of the message sent by the CA server to the proxy device is correct.
  • the digital signature value is signed with the CA root private key.
  • the CA certificate can also be loaded for the proxy device Chain, for the convenience of description, the following content is described by taking only the CA root certificate loaded as an example. If the CA certificate chain is loaded, it is necessary to use the digital certificates at all levels contained in the certificate chain to include various public keys to verify whether the digital signature values of the digital certificates at all levels are correct. The process will be described in detail in process step 308 below. Similarly, the CA server will import the preset initial end entity certificate and initial certificate chain of the proxy device.
  • the preset initial end entity certificate of the proxy device contains the public key of the initial proxy device
  • the preset end entity certificate of the proxy device is A digital certificate issued by the network device or an authority trusted by the network device using the private key of the initial proxy device contained in the second key pair, where the second key pair contains the public key of the initial proxy device and the private key of the initial proxy device.
  • the pre-set initial proxy device public key of the initial terminal entity certificate of the proxy device is used to verify whether the digital signature value of the message sent by the proxy device to the CA server is correct, and the digital signature is signed with the initial proxy device private key.
  • the method for implementing digital certificate issuance of the proxy device includes:
  • Step 301 The proxy device generates a third key pair of the proxy device itself, where the third key pair includes the first proxy device public key and the first proxy device private key.
  • the third key pair includes the first proxy device public key and the first proxy device private key.
  • the proxy device constructs an intermediate certificate authorization request, which includes the applicant information (that is, the proxy device information, such as the proxy device name, etc.) and the public key of the first proxy device, and uses the initial proxy device private key to perform the intermediate certificate authorization request. Digitally sign, and then send the digitally signed intermediate certificate authorization request to the CA server.
  • the intermediate certificate authorization request may be carried by a CMP message, a CMPv2 message, or a message of other message types, for example, the CMPv2 message is specifically an initialization request (initialization request, IR).
  • Step 302 The CA server receives the intermediate certificate authorization request, and the CA server verifies whether the digital signature value of the intermediate certificate authorization request is correct using the initial proxy device public key contained in the initial terminal entity certificate of the preloaded proxy device. Generate a first intermediate certificate for the proxy device according to the applicant information contained in the intermediate certificate authorization request and the public key of the first proxy device, and use the CA root private key to digitally sign the first intermediate certificate.
  • the first intermediate certificate contains the first intermediate certificate. Agent device public key.
  • the CA server generates an intermediate certificate authorization response including the first intermediate certificate, and uses the CA root private key to digitally sign the intermediate certificate authorization response, and sends the digitally signed intermediate certificate authorization response to the proxy device.
  • the intermediate certificate authorization response also includes The certificate chain of the first intermediate certificate.
  • the intermediate certificate authorization response may be carried by an IP message or a message in a format such as CMPv2, and the certificate chain of the first intermediate certificate includes the CA root certificate.
  • intermediate certificate a there are multiple intermediate certificates, for example, there are three intermediate certificates, namely: intermediate certificate a, intermediate certificate b, and intermediate certificate c
  • the relationship between these three certificates is: the first intermediate certificate a
  • the first-level certificate is the CA root certificate, that is to say, the CA root certificate is used to digitally sign the intermediate certificate a
  • the upper-level certificate of the intermediate certificate b is the intermediate certificate a, that is to say, the public key contained in the intermediate certificate a is used as the intermediate certificate b.
  • Digital signature the upper-level certificate of intermediate certificate c is intermediate certificate b, that is to say, the public key contained in intermediate certificate b is used to digitally sign intermediate certificate c.
  • intermediate certificate c is the above-mentioned first intermediate certificate.
  • the certificate chain of the first intermediate certificate includes the CA root certificate, the intermediate certificate a, and the intermediate certificate b.
  • the embodiment of the present invention uses only one intermediate certificate as an example to describe the solution, and there are multiple intermediate certificates.
  • the scheme process of the certificate is similar to that of the existence of an intermediate certificate, so it is not repeated here.
  • Step 303 The proxy device receives the intermediate certificate authorization response, and uses the preloaded CA root public key of the CA root certificate to respectively verify the digital signature value of the intermediate certificate authorization response, and uses the certificate chain of the first intermediate certificate to verify the first intermediate certificate.
  • the proxy device sends a certificate confirmation message to the CA server to confirm receipt of the first intermediate certificate.
  • the certificate confirmation message can be a CertConf message.
  • the process of using the certificate chain of the first intermediate certificate to verify whether the digital signature value of the first intermediate certificate is correct is as follows: the proxy device obtains all the certificates from the certificate chain of the first intermediate certificate, in this embodiment of the present invention, it is only the CA root certificate, Then use the pre-loaded CA root public key to verify whether the digital signature value of the CA root certificate is correct. If the digital signature value of the CA root certificate is incorrect, it is determined that the first intermediate certificate is incorrect. If it is correct, the CA root certificate is used. The public key verifies whether the digital signature value of the first intermediate certificate is correct. If the digital signature value of the first intermediate certificate is verified to be incorrect, it is determined that the first intermediate certificate is incorrect. If the digital signature value of the first intermediate certificate is verified to be incorrect is correct, it is determined that the first intermediate certificate is correct.
  • the process of verifying whether the digital signature value of the first intermediate certificate is correct by using the certificate chain of the first intermediate certificate is as follows: The proxy device obtains all certificates from the certificate chain of the first intermediate certificate, and then uses the pre-loaded CA root public key to verify whether the digital signature value of the CA root certificate is correct, if the digital signature value of the CA root certificate is incorrect , then it is determined that the first intermediate certificate is incorrect. If the digital signature value of the CA root certificate is verified to be correct, then the CA root public key is used to verify whether the digital signature value of the intermediate certificate a is correct.
  • the digital signature of the intermediate certificate a is verified If the value is incorrect, it is determined that the first intermediate certificate is incorrect. If it is verified that the digital signature value of intermediate certificate a is correct, the public key contained in intermediate certificate a is used to verify whether the digital signature value of intermediate certificate b is correct. If the digital signature value of the intermediate certificate b is incorrect, it means that the first intermediate certificate is incorrect. If the digital signature value of the intermediate certificate b is verified to be correct, the public key contained in the intermediate certificate b is used to verify the first intermediate certificate.
  • Step 304 After receiving the certificate confirmation message, the CA server sends a PKI confirmation (PKIConf) message to the proxy device to confirm receipt of the certificate confirmation message.
  • PKIConf PKI confirmation
  • Step 305 After the proxy device receives the first intermediate certificate sent by the CA server, the proxy device sends a certificate application notification to each terminal entity.
  • each terminal entity and proxy device are pre-set with the initial terminal entity certificate and initial terminal root certificate and proxy device issued by the manufacturer. After the terminal entity goes online, it automatically establishes a secure communication channel (TLS/DTLS/MASEC, etc.) with the proxy device. Pre-set end-entity certificates are used as authentication credentials.
  • the proxy device in addition to an intermediate certificate that can issue a digital certificate for the terminal entity, the proxy device also has a terminal entity certificate that certifies the identity of the proxy device.
  • Step 306 The terminal entity generates a fourth key pair of the terminal entity itself, where the fourth key pair includes the public key of the first terminal entity and the private key of the first terminal entity.
  • the terminal entity constructs the terminal entity certificate authorization request, and the terminal entity certificate authorization request includes the applicant information (that is, the terminal entity information, such as the name of the terminal entity) and the public key of the first terminal entity, And use the initial terminal entity private key of the initial terminal entity certificate to digitally sign the terminal entity certificate authorization request, and then send the digitally signed terminal entity certificate authorization request to the proxy device through the secure channel between the boards.
  • the end-entity certificate authorization request may be carried by a CMP message, a CMPv2 message, or a message of other message types.
  • Step 307 the proxy device receives the end entity certificate authorization request from the secure channel, and uses the initial end entity public key obtained from the preloaded initial end entity certificate of the first end entity to verify the end entity certificate authorization request Is the digital signature value correct. If the verification fails, the terminal entity certificate authorization request is considered to be an untrusted message, and the proxy device does not process the terminal entity certificate authorization request, or returns a warning message to the terminal entity. If the verification is passed, the proxy device generates the first terminal entity certificate for the terminal entity according to the first intermediate certificate, the applicant information contained in the terminal entity certificate authorization request, and the public key of the first terminal entity, and uses the first proxy device private key to generate the first terminal entity certificate for the terminal entity.
  • a terminal entity certificate is digitally signed, and the first terminal entity certificate contains the first terminal entity public key.
  • the proxy device generates a terminal entity certificate authorization response that includes the digitally signed first terminal entity certificate and the certificate chain of the first terminal entity certificate, and the proxy device can use the initial proxy device private key of the proxy device's initial terminal entity certificate as the terminal entity certificate.
  • the authorization response is digitally signed, and the terminal entity certificate authorization response is sent to the terminal entity through the secure channel between the boards.
  • the certificate chain of the first terminal entity certificate includes the CA root certificate and the first intermediate certificate.
  • Step 308 The terminal entity receives the terminal entity certificate authorization response of the proxy device from the secure channel, and uses the initial terminal entity public key of the initial terminal certificate of the proxy device to verify whether the digital signature value of the terminal entity certificate authorization response is correct, if the verification result is If it is incorrect, it is considered that the certificate authorization response of the terminal entity is an untrusted message, and the proxy device does not process the certificate authorization response of the terminal entity, or returns a warning message to the terminal entity. If the verification result is correct, the certificate chain of the first terminal entity certificate is used to verify whether the digital signature value of the first terminal entity certificate is correct, so as to ensure that the first terminal entity certificate is correct.
  • the process of verifying whether the digital signature value of the first terminal entity certificate is correct by using the certificate chain of the first terminal entity certificate includes: the terminal entity first obtains all digital certificates included in the certificate chain from the certificate chain of the first terminal entity certificate, namely: the first intermediate
  • the certificate and the CA root certificate are used to verify whether the digital signature value contained in the CA root certificate is correct by using the CA root public key.
  • the verification result is incorrect, it means that the first terminal entity certificate is incorrect.
  • use the CA root certificate containing the CA root public key to verify whether the digital signature value contained in the first intermediate certificate is correct, and when the verification result is incorrect, it means that the first terminal entity certificate is incorrect .
  • the verification result uses the first intermediate certificate to include the first proxy device public key to verify whether the digital signature value contained in the first terminal entity certificate is correct, and when the verification result is incorrect, it means that the first terminal entity certificate is incorrect.
  • the verification result it means that the certificate of the first terminal entity is correct.
  • the process of verifying the CA root certificate, the intermediate certificate a and the intermediate certificate b is the same as the content introduced in step 303
  • the present invention if the certificate chain of the second intermediate certificate or the certificate chain of the third terminal entity certificate includes the CA root certificate, the intermediate certificate a and the intermediate certificate b, the process of verifying the CA root certificate, the intermediate certificate a and the intermediate certificate b is the same as step 303. content presented.
  • the terminal entity and the proxy device use their respective initial terminal entity private keys to digitally sign the message respectively, and the terminal entity and the proxy device use the corresponding initial terminal entity public key to verify the message respectively. Is the digital signature value correct.
  • the proxy device can also generate a fifth key pair of the proxy device itself, where the fifth key For including the public key of the terminal entity of the proxy device and the private key of the terminal entity of the proxy device, the proxy device can use the first proxy device private key of the first intermediate certificate to issue a terminal entity certificate for the proxy device, and the terminal entity of the proxy device can use the first proxy device private key of the first intermediate certificate to issue the proxy device.
  • the certificate contains the public key of the end entity of the proxy device.
  • the terminal entity can also use the private key of the first terminal entity to digitally sign the message, and the proxy device can also use the public key of the first terminal entity to check whether the digital signature value of the message is correct
  • the proxy device can also use the private key of the terminal entity of the proxy device to digitally sign the message
  • the terminal entity can also use the public key of the terminal entity of the proxy device to check whether the digital signature value of the message is correct.
  • the terminal entity may send a certificate obtaining notification to the proxy device.
  • Step 309 The proxy device detects that all terminal entities have successfully applied for the certificate of the first terminal entity, and sends a certificate switching notification to each terminal entity through a secure channel.
  • the proxy device may store a terminal entity list locally, where the terminal entity list records whether the terminal entity has received the first terminal entity certificate.
  • Step 310 After receiving the certificate switching notification, each terminal entity replaces the preset initial terminal entity certificate with the first terminal entity certificate issued by the proxy device.
  • the CA server in the digital certificate management system, can issue an intermediate certificate to the proxy device, so the proxy device having the intermediate certificate can issue digital certificates to each terminal entity.
  • the CA server there is only one CA server in a digital certificate management system, and there can be multiple proxy devices, which avoids a large number of end entities from requesting a unique CA server for digital certificate authentication for end entities, thus reducing the risk of It reduces the load on the CA server and saves network bandwidth resources.
  • the proxy device can be set near the terminal entity, for example, the service veneer (as the terminal entity) and the control veneer (as the proxy device) located in the same network device, the service veneer The communication with the control board is faster and more secure, so the proxy device can provide the end entity with a very secure, fast and convenient digital certificate authentication.
  • the terminal entity needs to request the proxy device to update the first terminal entity certificate in time. After the first end entity certificate is updated successfully.
  • the flow of the certificate update method is as follows:
  • Step 401 When the terminal entity determines that it needs to re-apply for the terminal entity certificate to the proxy device, it regenerates a sixth key pair of the terminal entity itself, and the sixth key pair includes the second terminal entity public key and the second terminal entity private key.
  • the terminal entity constructs a first certificate update request, the first certificate update request includes the second terminal entity public key and the applicant information (that is, the information of the terminal entity), and uses the second terminal entity private key to digitize the first certificate update request. Sign, and send the first certificate update request to the proxy device through the inter-board security channel.
  • the terminal entity can periodically detect whether the expiration date of the first terminal entity certificate is within the update range, when it is detected that the expiration date of the first terminal entity certificate of the terminal entity is already within the update range, or the terminal entity periodically detects When the corresponding private key is damaged or leaked, the terminal entity determines that it needs to apply for the terminal entity certificate from the CA server again.
  • Step 402 The proxy device receives the first certificate update request, first uses the second terminal entity public key in the first certificate update request to verify whether the digital signature value of the first certificate update request is correct, and when the verification result is correct, according to the first certificate update request.
  • the applicant information and the public key of the second terminal entity contained in a certificate update request generate a second terminal entity certificate, and use the private key of the first proxy device related to the first intermediate certificate to digitally sign the second terminal entity certificate.
  • the proxy device generates a first certificate update response, where the first certificate update response includes the digitally signed second terminal entity certificate and the certificate chain of the second terminal entity certificate, and the proxy device sends the first certificate update response to the terminal through the secure channel entity, the certificate chain of the second terminal entity certificate at this time includes the CA root certificate and the first intermediate certificate.
  • Step 403 The terminal entity receives the first certificate update response of the proxy device from the secure channel, and uses the public key of the first proxy device related to the first intermediate certificate to verify whether the digital signature value of the first certificate update response is correct. If it is correct, confirm that the first certificate update response is untrusted; if the verification result is correct, confirm that the first certificate update response is trusted, and use the certificate chain of the second terminal entity certificate to verify the digital signature of the second terminal entity certificate Check whether the value is correct to ensure that the certificate of the second terminal entity is trusted. After the verification is passed, the certificate of the second terminal entity is used to replace the certificate of the first terminal entity.
  • the process of verifying whether the digital signature value of the certificate of the second terminal entity is correct by using the certificate chain of the certificate of the second terminal entity includes: the terminal entity first obtains all the digital certificates included in the certificate chain from the certificate chain of the certificate of the second terminal entity, namely: the first intermediate certificate and the CA root certificate, and use the CA root public key to verify whether the digital signature value contained in the CA root certificate is correct.
  • the verification result is incorrect, it means that the second terminal entity certificate is incorrect.
  • the verification result When the verification result is correct, continue to use the first intermediate certificate to include the public key of the first proxy device to verify whether the digital signature value contained in the certificate of the second terminal entity is correct.
  • the verification result When the verification result is incorrect, it means that the second terminal entity The certificate is incorrect.
  • the verification result is correct, it means that the certificate of the second terminal entity is correct.
  • the proxy device possessing the intermediate certificate can issue digital certificates to each terminal entity, when the terminal entity certificate needs to be updated, it is not necessary to go to the CA server to request to update the terminal entity certificate , but only need to request the renewal of the certificate of the terminal entity from the proxy device located near the terminal entity. In this way, a large number of terminal entities are prevented from going to the unique CA server to request the renewal of the digital certificate authentication, which reduces the load of the CA server and saves network bandwidth resources.
  • the proxy device can provide very secure, fast and convenient renewal management of digital certificates to end entities.
  • the network device When the first intermediate certificate of the network device is about to expire or the corresponding private key is damaged or leaked, the network device needs to request the CA server to update the first intermediate certificate in time. After the first intermediate certificate is successfully updated, the proxy device needs to notify each terminal entity to update the first terminal entity certificate, and use the new intermediate certificate (ie the second intermediate certificate) to re-issue a new terminal entity certificate (ie the third terminal entity certificate) to each terminal entity. entity certificate).
  • the flow of the certificate update method includes the following:
  • Step 501 When the proxy device determines that it needs to re-apply for an intermediate certificate from the CA server, it regenerates a seventh key pair of the proxy device itself, where the seventh key pair includes the second proxy device public key and the second proxy device private key.
  • the proxy device constructs a second certificate update request, and the second certificate update request includes the applicant information (specifically, proxy device information, such as proxy device name) and the second proxy device public key, and uses the second proxy device private key to pair the first proxy device.
  • the second certificate update request is digitally signed, and then the digitally signed second certificate update request is sent to the CA server through the https channel.
  • the second certificate update request may be carried by a key update request (Key Update Request, KUR).
  • the proxy device can periodically detect whether the expiration date of the first intermediate certificate is within the update range. When it detects that the expiration date of the first intermediate certificate of the terminal entity is already within the update range, or the proxy device periodically detects the private key corresponding to the first intermediate certificate When damage or leakage occurs, the proxy device determines that it needs to apply for an intermediate certificate from the CA server again.
  • Step 502 The CA server receives the second certificate update request, and uses the public key of the second proxy device included in the second certificate update request to verify whether the digital signature value of the second certificate update request is correct.
  • the public key of the second proxy device and the applicant information in the certificate update request generate a new intermediate certificate for the proxy device (referred to as the second intermediate certificate later), and use the CA root private key to digitally sign the second intermediate certificate.
  • the CA server generates a second certificate update response including the second intermediate certificate and the certificate chain of the second intermediate certificate, and uses the CA root private key to digitally sign the second certificate update response.
  • the CA server uses the https channel to digitally sign the second certificate update response.
  • the certificate update response is sent to the proxy device.
  • the second certificate update response may be carried by a key update response (Key Update Response, KUP).
  • KUP Key Update Response
  • Step 503 The proxy device receives the second certificate update response, and uses the CA root public key of the CA root certificate to verify whether the digital signature value of the second certificate update response is correct. When the verification result is correct, it means that the received second certificate update If the response is correct, the proxy device sends a certificate confirmation message to the CA server to confirm receipt of the second intermediate certificate.
  • Step 504 The CA server sends a PKI confirmation message to the main control unit to confirm receipt of the certificate confirmation message.
  • Step 505 After receiving the PKI confirmation message, the proxy device sends an intermediate certificate update notification to each terminal entity.
  • Step 506 After receiving the intermediate certificate update notification, the terminal entity generates a third certificate update request, the third certificate update request includes the public key of the first terminal entity and the applicant information (information of the terminal entity), using the first terminal entity The private key digitally signs the third certificate update request, and sends the third certificate update request to the proxy device through the inter-board security channel.
  • Step 507 After receiving the third certificate update request, the proxy device first uses the public key of the first terminal entity in the third certificate update request to verify whether the digital signature value of the third certificate update request is correct.
  • the applicant information and the public key of the first terminal entity included in the certificate update request generate a third terminal entity certificate, and use the second proxy device private key related to the second intermediate certificate to digitally sign the third terminal entity certificate.
  • the proxy device generates a third certificate update response, where the third certificate update response includes the digitally signed third terminal entity certificate and the certificate chain of the third terminal entity certificate, and the proxy device sends the third certificate update response to the terminal through the secure channel entity, the certificate chain of the third terminal entity certificate at this time includes the CA root certificate and the second intermediate certificate.
  • Step 508 The terminal entity receives the third certificate update response from the proxy device from the secure channel, and verifies whether the digital signature value of the third terminal entity certificate and the certificate chain of the third terminal entity certificate is correct to ensure its legality. Replace the first end-entity certificate with the third end-entity certificate.
  • the terminal entity first obtains all the digital certificates contained in the certificate chain from the certificate chain of the certificate of the third terminal entity, namely: the second intermediate certificate and the CA root certificate, and uses the CA root certificate containing the CA root public key to verify the digital signature value contained in the CA root certificate Whether it is correct or not, when the verification result is incorrect, it means that the certificate of the third terminal entity is incorrect.
  • the verification result use the CA root certificate containing the CA root public key to verify whether the digital signature value contained in the second intermediate certificate is correct, and when the verification result is incorrect, it means that the third terminal entity certificate is incorrect .
  • the verification result When the verification result is correct, use the second intermediate certificate containing the public key of the second proxy device to verify whether the digital signature value contained in the third terminal entity certificate is correct, and when the verification result is incorrect, it means that the third terminal entity certificate is incorrect. When the verification result is correct, it means that the certificate of the third terminal entity is correct.
  • Step 509 After the proxy device detects that all terminal entities have successfully updated their certificates, it revokes all the first terminal entity certificates issued using the private key of the initial proxy device, generates a certificate revocation notification including CRL information, and passes the inter-board security channel. A certificate revocation notification is sent so as to notify each end entity to revoke the certificate of the first end entity.
  • Step 510 The terminal entity receives the certificate revocation notification, and imports the CRL information carried in the message into the context of the inter-board secure connection to revoke the certificate of the first terminal entity.
  • the proxy device possessing the intermediate certificate can issue digital certificates to each terminal entity, when the intermediate certificate needs to be updated, a large number of terminal entities do not need to request the CA server to update the intermediate certificate
  • the proxy device only needs to request the CA server to update the intermediate certificate, which avoids the need for a large number of terminal entities to update the intermediate certificate to the unique CA server, which reduces the load of the CA server and saves network bandwidth resources.
  • the proxy device updates the intermediate certificate, it sends an intermediate certificate update notification to the terminal entity in time, so that the terminal entity updates the terminal entity certificate in time.
  • an embodiment of the present application provides an apparatus 600 for issuing a digital certificate.
  • the apparatus 600 may be deployed in the proxy device provided in the embodiment shown in FIG. 3, FIG. 4, or FIG. 5, and includes: a receiving unit 601, which uses receiving a terminal entity certificate authorization request sent by a terminal entity, where the terminal entity certificate authorization request includes the first terminal entity public key;
  • a certificate issuing unit 602 configured to generate a first terminal entity certificate for the first terminal entity public key according to the terminal entity certificate authorization request, and use the first proxy device private key to digitally sign the first terminal entity certificate , obtain the digital signature value of the first terminal entity certificate, and generate a terminal entity certificate authorization response, wherein the terminal entity certificate authorization response includes the first terminal entity certificate and the certificate chain of the first terminal entity certificate,
  • the first terminal entity certificate includes the first terminal entity public key and the digital signature value of the first terminal entity certificate
  • the certificate chain of the first terminal entity certificate is used to verify the authenticity of the first terminal entity certificate.
  • the certificate chain of the first terminal entity certificate includes the authorized certification CA root certificate and the first intermediate certificate, wherein the first intermediate certificate includes the public key of the first proxy device, the first proxy device
  • the public key and the private key of the first proxy device are a pair of key pairs generated by the proxy device.
  • the sending unit 603 is configured to send the terminal entity certificate authorization response to the terminal entity.
  • the apparatus 600 further includes a verification unit 604 .
  • the sending unit 603 is further configured to send an intermediate certificate authorization request to the authorized certification CA server, where the intermediate certificate authorization request includes the public key of the first proxy device.
  • the receiving unit 601 is further configured to receive an intermediate certificate authorization response sent by the CA server, where the intermediate certificate authorization response includes the first intermediate certificate and the certificate chain of the first intermediate certificate, the first intermediate certificate
  • the intermediate certificate includes the public key of the first proxy device and the digital signature value of the first intermediate certificate, wherein the certificate chain of the first intermediate certificate includes the CA root certificate, the CA root certificate includes the CA root public key, and the The digital signature value of the first intermediate certificate is obtained by the CA server using the CA root private key to digitally sign the first intermediate certificate, and the CA root public key and the CA root private key are one generated by the CA server. key pair.
  • a verification unit 604 configured to verify that the digital signature value of the first intermediate certificate is correct using the certificate chain of the first intermediate certificate.
  • the receiving unit 601 is further configured to receive a first certificate update request sent by the terminal entity, where the first certificate update request includes the public key of the second terminal entity.
  • the certificate issuing unit 602 is further configured to generate a second terminal entity certificate for the second terminal entity public key according to the first certificate update request, and use the first proxy device private key to pair the The second terminal entity certificate is digitally signed, the digital signature value of the second terminal entity certificate is obtained, and a first certificate update response is generated, wherein the first certificate update response includes the second terminal entity certificate and the first certificate update response.
  • a certificate chain of two end-entity certificates the second end-entity certificate includes the second end-entity public key and the digital signature value of the second end-entity certificate, and the certificate chain of the second end-entity certificate is used for verification Whether the digital signature value of the second terminal entity certificate is correct, and the certificate chain of the second terminal entity certificate includes the CA root certificate and the first intermediate certificate.
  • the sending unit 603 is further configured to send the first certificate update response to the terminal entity.
  • the apparatus 600 further includes a replacement unit 605, and the replacement unit 605 is configured to use the certificate chain of the second intermediate certificate to verify that the digital signature value of the second intermediate certificate is correct. , and replace the first intermediate certificate with the second intermediate certificate.
  • the sending unit 603 is further configured to send a second certificate update request to the CA server, where the second certificate update request includes the public key of the second proxy device.
  • the receiving unit 601 is further configured to receive a second certificate update response sent by the CA server, where the second certificate update response includes a second intermediate certificate and a certificate chain of the second intermediate certificate, the The second intermediate certificate contains the public key of the second proxy device and the digital signature value of the second intermediate certificate, wherein the digital signature value of the second intermediate certificate is used by the CA server to use the CA root private key for the second intermediate certificate.
  • the intermediate certificate is digitally signed.
  • the receiving unit 601 is further configured to receive a third certificate update request sent by the terminal entity, where the third certificate update request includes the public key of the first terminal entity.
  • the certificate issuing unit 602 is further configured to generate a third terminal entity certificate for the first terminal entity public key according to the third certificate update request, and use the second proxy device private key to pair the The third terminal entity certificate is digitally signed, the digital signature value of the third terminal entity certificate is obtained, and a third certificate update response is generated, wherein the third certificate update response includes the third terminal entity certificate and the third certificate update response.
  • the certificate chain of the terminal entity certificate, the third terminal entity certificate contains the public key of the first terminal entity and the digital signature value of the third terminal entity certificate, and the certificate chain of the third terminal entity certificate is used to verify all Whether the digital signature value of the third terminal entity certificate is correct, the certificate chain of the third terminal entity certificate includes the CA root certificate and the second intermediate certificate, the second proxy device private key and the second proxy device
  • the public key is a pair of key pairs generated by the proxy device.
  • the sending unit 603 is further configured to send the third certificate update response to the terminal entity.
  • the replacement unit 605 is specifically configured to use the CA root public key to verify whether the digital signature value of the CA root certificate is correct, and when verifying that the digital signature value of the CA root certificate is incorrect, determine the second The intermediate certificate is incorrect; when verifying that the digital signature value of the CA root certificate is correct, use the CA root public key to verify whether the digital signature value of the second intermediate certificate is correct.
  • the digital signature value of the certificate is incorrect, it is determined that the second intermediate certificate is incorrect; when it is verified that the digital signature value of the second intermediate certificate is correct, it is determined that the second intermediate certificate is correct .
  • the proxy device with the intermediate certificate can issue digital certificates to each end entity.
  • there is only one CA server in a digital certificate management system and there can be multiple proxy devices, which avoids a large number of terminal entities requesting a unique CA server for digital certificate authentication for terminal entities, which reduces the It reduces the load on the CA server and saves network bandwidth resources.
  • the proxy device can provide the terminal entity with a very secure, fast and convenient digital certificate authentication.
  • an embodiment of the present application provides a terminal entity 700, and the terminal entity 700 may be deployed in the terminal entity provided in the embodiment shown in FIG. 3, FIG. 4, or FIG. 5, including:
  • the sending module 701 is configured to send a terminal entity certificate authorization request to the proxy device, where the terminal entity certificate authorization request includes the first terminal entity public key.
  • a receiving module 702 configured to receive a terminal entity certificate authorization response sent by the proxy device, wherein the terminal entity certificate authorization response includes a first terminal entity certificate and a certificate chain of the first terminal entity certificate, the first terminal entity certificate
  • the terminal entity certificate contains the first terminal entity public key and the digital signature value of the first terminal entity certificate, and the certificate chain of the first terminal entity certificate is used to verify whether the digital signature value of the first terminal entity certificate is correct.
  • a verification module 703, configured to verify whether the digital signature value of the first terminal entity certificate is correct by using the certificate chain of the first terminal entity certificate.
  • the sending module 701 is further configured to send a first certificate update request to the proxy device, where the first certificate update request includes the public key of the second terminal entity.
  • the receiving module 702 is further configured to receive the first certificate update response sent by the proxy device, where the first certificate update response includes the second terminal entity certificate and the second terminal entity certificate
  • the certificate chain of the second terminal entity includes the public key of the second terminal entity and the digital signature value of the certificate of the second terminal entity, and the certificate chain of the certificate of the second terminal entity is used to verify the second terminal entity certificate. Whether the digital signature value of the end-entity certificate is correct.
  • the terminal entity further includes a replacement module 704, configured to use the certificate chain of the second terminal entity certificate to verify that the digital signature value of the second terminal entity certificate is correct, replace the first terminal The entity certificate is replaced with the second end entity certificate.
  • the sending module 701 is further configured to send a third certificate update request to the proxy device, where the third certificate update request includes the public key of the first terminal entity.
  • the receiving module 702 is further configured to receive a third certificate update response sent by the proxy device, where the third certificate update response includes the third terminal entity certificate and the third terminal entity certificate.
  • a certificate chain, the third terminal entity certificate includes the first terminal entity public key and the digital signature value of the third terminal entity certificate, and the certificate chain of the third terminal entity certificate is used to verify the third terminal Whether the digital signature value of the entity certificate is correct.
  • the replacement module 704 is further configured to use the certificate chain of the third terminal entity certificate to verify that the digital signature value of the third terminal entity certificate is correct, and replace the first terminal entity certificate with the third end entity certificate.
  • the verification module 703 is specifically configured to use the CA root public key to verify whether the digital signature value of the CA root certificate is correct, and when verifying that the digital signature value of the CA root certificate is incorrect When verifying that the first terminal entity certificate is incorrect; when verifying that the digital signature value of the CA root certificate is correct, use the CA root public key to verify whether the digital signature value of the first intermediate certificate is correct , when verifying that the digital signature value of the first intermediate certificate is incorrect, it is determined that the first terminal entity certificate is incorrect; when verifying that the digital signature value of the first intermediate certificate is correct, use the The first proxy device public key included in the first intermediate certificate verifies whether the digital signature value of the first terminal entity certificate is correct, and when it is verified that the digital signature value of the first terminal entity certificate is incorrect, it is determined that the digital signature value of the first terminal entity certificate is incorrect. The first terminal entity certificate is incorrect; when it is verified that the digital signature value of the first terminal entity certificate is correct, it is determined that the first terminal entity certificate is correct.
  • the receiving module 702 is further configured to receive a certificate application notification sent by the proxy device.
  • an embodiment of the present application provides a schematic diagram of an apparatus 800 for issuing a digital certificate.
  • the apparatus 800 may be the proxy device in any of the foregoing embodiments.
  • the apparatus 800 includes at least one processor 801 , internal connections 802 , memory 803 and at least one transceiver 804 .
  • the apparatus 800 is an apparatus with a hardware structure, and can be used to implement the functional modules in the apparatus 600 described in FIG. 6 .
  • the certificate issuing unit 602, the verification unit 604 or the replacement unit 605 in the apparatus 600 shown in FIG. 6 can be implemented by calling the code in the memory 803 by the at least one processor 801, as shown in FIG. 6
  • the receiving unit 601 and the sending unit 603 in the apparatus 600 can be implemented by the transceiver 804 .
  • the apparatus 800 may also be used to implement the function of the proxy apparatus in any of the foregoing embodiments.
  • processor 801 may be a general-purpose central processing unit (central processing unit, CPU), network processor (network processor, NP), microprocessor, application-specific integrated circuit (application-specific integrated circuit, ASIC) , or one or more integrated circuits used to control the execution of the program of this application.
  • CPU central processing unit
  • NP network processor
  • ASIC application-specific integrated circuit
  • the internal connection 802 described above may include a path to transfer information between the above described components.
  • the internal connection 802 is a single board or a bus or the like.
  • the above transceiver 804 is used to communicate with other devices or communication networks.
  • the above-mentioned memory 803 can be a read-only memory (read-only memory, ROM) or other types of static storage devices that can store static information and instructions, a random access memory (random access memory, RAM) or other types of storage devices that can store information and instructions.
  • types of dynamic storage devices which can also be electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM), or other optical disk storage, optical disks storage (including compact discs, laser discs, compact discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or capable of carrying or storing desired program code in the form of instructions or data structures and capable of being accessed by Any other medium accessed by the computer without limitation.
  • the memory can exist independently and be connected to the processor through a bus.
  • the memory can also be integrated with the processor.
  • the memory 803 is used to store the application code for executing the solution of the present application, and the execution is controlled by the processor 801 .
  • the processor 801 is configured to execute the application program code stored in the memory 803, and cooperate with at least one transceiver 804, so that the apparatus 800 realizes the functions in the method of the present patent.
  • the processor 801 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 8 .
  • the apparatus 800 may include multiple processors, for example, the processor 801 and the processor 807 in FIG. 8 .
  • processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor.
  • a processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (eg, computer program instructions).
  • an embodiment of the present application provides a schematic diagram of a terminal entity 900 .
  • the terminal entity 900 may be the terminal entity in any of the foregoing embodiments.
  • the end entity 900 includes at least one processor 901 , internal connections 902 , memory 903 and at least one transceiver 904 .
  • the terminal entity 900 is a device with a hardware structure, which can be used to implement the functional modules in the terminal entity 700 described in FIG. 7 .
  • the verification module 703 or the replacement module 704 in the terminal entity 700 shown in FIG. 7 can be implemented by calling the code in the memory 903 by the at least one processor 901.
  • the terminal entity 700 shown in FIG. 7 The sending module 701 and the receiving module 702 in the above can be implemented by the transceiver 904 .
  • the terminal entity 900 may also be used to implement the function of the proxy device in any of the foregoing embodiments.
  • processor 901 may be a general-purpose central processing unit (central processing unit, CPU), a network processor (network processor, NP), a microprocessor, an application-specific integrated circuit (application-specific integrated circuit, ASIC) , or one or more integrated circuits used to control the execution of the program of this application.
  • CPU central processing unit
  • NP network processor
  • ASIC application-specific integrated circuit
  • the internal connection 902 described above may include a path to transfer information between the above described components.
  • the internal connection 902 is a single board or a bus or the like.
  • the above transceiver 904 is used to communicate with other devices or communication networks.
  • the above-mentioned memory 903 can be a read-only memory (read-only memory, ROM) or other types of static storage devices that can store static information and instructions, a random access memory (random access memory, RAM) or other types of storage devices that can store information and instructions.
  • ROM read-only memory
  • RAM random access memory
  • Types of dynamic storage devices which can also be electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM), or other optical storage, CD-ROM storage (including compact discs, laser discs, compact discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or capable of carrying or storing desired program code in the form of instructions or data structures and capable of being accessed by Any other medium accessed by the computer, but not limited to this.
  • the memory can exist independently and be connected to the processor through a bus.
  • the memory can also be integrated with the processor.
  • the memory 903 is used for storing the application program code for executing the solution of the present application, and the execution is controlled by the processor 901 .
  • the processor 901 is configured to execute the application program code stored in the memory 903, and cooperate with at least one transceiver 904, so that the end entity 900 realizes the functions in the method of the present patent.
  • the processor 901 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 9 .
  • the terminal entity 900 may include multiple processors, for example, the processor 901 and the processor 907 in FIG. 9 .
  • Each of these processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor.
  • a processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (eg, computer program instructions).
  • Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
  • a storage medium can be any available medium that a computer can access.
  • computer readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage media or other magnetic storage devices, or be capable of carrying or storing instructions or data structures in the form of desired program code and any other medium that can be accessed by a computer. also.
  • any connection can be appropriately made into a computer-readable medium.
  • the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave
  • coaxial cable , fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, wireless, and microwave
  • Disk and disc includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc, where disks usually reproduce data magnetically, and discs Lasers are used to optically copy data. Combinations of the above should also be included within the scope of computer-readable media.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请公开提供一种数字证书签发的方法、装置、终端实体和***，其中方法包括：代理设备接收终端实体发送的包含第一终端实体公钥的终端实体证书授权请求，由于代理设备自身有中间证书，可以为终端实体签发数字证书，因此代理设备根据终端实体证书授权请求对第一终端实体公钥生成第一终端实体证书，使用第一代理设备私钥对第一终端实体证书进行数字签名，获得第一终端实体证书的数字签名值，生成并向终端实体发送终端实体证书授权响应，这样就实现代理设备对第一终端实体证书的签发。由于代理设备可以有多个，避免海量的终端实体向唯一的CA服务器去请求对终端实体进行数字证书的认证，因此减轻了CA服务器的负荷，也能节约网络带宽资源。

Description

数字证书签发的方法、装置、终端实体和***
本申请要求于2020年12月4日提交中国国家知识产权局、申请号为202011402744.8、申请名称为“数字证书签发的方法、装置、终端实体和***”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明实施例涉及信息技术和通信技术领域，尤其涉及数字证书签发的方法、装置、终端实体和***。
背景技术
通信设备之间进行通信通常需要是相互信任的，将通信设备之间的通信信任可以被认为跨信任域通信，通信设备也可以被称为网络实体(network entity，NE)。通常来说，通信设备内多个单板间通信则被认为属于同一信任域内的通信，单板间通信没有提供任何安全功能。随着网络攻击技术的不断发展，对通信设备的***安全和韧性能力的要求也越来越高，通信设备的单板间通信安全也变得愈发重要。
为保证通信设备单板间通信安全，通常会采用安全传输层协议(transport layer security，TLS)、数据包传输层安全性协议(datagram transport layer security，DTLS)、互联网安全协议(internet protocol security，IPSEC)、媒体访问控制层安全协议(media access control security，MACSEC)等协议。这些协议通常使用数字证书作为通信双方身份认证凭据。这就要求设备上每块业务单板都能提供单独的数字证书标识身份。
由于诸如业务单板的海量终端实体需要请求证书授权(certificate authority，CA)服务器为终端实体签发数字证书，因此CA服务器将为海量终端实体签发数字证书，可能会导致CA服务器的负荷过大，并且消耗了大量网络带宽资源。
发明内容
有鉴于此，本发明实施例提供了一种数字证书签发的方法、装置、终端实体和***，通过CA服务器授权代理设备发送中间证书，由代理设备向各个终端实体签发各个终端的终端实体证书，这样各个终端实体不需要到授权认证CA服务器请求数字证书的签发，因此，减少了CA服务器的负担。
第一方面，提供一种数字证书签发的方法，方法包括：终端实体会预先生成自身的第一终端实体公钥和第一终端实体私钥的一对密钥对，代理设备预先生成自身的第一代理设备公钥和第一代理设备私钥的一对密钥对。代理设备接收终端实体发送的终端实体证书授权请求，该终端实体证书授权请求包含第一终端实体公钥，由于代理设备自身有中间证书，可以为终端实体签发数字证书，因此代理设备根据终端实体证书授权请求对第一终端实体公钥生成第一终端实体证书，使用第一代理设备私钥对第一终端实体证书进行数字签名，获得第一终端实体证书的数字签名值，生成终端实体证书授权响应，并向终端实体返回终端实体证书授权响应，这样就实现了代理设备对第一终端实体证书的签发。其中，终端实体证书授权响应包 含第一终端实体证书和第一终端实体证书的证书链，第一终端实体证书包含第一终端实体公钥和第一终端实体证书的数字签名值，第一终端实体证书的证书链用于验证第一终端实体证书的数字签名值是否正确，第一终端实体证书的证书链包含CA根证书和第一中间证书，第一中间证书由CA服务器给代理设备签发的，该第一中间证书包含第一代理设备公钥，这样拥有第一中间证书的代理设备就可以为终端实体签发数字证书。
上述方案，拥有中间证书的代理设备可以实现对各个终端实体颁发数字证书。通常来说，CA服务器在一个数字证书管理***中只有一个，而代理设备可以有多个，这样避免了海量的终端实体都向唯一的CA服务器去请求对终端实体进行数字证书的认证，这样减轻了CA服务器的负荷，也能节约网络带宽资源。另外，由于代理设备可以有多个，代理设备可以设置在终端实体的附近，因此代理设备可以向终端实体提供非常安全、快速和方便地数字证书的认证。
在一种可能的实现方式中，方法还包括：代理设备向CA服务器发送包含第一代理设备公钥的中间证书授权请求，代理设备接收CA服务器发送的中间证书授权响应，该中间证书授权响应包含了第一中间证书和第一中间证书的证书链，其中，第一中间证书包含所述第一代理设备公钥和第一中间证书的数字签名值，第一中间证书的证书链包含CA根证书，CA根证书包含CA根公钥，第一中间证书的数字签名值由CA服务器使用CA根私钥对第一中间证书进行数字签名获得的，CA根公钥和所述CA根私钥为所述CA服务器生成的一对密钥对；代理设备使用所述第一中间证书的证书链验证所述第一中间证书的数字签名值是正确的。因此，CA服务器可以为代理设备颁发中间证书，这样拥有中间证书的代理设备可以实现对各个终端实体颁发终端实体的数字证书。
在一种可能的实现方式中，方法还包括：当终端实体需要更新自身的终端实体证书时，终端实体将生成新的密钥对：第二终端实体公钥和第二终端实体私钥。代理设备接收终端实体发送的包含第二终端实体公钥的第一证书更新请求，代理设备根据所述第一证书更新请求对所述第二终端实体公钥生成第二终端实体证书，并使用第一代理设备私钥对第二终端实体证书进行数字签名，获得第二终端实体证书的数字签名值，生成并向终端实体发送第一证书更新响应，其中，第一证书更新响应包含第二终端实体证书和第二终端实体证书的证书链，第二终端实体证书包含第二终端实体公钥和所述第二终端实体证书的数字签名值，第二终端实体证书的证书链用于验证所述第二终端实体证书的数字签名值是否正确，第二终端实体证书的证书链包含CA根证书和第一中间证书。当需要更新终端实体证书时，无需到CA服务器去请求更新该终端实体证书，而只需要向位于终端实体附近的代理设备请求更新该终端实体证书。这样避免了海量的终端实体都到唯一的CA服务器去请求更新数字证书的认证，这样减轻了CA服务器的负荷，也能节约网络带宽资源。
在一种可能的实现方式中，方法还包括：当代理设备需要更新中间证书时，代理设备将生成新的密钥对：第二代理设备公钥和第二代理设备私钥。代理设备向CA服务器发送包含第二代理设备公钥的第二证书更新请求，代理设备接收CA服务器发送的第二证书更新响应，其中，该第二证书更新响应包含第二中间证书和第二中间证书的证书链，第二中间证书包含第二代理设备公钥和第二中间证书的数字签名值，第二中间证书的数字签名值由所述CA服务器使用CA根私钥对所述第二中间证书进行数字签名获得的；当代理设备使用所述第二中间证书的证书链验证所述第二中间证书的数字签名值是正确时，代理设备将所述第一中间证书替换为所述第二中间证书。当需要更新中间证书时，代理设备及时向CA服务器请求更新该中间证书，这样实现了中间证书的及时更新。
在一种可能的实现方式中，方法还包括：在中间证书更新后，终端实体需要更新重新向代理设备重新签发终端实体证书，此时代理设备接收终端实体发送的包含第一终端实体公钥第三证书更新请求，代理设备根据第三证书更新请求，对第一终端实体公钥生成第三终端实体证书，并使用第二代理设备私钥对第三终端实体证书进行数字签名，获得第三终端实体证书的数字签名值，生成并向终端实体发送第三证书更新响应，其中，第三证书更新响应包含第三终端实体证书和第三终端实体证书的证书链，第三终端实体证书包含第一终端实体公钥和第三终端实体证书的数字签名值，第三终端实体证书的证书链用于验证第三终端实体证书的数字签名值是否正确，第三终端实体证书的证书链包含CA根证书和第二中间证书。在中间证书更新后，代理设备重新为终端实体签发新的终端实体证书，此时使得终端实体证书的合法性得到延续。
在一种可能的实现方式中，方法还包括：使用所述第二中间证书的证书链验证所述第二中间证书的数字签名值是正确的，具体为：代理设备利用CA根公钥验证CA根证书的数字签名值是否正确，当验证CA根证书的数字签名值为不正确时，确定第二中间证书是不正确的；当验证CA根证书的数字签名值为正确时，利用CA根公钥验证第二中间证书的数字签名值是否正确，当验证第二中间证书的数字签名值为不正确时，则确定第二中间证书是不正确的；当验证第二中间证书的数字签名值为正确时，则确定第二中间证书是正确的。
第二方面，本发明提供一种数字证书签发的方法，包括：终端实体会预先生成自身的第一终端实体公钥和第一终端实体私钥的一对密钥对，代理设备预先生成自身的第一代理设备公钥和第一代理设备私钥的一对密钥对。终端实体向代理设备发送包含第一终端实体公钥终端的实体证书授权请求，终端实体接收代理设备发送的终端实体证书授权响应，其中，终端实体证书授权响应包含第一终端实体证书和第一终端实体证书的证书链，第一终端实体证书包含第一终端实体公钥和第一终端实体证书的数字签名值，第一终端实体证书的证书链用于验证所述第一终端实体证书的数字签名值是否正确；利用第一终端实体证书的证书链验证第一终端实体证书的数字签名值是否正确。
上述方案，拥有中间证书的代理设备可以实现对各个终端实体颁发数字证书。通常来说，CA服务器在一个数字证书管理***中只有一个，而代理设备可以有多个，这样避免了海量的终端实体都向唯一的CA服务器去请求对终端实体进行数字证书的认证，这样减轻了CA服务器的负荷，也能节约网络带宽资源。另外，由于代理设备可以有多个，代理设备可以设置在终端实体的附近，因此代理设备可以向终端实体提供非常安全、快速和方便地数字证书的认证。
在一种可能的实现方式中，方法还包括：在终端实体重新生成密钥对：第二终端实体公钥和第二终端实体私钥，终端实体向代理设备发送包含第二终端实体公钥的第一证书更新请求，终端实体接收所述设备发送的第一证书更新响应，其中，第一证书更新响应包含第二终端实体证书和第二终端实体证书的证书链，第二终端实体证书包含所述第二终端实体公钥和第二终端实体证书的数字签名值，第二终端实体证书的证书链用于验证第二终端实体证书的数字签名值是否正确；利用第二终端实体证书的证书链验证第二终端实体证书的数字签名值为正确时，将第一终端实体证书替换为第二终端实体证书。当需要更新终端实体证书时，无需到CA服务器去请求更新该终端实体证书，而只需要向位于终端实体附近的代理设备请求更新该终端实体证书。这样避免了海量的终端实体都到唯一的CA服务器去请求更新数字证书的认证，这样减轻了CA服务器的负荷，也能节约网络带宽资源。
在一种可能的实现方式中，方法还包括：当代理设备需要更新中间证书时，代理设备将 生成新的密钥对：第二代理设备公钥和第二代理设备私钥。终端实体向代理设备发送包含所述第一终端实体公钥的第三证书更新请求，终端实体接收代理设备发送第三证书更新响应，其中，第三证书更新响应包含第三终端实体证书和第三终端实体证书的证书链，第三终端实体证书包含第一终端实体公钥和第三终端实体证书的数字签名值，第三终端实体证书的证书链用于验证第三终端实体证书的数字签名值是否正确；利用第三终端实体证书的证书链验证第三终端实体证书的数字签名值为正确时，将第一终端实体证书替换为第三终端实体证书。在中间证书更新后，代理设备重新为终端实体签发新的终端实体证书，此时使得终端实体证书的合法性得到延续。
在一种可能的实现方式中，方法还包括：所述第一终端实体证书的证书链包含授权认证CA根证书和第一中间证书，利用第一终端实体证书的证书链验证第一终端实体证书的数字签名值是否正确，具体为：利用CA根公钥验证CA根证书的数字签名值是否正确，当验证CA根证书的数字签名值为不正确时，确定第一终端实体证书是不正确的；当验证CA根证书的数字签名值为正确时，利用CA根公钥验证第一中间证书的数字签名值是否正确，当验证第一中间证书的数字签名值为不正确时，则确定第一终端实体证书是不正确的；当验证第一中间证书的数字签名值为正确时，利用第一中间证书包含的第一代理设备公钥验证第一终端实体证书的数字签名值是否正确，当验证第一终端实体证书的数字签名值为不正确时，则确定第一终端实体证书是不正确的；当验证第一终端实体证书的数字签名值为正确时，则确定第一终端实体证书是正确的。
第三方面，本申请提供了一种数字证书签发的装置，该装置包括一个或多个单元，用于实现第一方面所述的数字证书签发的方法。
第四方面，本申请提供了一种终端实体，该终端实体包括一个或多个模块，用于实现第二方面所述的数字证书签发的方法。
第五方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序或指令，当计算机程序或指令被代理设备执行时，使得该代理设备执行上述第一方面或第一方面的任意可能的实现方式中的方法。
第六方面，本申请提供一种计算机可读存储介质，该计算机程序产品包括计算机程序或指令，当该计算机程序或指令被终端实体执行时，使得该终端实体执行上述第二方面或第二方面的任意可能的实现方式中的方法。
附图说明
图1为本发明一实施例提供的证书链的链式关系示意图；
图2为本发明一实施例提供的数字证书管理***的结构示意图；
图3为本发明一实施例提供的一种数字证书签发的流程图；
图4为本发明一实施例提供的一种数字证书更新的流程图；
图5为本发明一实施例提供的一种数字证书更新的流程图；
图6为本发明一实施例提供的一种数字证书签发的装置的结构示意图；
图7为本发明一实施例提供的一种终端实体的结构示意图；
图8为本发明一实施例提供的一种数字证书签发的装置的结构示意图；
图9为本发明一实施例提供的一种终端实体的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，可以理解的是，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
以下，对本申请中的部分用语进行解释说明。需要说明的是，这些解释是为了便于本领域技术人员理解，并不是对本申请所要求的保护范围构成限定。
对称加密算法：加密方和解密方使用同一个规则对信息进行加密和解密。
非对称加密算法：又被称为公钥密码学或者双钥密码学。非对称加密算法需要两个密钥：公开密钥(publ ickey，简称公钥)和私有密钥(privatekey，简称私钥)。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密，如果用私钥对数据进行加密，只有用对应的公钥才能解密。因为加密和解密使用的是两个不同的密钥。目前典型的非对称加密算法为RSA算法，由三位数学家Rivest、Shamir和Adleman所设计。RSA密码体制是一种公钥密码体制，公钥公开，私钥保密，它的加密解密算法是公开的。由公钥加密的内容可以并且只能由私钥进行解密，或者由私钥加密的内容可以并且只能由公钥进行解密。也就是说，RSA的这一对公钥、私钥都可以用来加密和解密，并且一方加密的内容可以由并且只能由对方进行解密。
数字签名，又称为公钥数字签名，数字签名为附加在数据单元后面再加上一段内容，或是对数据单元所作的密码变换，可以证明数据单元没有被修改过。这种数据或变换允许数据单元的接收者用以确认数据单元的来源和数据单元的完整性并保护数据，防止被人(例如接收者)进行伪造。它是对电子形式的消息进行签名的一种方法，一个签名消息能在一个通信网络中传输。基于公钥密码体制和私钥密码体制都可以获得数字签名。
公钥基础设施(pubic key infrastructure，PKI)，又称公开密钥基础架构、公钥基础建设、公钥基础设施、公开密码匙基础建设或公钥基础架构。PKI是一个利用非对称密码算法和技术实现的并提供网络安全服务的具有通用性的安全基础设施，目的在于创造、管理、分配、使用、存储以及撤销证书。PKI借着CA机构将用户的个人身份跟公开密钥链接在一起。对每个证书中心用户的身份必须是唯一的。链接关系通过注册和发布过程创建，取决于担保级别，链接关系可能由CA机构的各种软件或在人为监督下完成。PKI的确定链接关系的这一角色称为证书注册(Registration Authority，RA)机构。RA机构确保公开密钥和个人身份链接，可以防抵赖。PKI通常由以下几部分组成：CA机构、RA机构、证书库、密钥备份及恢复***、证书废除处理***、应用***接口和证书。
CA机构：CA机构是PKI的核心执行机构，也被称为认证中心或者CA服务器。CA机构是负责签发证书、认证证书和管理已颁发证书的机构，具体来说，CA机构可以制定政策和具体步骤来验证、识别用户身份，并对用户证书进行签名，以确保证书持有者的身份和公钥的拥有权，CA机构是一种权威性、可信任性和公正性的第三方机构。CA机构还具有层次性结构，在大型的PKI设施中，由于用户数量的繁多，使用一个CA机构进行证书验证和签发服务，可能负荷会很大，所以就需要进行CA机构的层次性部署，在CA机构的层次性部署里，各CA机构之间需要建立自上而下的信任证书链，下级CA机构信任上级CA机构，下级CA机构由上级CA机构颁发证书并认证。可以在证书链中看出层次关系。
RA机构：是CA机构的组成部分，是证书的申请注册、审批、校对和管理机构。RA机构也称为层次结构，RA为注册总中心，负责证书申请注册汇总。RA机构是CA机构面对用户的窗口，它负责接收用户的证书申请、审核用户的身份。实际应用中,通常PKI中的RA机构并不独立存在,而是和CA机构合并在一起。
数字证书：简称证书，证书是一个由颁发机构签发的包含公钥拥有者信息以及公钥的文件，由颁发机构进行数字签名，它是数字签名的技术基础保障。证书一般包含证书版本、证书序列号、证书签名算法、颁发者信息、证书有效期、公钥和使用者信息，证书序列号由颁发机构颁发，并且确保在该证书使用范围内都是唯一的；证书有效期包含证书生效时间和证书失效时间；颁发者信息是由颁发机构确定的，使用者信息是由证书申请者确定的。证书还可以包含密钥用法、证书类型、扩展密钥用法和证书吊销列表分发点，其中，密钥用法表示了该证书的公钥能够支持的功能和服务，比如：证书签名(certificate signature)、密钥加密(key encipherment)、数据加密(data encipherment)、密钥协定(key agreement)、证书撤销列表(Certification Revocation List，CRL)签名。其中，证书签名和证书撤销列表签名只能是CA证书才能具有的密钥用法，因此虽然密钥用法扩展域是可选项，但是对于根CA来说，这一扩展域是不可或缺的关键扩展项，而且必须具备certificate signature、Certification Revocation List(CRL)signature这两种密钥用法。证书类型为根证书(root certificate)、中间证书(intermediate certificate)和终端实体证书(end-entity certificate)，其中，根证书是由CA机构给自己签发的证书，根证书的数字签名是用根私钥签发的，所以验证根证书签名要用根公钥才能验证通过，通常将根证书的数字签名叫做自签名。中间证书是由CA机构签发的，中间证书里面包含了根证书的名称，中间证书的签名是用根私钥进行数字签名，所以需要用根公钥验证中间证书的合法性。终端实体证书包含是由中间证书拥有者签发的，终端实体证书包含了中间证书的名称，终端实体证书的数字签名是用中间私钥签发的，所以需要用中间公钥验证终端实体证书的合法性。根证书或中间证书具有为其下一级证书签发证书的能力，通常来说，中间证书只有一个级别，此时可以将中间证书称为二级证书，不过中间证书也可以有多个级别。终端实体证书是不具有签发证书的授权能力，只具有证明终端实体身份的作用，需要说明的是：这里的终端实体包括了手机、电脑、单板、服务器和网络设备等各种使用终端实体证书证明自己身份的设备。
证书链(certificate chain)是一个有序的证书列表，是证书之间的信任关系，证书链通常包含三级结构，根证书，中间证书和终端实体证书，如图1所示，证书链顺序中终端实体证书处在最底端，终端实体证书里面包含了终端实体信息，终端实体公钥和数字签名值等。终端实体证书上一级是中间证书，即：终端实体证书是由拥有中间证书的机构签发的。中间证书由CA机构授权签发的。图1只显示了一个中间证书，不过证书链可以有多个中间证书，此时最上层的中间证书是由根证书签发，最下层的中间证书是用于签发终端实体证书，根证书是由CA机构自签发的。当终端实体身份进行校验时，需要验证整个证书链的每个证书颁发者的合法性。根据证书链一层层的去寻找颁发者的证书，直到找到自签名的根证书，然后通过相应的公钥验证下一级的数字签名值的正确性，当每一级证书的数字签名值都被验证是正确的，则说明终端实体证书是正确的。
证书管理协议(Certificate Management Protocol)是一个网际协议，用于在PKI体系中证书的申请和更新操作时客户端(证书的拥有者和使用者)与CA机构(证书的颁发者)之间的行为。CMP发展到第二版本，简称CMPv2。
如图2所示，本发明实施例提供的一种网络***架构，包括：CA服务器和多个NE，其中 NE可以进一步包括业务单板(service board)和控制单板(main control board)，在业务单板和控制单板上可以安装证书管理代理(certificate management agent)。当前，通过加密算法的方式来增加不同网元之间的通信的安全性。
通常来说，NE中各个业务单板可以独立向CA服务器请求证书签发或者证书更新服务。该证书服务的具体流程可以包括如下：包括业务单板和控制单板的所有单板在出厂时都会预先设置表明单板身份的初始终端实体证书和初始证书链，该初始证书链包含了签发初始终端证书的初始中间证书及初始根证书，初始终端实体证书通常是由网络设备厂家签发的，并不是由CA服务器签发的。当控制单板和业务单板分别上线后，业务单板和控制单板采用预先设置的初始终端实体证书作为身份凭据建立安全通信通道，建立安全通道采用的安全协议有多种，比如：TLS/DTLS/MACSEC。接着，控制单板和业务单板可以分别向CA服务器请求签发新的证书(即CA服务器认证的终端实体证书)，CA服务器将认证的证书分别返回给控制单板和业务单板。控制单板和业务单板使用认证的终端实体证书替换预先预置的初始终端实体证书，这样，经过认证的终端实体证书就可以作为控制单板和业务单板之间通信的认证凭据。但是上述各个单板向CA服务器请求证书签发的过程可能存在如下的技术问题：由于现存网络中的通信设备众多，通信设备的业务单板数量更是通信设备数的数十倍。如果每个业务单板或控制单板都独立向CA服务器申请认证的终端实体证书，会导致CA服务器不堪重负，以及增加管理网络流量，占用较多网络带宽。
基于上述的技术问题，本发明实施例公开了一种新的证书获取的方法，为了描述方便，针对证书获取的不同阶段，下面分为了4个不同实施例来进行描述。
实施例一
在网络设备出厂时，设备厂家可以为各个终端实体(end-entity)(比如：业务单板)和代理设备(比如：控制单板)预先配置的设备自身的初始终端实体证书和初始证书链，该初始证书链包含了签发初始终端证书的初始中间证书及初始根证书。当终端实体正常运行时，管理员可以为网络设备中的代理设备加载CA服务器自身的CA根证书，CA根证书包含CA根公钥，该CA根证书是由CA服务器使用第一密钥对包含的CA根私钥自签发的数字证书，第一密钥对是由CA服务器生成的，第一密钥对包含CA根公钥和CA根私钥。该CA根公钥可以用于验证CA服务器发送给代理设备的消息的数字签名值是否正确，该数字签名值是用CA根私钥签名的，需要说明的是：也可以为代理设备加载CA证书链，为了说明方便，下面的内容以只加载CA根证书为例进行说明。如果加载CA证书链的话，需要利用证书链包含的各级数字证书包含各类公钥对应性地验证各级数字证书的数字签名值是否正确，关于利用证书链逐级认证各级数字证书是否正确的过程在下面过程步骤308中会做详细介绍。类似的，CA服务器会导入预先设置的代理设备的初始终端实体证书和初始证书链，预先设置的代理设备的初始终端实体证书包含初始代理设备公钥，该预先设置的代理设备的终端实体证书是由网络设备或者网络设备信任的授权机构使用第二密钥对包含的初始代理设备私钥签发的数字证书，第二密钥对包含初始代理设备公钥和初始代理设备私钥。该预先设置的代理设备的初始终端实体证书的初始代理设备公钥用于验证代理设备发送给CA服务器的消息的数字签名值是否正确，该数字签名是用初始代理设备私钥签名的。
如图3所示，代理设备的实现数字证书签发的方法，包括：
步骤301：代理设备生成代理设备自身的第三密钥对，第三密钥对包括第一代理设备公钥和第一代理设备私钥。现有技术中，关于密钥对的生成方法有多种，这里不再赘述。
代理设备构造中间证书授权请求，该中间证书授权请求包含申请者信息(即代理设备的 信息，如代理设备名称等)和第一代理设备公钥，并用初始代理设备私钥对中间证书授权请求进行数字签名，然后将数字签名后的中间证书授权请求发送给CA服务器。该中间证书授权请求可以用CMP消息、CMPv2消息或者其他消息类型的消息进行承载，比如：CMPv2消息具体为初始化请求(initialization request，IR)。
步骤302：CA服务器接收到中间证书授权请求，CA服务器使用预先加载的代理设备的初始终端实体证书包含的初始代理设备公钥验证该中间证书授权请求的数字签名值是否正确，如果验证正确后，根据中间证书授权请求包含的申请者信息和第一代理设备公钥为该代理设备生成第一中间证书，并使用CA根私钥对第一中间证书进行数字签名，第一中间证书包含了第一代理设备公钥。CA服务器生成包含第一中间证书的中间证书授权响应，并使用CA根私钥对中间证书授权响应进行数字签名，并向代理设备发送数字签名后的中间证书授权响应，该中间证书授权响应还包含了第一中间证书的证书链。该中间证书授权响应可以采用IP消息或者CMPv2等格式的消息进行承载，第一中间证书的证书链包含了CA根证书。
这里需要说明的是：如果存在多个中间证书，比如：存在3个中间证书，分别即为：中间证书a，中间证书b，中间证书c，这三个证书的关系是：中间证书a上一级证书是CA根证书，也就是说用CA根证书为中间证书a进行数字签名，中间证书b上一级证书是中间证书a，也就是说用中间证书a包含的公钥为中间证书b进行数字签名，中间证书c上一级证书是中间证书b，也就是说用中间证书b包含的公钥为中间证书c进行数字签名，此时的中间证书c即为上述的第一中间证书，此时第一中间证书的证书链包含CA根证书、中间证书a和中间证书b，本发明实施例为了描述方便，本发明实施例以只存在一个中间证书为例来进行方案说明，存在多个中间证书的方案流程与存在一个中间证书流程是类似的，因此不再赘述。
步骤303：代理设备接收中间证书授权响应，并使用预先加载的CA根证书的CA根公钥分别验证中间证书授权响应的数字签名值，并利用第一中间证书的证书链来验证第一中间证书的数字签名值是否正确，当验证第一中间证书的数字签名值是正确时，代理设备向CA服务器发送证书确认消息以确认收到第一中间证书，该证书确认消息可以为CertConf消息。
利用第一中间证书的证书链来验证第一中间证书的数字签名值是否正确过程如下：代理设备从第一中间证书的证书链获取到所有的证书，在本发明实施例仅为CA根证书，然后用预先加载的CA根公钥验证CA根证书的数字签名值是否正确，如果验证CA根证书的数字签名值不正确，则确定第一中间证书是不正确的，如果正确，则利用CA根公钥验证第一中间证书的数字签名值是否正确，如果验证第一中间证书的数字签名值是不正确的，则确定第一中间证书是不正确的，如果验证第一中间证书的数字签名值是正确的，则确定第一中间证书正确的。
需要说明的是：如果第一中间证书的证书链包含CA根证书、中间证书a和中间证书b，则利用第一中间证书的证书链来验证第一中间证书的数字签名值是否正确过程如下：代理设备从第一中间证书的证书链获取到所有的证书，然后用预先加载的CA根公钥验证CA根证书的数字签名值是否正确的，如果验证CA根证书的数字签名值是不正确的，则确定第一中间证书是不正确的，如果验证CA根证书的数字签名值是正确的，则利用CA根公钥验证中间证书a的数字签名值是否正确，如果验证中间证书a的数字签名值是不正确，则确定第一中间证书是不正确的，如果验证中间证书a的数字签名值是正确，则利用中间证书a包含的公钥验证中间证书b的数字签名值是否正确，如果验证中间证书b的数字签名值是不正确的，则说明第一中间证书是不正确的，如果验证中间证书b的数字签名值是正确的，则利用中间证书b包含的公钥验证第一中间证书的数字签名值是否正确，如果验证第一中间证书的数字签名值是不正确的，则确定第一中间证书是不正确的，如果验证第一中间证书的数字签名值是正 确的，则确定第一中间证书正确的。
步骤304：CA服务器收到证书确认消息后，向代理设备发送PKI确认(PKIConf)消息，确认收到证书确认消息。
步骤305：在代理设备收到CA服务器发送的第一中间证书后，该代理设备向各终端实体发送证书申请通知。
设备出厂，各个终端实体和代理设备均预先设置厂商签发的初始终端实体证书和初始终端根证书和代理设备，终端实体上线后自动和代理设备建立安全通信通道(TLS/DTLS/MASEC等)，使用预先设置的终端实体证书作为身份认证凭据。
需要说明的是：代理设备除了具有可以为终端实体签发数字证书的中间证书外，还具有包含证明其代理设备身份的终端实体证书。
步骤306：终端实体生成终端实体自身的第四密钥对，这里的第四密钥对包括了第一终端实体公钥和第一终端实体私钥。终端实体收到了证书申请通知后，终端实体构造终端实体证书授权请求，该终端实体证书授权请求包含了申请者信息(即终端实体信息，比如：终端实体的名称)和第一终端实体公钥，并用初始终端实体证书的初始终端实体私钥对终端实体证书授权请求进行数字签名，然后将数字签名后的终端实体证书授权请求通过单板间的安全通道发送给代理设备。该终端实体证书授权请求可以用CMP消息、CMPv2消息或者其他消息类型的消息进行承载。
步骤307：代理设备从安全通道接收到终端实体证书授权请求，从预先加载的第一终端实体的初始终端证书中获得的初始终端实体公钥，使用该初始终端实体公钥验证终端实体证书授权请求的数字签名值是否正确。如果验证未通过，则认为该终端实体证书授权请求为不可信任的消息，代理设备对终端实体证书授权请求不做处理，或者向终端实体回复警告消息。如果验证通过后，代理设备根据第一中间证书、终端实体证书授权请求包含的申请者信息和第一终端实体公钥为终端实体生成第一终端实体证书，并利用第一代理设备私钥为第一终端实体证书进行数字签名，第一终端实体证书包含了第一终端实体公钥。代理设备生成包含数字签名后的第一终端实体证书和第一终端实体证书的证书链的终端实体证书授权响应，代理设备可以用代理设备的初始终端实体证书的初始代理设备私钥为终端实体证书授权响应进行数字签名，并通过单板间的安全通道向终端实体发送终端实体证书授权响应，此时第一终端实体证书的证书链包含CA根证书和第一中间证书。
步骤308：终端实体从安全通道接收到代理设备的终端实体证书授权响应，利用代理设备的初始终端证书的初始终端实体公钥验证终端实体证书授权响应的数字签名值是否正确，如果验证的结果是不正确时，则认为该终端实体证书授权响应为不可信任的消息，代理设备对该终端实体证书授权响应不做处理，或者向终端实体回复警告消息。如果验证的结果是正确时，利用第一终端实体证书的证书链验证第一终端实体证书的数字签名值是否正确，以确保第一终端实体证书是正确的。
利用第一终端实体证书的证书链验证第一终端实体证书的数字签名值是否正确过程包括：终端实体首先从第一终端实体证书的证书链获得证书链包含的所有数字证书，即：第一中间证书和CA根证书，利用CA根公钥验证CA根证书包含的数字签名值是否正确，当验证的结果为不正确时，则说明第一终端实体证书是不正确的。当验证的结果为正确时，利用CA根证书包含CA根公钥验证第一中间证书包含的数字签名值是否正确，当验证的结果为不正确时，则说明第一终端实体证书是不正确的。当验证的结果为正确时，利用第一中间证书包含第一代理设备公钥验证第一终端实体证书包含的数字签名值是否正确，当验证的结果为不正 确时，则说明第一终端实体证书是不正确的。当验证的结果为正确时，则说明第一终端实体证书是正确的。需要说明的是：如果第一终端实体证书的证书链包含CA根证书、中间证书a和中间证书b，验证CA根证书、中间证书a和中间证书b过程同步骤303所介绍的内容，本发明实施例中，如果第二中间证书的证书链或者第三终端实体证书的证书链包含CA根证书、中间证书a和中间证书b，验证CA根证书、中间证书a和中间证书b过程同步骤303所介绍的内容。
上述步骤306、步骤307和步骤308中，终端实体和代理设备使用各自的初始终端实体私钥对消息分别进行数字签名，以及终端实体和代理设备使用相应的初始终端实体公钥对消息分别验证消息的数字签名值是否正确。在后续过程中，如果终端实体和代理设备获得由中间证书签发的各自的身份证书(终端实体证书)，比如：代理设备还可以生成代理设备自身的第五密钥对，这里的第五密钥对包括了代理设备的终端实体的公钥和代理设备的终端实体的私钥，代理设备可以用第一中间证书的第一代理设备私钥为代理设备签发终端实体证书，该代理设备的终端实体证书包含了代理设备的终端实体的公钥。此时：上述步骤306、步骤307和步骤308中，终端实体还可以利用第一终端实体私钥对消息进行数字签名，代理设备还可以使用第一终端实体公钥对消息的数字签名值是否正确；相应地，代理设备还可以使用代理设备的终端实体的私钥对消息进行数字签名，终端实体还可以使用代理设备的终端实体的公钥对消息的数字签名值是否正确。
可选地，终端实体获得第一终端实体证书后，可以向代理设备发送证书获得通知。
步骤309：代理设备检测到所有终端实体均已成功申请到第一终端实体证书，通过安全通道向各终端实体发送证书切换通知。
代理设备可以在本地存储终端实体列表，该终端实体列表记录了该终端实体是否已经收到了第一终端实体证书。
步骤310：各终端实体收到证书切换通知后，使用代理设备签发的第一终端实体证书替换预先设置的初始终端实体证书。
本发明实施例，在数字证书管理***中，CA服务器可以为代理设备颁发中间证书，因此拥有中间证书的代理设备可以实现对各个终端实体颁发数字证书。通常来说，CA服务器在一个数字证书管理***中只有一个，而代理设备可以有多个，这样避免了海量的终端实体都向唯一的CA服务器去请求对终端实体进行数字证书的认证，这样减轻了CA服务器的负荷，也能节约网络带宽资源。另外，由于代理设备可以有多个，代理设备可以设置在终端实体的附近，比如：位于同一个网络设备里的业务单板(作为终端实体)和控制单板(作为代理设备)，业务单板和控制单板之间的通信更加快速和安全，因此代理设备可以向终端实体提供非常安全、快速和方便地数字证书的认证。
当终端实体的第一终端实体证书快过期或其对应私钥出现损坏、泄露等情况时，终端实体需要及时请求代理设备更新第一终端实体证书。第一终端实体证书更新成功后。如图4所示，证书更新方法的流程如下：
步骤401：终端实体确定需要重新向代理设备申请终端实体证书时，重新生成终端实体自身的第六密钥对，第六密钥对包含第二终端实体公钥和第二终端实体私钥。终端实体构造第一证书更新请求，该第一证书更新请求包含了第二终端实体公钥和申请者信息(即终端实体的信息)，使用第二终端实体私钥对第一证书更新请求进行数字签名，并通过板间安全通道将第一证书更新请求发给代理设备。
终端实体可以周期性检测到第一终端实体证书的期限是否在更新范围内，当检测到终端 实体的第一终端实体证书的期限已经处于更新范围时，或者终端实体周期性检测第一终端实体证书对应私钥出现损坏或泄露时，终端实体确定需要重新向CA服务器申请终端实体证书。
步骤402：代理设备收到第一证书更新请求，先使用第一证书更新请求中的第二终端实体公钥验证第一证书更新请求的数字签名值是否正确，当验证结果为正确时，根据第一证书更新请求包含的申请者信息和第二终端实体公钥生成第二终端实体证书，并使用第一中间证书相关的第一代理设备私钥为第二终端实体证书进行数字签名。代理设备生成第一证书更新响应，该第一证书更新响应包含携带数字签名后的第二终端实体证书及第二终端实体证书的证书链，代理设备通过安全通道将第一证书更新响应发送给终端实体，此时的第二终端实体证书的证书链包含了CA根证书和第一中间证书。
步骤403：终端实体从安全通道接收到代理设备的第一证书更新响应，使用第一中间证书相关的第一代理设备公钥验证第一证书更新响应的数字签名值是否正确，当验证结果为不正确时，则确认第一证书更新响应是不信任的，如果验证结果为正确时，则确认第一证书更新响应是信任的，使用第二终端实体证书的证书链验证第二终端实体证书数字签名值是否正确，以确保第二终端实体证书是信任的，验证通过后使用第二终端实体证书替换第一终端实体证书。
使用第二终端实体证书的证书链验证第二终端实体证书数字签名值是否正确过程包括：终端实体首先从第二终端实体证书的证书链获得证书链包含的所有数字证书，即：第一中间证书和CA根证书，利用CA根公钥验证CA根证书包含的数字签名值是否正确，当验证的结果为不正确时，则说明第二终端实体证书是不正确的。当验证的结果为正确时，继续利用CA根证书包含CA根公钥验证第一中间证书包含的数字签名值是否正确，当验证的结果为不正确时，则说明第二终端实体证书是不正确的。当验证的结果为正确时，继续利用第一中间证书包含第一代理设备公钥验证第二终端实体证书包含的数字签名值是否正确，当验证的结果为不正确时，则说明第二终端实体证书是不正确的。当验证的结果为正确时，则说明第二终端实体证书是正确的。
本发明实施例，在数字证书管理***中，由于拥有中间证书的代理设备可以实现对各个终端实体颁发数字证书，因此，当需要更新终端实体证书时，无需到CA服务器去请求更新该终端实体证书，而只需要向位于终端实体附近的代理设备请求更新该终端实体证书。这样避免了海量的终端实体都到唯一的CA服务器去请求更新数字证书的认证，这样减轻了CA服务器的负荷，也能节约网络带宽资源。另外，代理设备可以向终端实体提供非常安全、快速和方便地数字证书的更新管理。
当网络设备的第一中间证书快过期或其对应私钥出现损坏、泄露等情况时，网络设备需要及时请求CA服务器更新第一中间证书。第一中间证书更新成功后，代理设备需要通知各终端实体更新第一终端实体证书，使用新的中间证书(即第二中间证书)重新给各终端实体签发新的终端实体证书(即第三终端实体证书)。如图5所示，基于图3所示的实施例，证书更新方法的流程包括如下：
步骤501：代理设备确定需要重新向CA服务器申请中间证书时，重新生成代理设备自身的第七密钥对，第七密钥对包含第二代理设备公钥和第二代理设备私钥。代理设备构造第二证书更新请求，该第二证书更新请求包含了申请者信息(具体为代理设备信息，比如：代理设备名称)和第二代理设备公钥，并用第二代理设备私钥对第二证书更新请求进行数字签名，然后将数字签名后的第二证书更新请求通过https通道发送给CA服务器。该第二证书更新请求可以用关键更新请求(Key Update Request，KUR)进行承载。
代理设备可以周期性检测到第一中间证书的期限是否在更新范围内，当检测到终端实体的第一中间证书的期限已经处于更新范围时，或者代理设备周期性检测第一中间证书对应私钥出现损坏或泄露时，代理设备确定需要重新向CA服务器申请中间证书。
步骤502：CA服务器收到第二证书更新请求，使用第二证书更新请求包含的第二代理设备公钥验证第二证书更新请求的数字签名值是否正确，当验证通过后，CA服务器根据第二证书更新请求的第二代理设备公钥和申请者信息为代理设备生成新的中间证书(后续记为第二中间证书)，并利用CA根私钥为第二中间证书进行数字签名。CA服务器生成包含第二中间证书和第二中间证书的证书链的第二证书更新响应，并用CA根私钥为第二证书更新响应进行数字签名，CA服务器通过https通道将数字签名后的第二证书更新响应发送给代理设备。该第二证书更新响应可以用密钥更新响应(Key Update Response，KUP)进行承载。此时第二中间证书的证书链包括CA根证书。
步骤503：代理设备收到第二证书更新响应，用CA根证书的CA根公钥验证第二证书更新响应的数字签名值是否正确，当验证结果为正确时，则说明接收的第二证书更新响应是正确的，代理设备向CA服务器发送证书确认消息确认收到第二中间证书。
步骤504：CA服务器向主控制单元发送PKI确认消息，确认收到证书确认消息。
步骤505：代理设备收到PKI确认消息后，向各终端实体发送中间证书更新通知。
步骤506：终端实体收到中间证书更新通知后，生成第三证书更新请求，该第三证书更新请求包含了第一终端实体公钥和申请者信息(终端实体的信息)，使用第一终端实体私钥对第三证书更新请求进行数字签名，并通过板间安全通道将第三证书更新请求发给代理设备。
步骤507：代理设备收到第三证书更新请求，先使用第三证书更新请求中的第一终端实体公钥验证第三证书更新请求的数字签名值是否正确，当验证结果为正确时，根据第三证书更新请求包含的申请者信息和第一终端实体公钥生成第三终端实体证书，并使用第二中间证书相关的第二代理设备私钥为第三终端实体证书进行数字签名。代理设备生成第三证书更新响应，该第三证书更新响应包含携带数字签名后的第三终端实体证书及第三终端实体证书的证书链，代理设备通过安全通道将第三证书更新响应发送给终端实体，此时的第三终端实体证书的证书链包含了CA根证书和第二中间证书。
步骤508：终端实体从安全通道接收到代理设备的第三证书更新响应，验证第三终端实体证书和第三终端实体证书的证书链的数字签名值是否正确，以确保其合法性，验证通过后使用第三终端实体证书替换第一终端实体证书。
终端实体首先从第三终端实体证书的证书链获得证书链包含的所有数字证书，即：第二中间证书和CA根证书，利用CA根证书包含CA根公钥验证CA根证书包含的数字签名值是否正确，当验证的结果为不正确时，则说明第三终端实体证书是不正确的。当验证的结果为正确时，利用CA根证书包含CA根公钥验证第二中间证书包含的数字签名值是否正确，当验证的结果为不正确时，则说明第三终端实体证书是不正确的。当验证的结果为正确时，利用第二中间证书包含第二代理设备公钥验证第三终端实体证书包含的数字签名值是否正确，当验证的结果为不正确时，则说明第三终端实体证书是不正确的。当验证的结果为正确时，则说明第三终端实体证书是正确的。
步骤509：代理设备检测到所有终端实体均已成功更新证书后，将所有使用初始代理设备私钥签发的第一终端实体证书进行吊销，生成包含CRL信息的证书吊销通知，并通过板间安全通道发送证书吊销通知，以便于通知各终端实体吊销第一终端实体证书。
步骤510：终端实体收到证书吊销通知，将消息中携带的CRL信息导入板间安全连接的 上下文，以吊销第一终端实体证书。
本发明实施例，在数字证书管理***中，由于拥有中间证书的代理设备可以实现对各个终端实体颁发数字证书，因此，当需要更新中间证书时，海量的终端实体无需向CA服务器请求更新该中间证书，而只需要由代理设备向CA服务器请求更新该中间证书，这样避免了海量的终端实体都向唯一的CA服务器更新中间证书，这样减轻了CA服务器的负荷，也能节约网络带宽资源。另外，当代理设备更新了中间证书，及时向终端实体发出中间证书更新通知，这样终端实体及时更新了终端实体证书。
参见图6，本申请实施例提供了一种数字证书签发的装置600，装置600可以部署在上述图3、图4或图5所示实施例提供的代理设备中，包括：接收单元601，用于接收终端实体发送的终端实体证书授权请求，所述终端实体证书授权请求包含第一终端实体公钥；
证书签发单元602，用于根据所述终端实体证书授权请求，对所述第一终端实体公钥生成第一终端实体证书，使用第一代理设备私钥对所述第一终端实体证书进行数字签名，获得所述第一终端实体证书的数字签名值，生成终端实体证书授权响应，其中，所述终端实体证书授权响应包含所述第一终端实体证书和所述第一终端实体证书的证书链，所述第一终端实体证书包含所述第一终端实体公钥和所述第一终端实体证书的数字签名值，所述第一终端实体证书的证书链用于验证所述第一终端实体证书的数字签名值是否正确，所述第一终端实体证书的证书链包含授权认证CA根证书和第一中间证书，其中，所述第一中间证书包含第一代理设备公钥，所述第一代理设备公钥和所述第一代理设备私钥为所述代理设备生成的一对密钥对。
发送单元603，用于向所述终端实体发送所述终端实体证书授权响应。
可选的，在一种应用场景下，装置600还包括验证单元604。其中，发送单元603，还用于向授权认证CA服务器发送中间证书授权请求，所述中间证书授权请求包含第一代理设备公钥。在该种场景下，接收单元601，还用于接收所述CA服务器发送的中间证书授权响应，所述中间证书授权响应包含了第一中间证书和第一中间证书的证书链，所述第一中间证书包含所述第一代理设备公钥和第一中间证书的数字签名值，其中，所述第一中间证书的证书链包含所述CA根证书，CA根证书包含CA根公钥，所述第一中间证书的数字签名值由所述CA服务器使用CA根私钥对所述第一中间证书进行数字签名获得的，所述CA根公钥和所述CA根私钥为CA服务器生成的一对密钥对。验证单元604，用于使用所述第一中间证书的证书链验证所述第一中间证书的数字签名值是正确的。
可选的，在另一种应用场景下，接收单元601，还用于接收所述终端实体发送的第一证书更新请求，所述第一证书更新请求包含第二终端实体公钥。在该种场景下，证书签发单元602，还用于根据所述第一证书更新请求，对所述第二终端实体公钥生成第二终端实体证书，并使用第一代理设备私钥对所述第二终端实体证书进行数字签名，获得所述第二终端实体证书的数字签名值，生成第一证书更新响应，其中，所述第一证书更新响应包含所述第二终端实体证书和所述第二终端实体证书的证书链，所述第二终端实体证书包含所述第二终端实体公钥和所述第二终端实体证书的数字签名值，所述第二终端实体证书的证书链用于验证所述第二终端实体证书的数字签名值是否正确，第二终端实体证书的证书链包含所述CA根证书和第一中间证书。在该种场景下，发送单元603，还用于向所述终端实体发送所述第一证书更新响应。
可选的，在另一种应用场景下，装置600还包括替换单元605，替换单元605，用于使用所述第二中间证书的证书链验证所述第二中间证书的数字签名值是正确的，将所述第一中间 证书替换为所述第二中间证书。在此种应用场景下，发送单元603，还用于向所述CA服务器发送第二证书更新请求，所述第二证书更新请求包含第二代理设备公钥。在此种应用场景下，接收单元601，还用于接收所述CA服务器发送的第二证书更新响应，所述第二证书更新响应包含第二中间证书和第二中间证书的证书链，所述第二中间证书包含所述第二代理设备公钥和第二中间证书的数字签名值，其中，所述第二中间证书的数字签名值由所述CA服务器使用CA根私钥对所述第二中间证书进行数字签名获得的。
可选的，在另一种应用场景下，接收单元601，还用于接收所述终端实体发送的第三证书更新请求，所述第三证书更新请求包含所述第一终端实体公钥。在此种应用场景下，证书签发单元602，还用于根据所述第三证书更新请求，对所述第一终端实体公钥生成第三终端实体证书，并使用第二代理设备私钥对所述第三终端实体证书进行数字签名，获得所述第三终端实体证书的数字签名值，生成第三证书更新响应，其中，所述第三证书更新响应包含所述第三终端实体证书和第三终端实体证书的证书链，所述第三终端实体证书包含所述第一终端实体公钥和所述第三终端实体证书的数字签名值，所述第三终端实体证书的证书链用于验证所述第三终端实体证书的数字签名值是否正确，第三终端实体证书的证书链包含所述CA根证书和所述第二中间证书，所述第二代理设备私钥和所述第二代理设备公钥为所述代理设备生成的一对密钥对。在此种应用场景下，发送单元603，还用于向所述终端实体发送所述第三证书更新响应。
可选的，替换单元605，具体用于利用CA根公钥验证所述CA根证书的数字签名值是否正确，当验证所述CA根证书的数字签名值为不正确时，确定所述第二中间证书是不正确的；当验证所述CA根证书的数字签名值为正确时，利用所述CA根公钥验证所述第二中间证书的数字签名值是否正确，当验证所述第二中间证书的数字签名值为不正确时，则确定所述第二中间证书是不正确的；当验证所述第二中间证书的数字签名值为正确时，则确定所述第二中间证书是正确的。
拥有中间证书的代理设备可以实现对各个终端实体颁发数字证书。通常来说，CA服务器在一个数字证书管理***中只有一个，而代理设备可以有多个，这样避免了海量的终端实体都向唯一的CA服务器去请求对终端实体进行数字证书的认证，这样减轻了CA服务器的负荷，也能节约网络带宽资源。另外，由于代理设备可以有多个，代理设备可以设置在终端实体的附近，因此代理设备可以向终端实体提供非常安全、快速和方便地数字证书的认证。
参见图7，本申请实施例提供了一种终端实体700，所述终端实体700可以部署在上述图3、图4或图5所示实施例提供的终端实体中，包括：
发送模块701，用于向代理设备发送终端实体证书授权请求，所述终端实体证书授权请求包含第一终端实体公钥。
接收模块702，用于接收所述代理设备发送的终端实体证书授权响应，其中，所述终端实体证书授权响应包含第一终端实体证书和所述第一终端实体证书的证书链，所述第一终端实体证书包含所述第一终端实体公钥和所述第一终端实体证书的数字签名值，所述第一终端实体证书的证书链用于验证所述第一终端实体证书的数字签名值是否正确。
验证模块703，用于利用所述第一终端实体证书的证书链验证所述第一终端实体证书的数字签名值是否正确。
可选的，在一种应用场景下，发送模块701，还用于向所述代理设备发送第一证书更新请求，所述第一证书更新请求包含第二终端实体公钥。在此种应用场景下，接收模块702，还用于接收所述代理设备发送的所述第一证书更新响应，所述第一证书更新响应包含第二终 端实体证书和所述第二终端实体证书的证书链，所述第二终端实体证书包含所述第二终端实体公钥和所述第二终端实体证书的数字签名值，所述第二终端实体证书的证书链用于验证所述第二终端实体证书的数字签名值是否正确。在此种应用场景下，终端实体还包括替换模块704，用于利用所述第二终端实体证书的证书链验证所述第二终端实体证书的数字签名值为正确时，将所述第一终端实体证书替换为所述第二终端实体证书。
可选的，在另一种应用场景下，发送模块701，还用于向所述代理设备发送第三证书更新请求，所述第三证书更新请求包含所述第一终端实体公钥。在此种应用场景下，所述接收模块702，还用于接收所述代理设备发送第三证书更新响应，其中，所述第三证书更新响应包含第三终端实体证书和第三终端实体证书的证书链，所述第三终端实体证书包含所述第一终端实体公钥和所述第三终端实体证书的数字签名值，所述第三终端实体证书的证书链用于验证所述第三终端实体证书的数字签名值是否正确。在此种应用场景下，替换模块704还用于利用所述第三终端实体证书的证书链验证所述第三终端实体证书的数字签名值为正确时，将所述第一终端实体证书替换为所述第三终端实体证书。
可选的，在另一种应用场景下，验证模块703具体用于利用CA根公钥验证所述CA根证书的数字签名值是否正确，当验证所述CA根证书的数字签名值为不正确时，确定所述第一终端实体证书是不正确的；当验证所述CA根证书的数字签名值为正确时，利用所述CA根公钥验证所述第一中间证书的数字签名值是否正确，当验证所述第一中间证书的数字签名值为不正确时，则确定所述第一终端实体证书是不正确的；当验证所述第一中间证书的数字签名值为正确时，利用所述第一中间证书包含的第一代理设备公钥验证所述第一终端实体证书的数字签名值是否正确，当验证所述第一终端实体证书的数字签名值为不正确时，则确定所述第一终端实体证书是不正确的；当验证所述第一终端实体证书的数字签名值为正确时，则确定所述第一终端实体证书是正确的。
可选的，在另一种应用场景下，接收模块702，还用于接收所述代理设备发送的证书申请通知。
参见图8，本申请实施例提供了一种数字证书签发的装置800示意图。该装置800可以是上述任一实施例中的代理设备。该装置800包括至少一个处理器801，内部连接802，存储器803以及至少一个收发器804。
该装置800是一种硬件结构的装置，可以用于实现图6所述的装置600中的功能模块。例如，本领域技术人员可以想到图6所示的装置600中的证书签发单元602、验证单元604或者替换单元605可以通过该至少一个处理器801调用存储器803中的代码来实现，图6所示的装置600中的接收单元601和发送单元603可以通过该收发器804来实现。
可选的，该装置800还可用于实现上述任一实施例中代理装置的功能。
可选的，上述处理器801可以是一个通用中央处理器(central processing unit，CPU)，网络处理器(network processor，NP)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
上述内部连接802可包括一通路，在上述组件之间传送信息。可选的，内部连接802为单板或总线等。
上述收发器804，用于与其他设备或通信网络通信。
上述存储器803可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically  erasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器803用于存储执行本申请方案的应用程序代码，并由处理器801来控制执行。处理器801用于执行存储器803中存储的应用程序代码，以及配合至少一个收发器804，从而使得该装置800实现本专利方法中的功能。
在具体实现中，作为一种实施例，处理器801可以包括一个或多个CPU，例如图8中的CPU0和CPU1。
在具体实现中，作为一种实施例，该装置800可以包括多个处理器，例如图8中的处理器801和处理器807。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
参见图9，本申请实施例提供了一种终端实体900示意图。该终端实体900可以是上述任一实施例中的终端实体。该终端实体900包括至少一个处理器901，内部连接902，存储器903以及至少一个收发器904。
该终端实体900是一种硬件结构的装置，可以用于实现图7所述的终端实体700中的功能模块。例如，本领域技术人员可以想到图7所示的终端实体700中的验证模块703或者替换模块704可以通过该至少一个处理器901调用存储器903中的代码来实现，图7所示的终端实体700中的发送模块701和接收模块702可以通过该收发器904来实现。
可选的，该终端实体900还可用于实现上述任一实施例中代理装置的功能。
可选的，上述处理器901可以是一个通用中央处理器(central processing unit，CPU)，网络处理器(network processor，NP)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
上述内部连接902可包括一通路，在上述组件之间传送信息。可选的，内部连接902为单板或总线等。
上述收发器904，用于与其他设备或通信网络通信。
上述存储器903可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器903用于存储执行本申请方案的应用程序代码，并由处理器901来控制执行。处理器901用于执行存储器903中存储的应用程序代码，以及配合至少一个收发器904，从而使得该终端实体900实现本专利方法中的功能。
在具体实现中，作为一种实施例，处理器901可以包括一个或多个CPU，例如图9中的CPU0和CPU1。
在具体实现中，作为一种实施例，该终端实体900可以包括多个处理器，例如图9中的处理器901和处理器907。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可以用硬件实现，或固件实现，或它们的组合方式来实现。当使用软件实现时，可以将上述功能存储在计算机可读介质中或作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是计算机能够存取的任何可用介质。以此为例但不限于：计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质。此外。任何连接可以适当的成为计算机可读介质。例如，如果软件是使用同轴电缆、光纤光缆、双绞线、数字用户线(DSL)或者诸如红外线、无线电和微波之类的无线技术从网站、服务器或者其他远程源传输的，那么同轴电缆、光纤光缆、双绞线、DSL或者诸如红外线、无线和微波之类的无线技术包括在所属介质的定影中。如本发明所使用的，盘(Disk)和碟(disc)包括压缩光碟(CD)、激光碟、光碟、数字通用光碟(DVD)、软盘和蓝光光碟，其中盘通常磁性的复制数据，而碟则用激光来光学的复制数据。上面的组合也应当包括在计算机可读介质的保护范围之内。
以上公开的仅为本发明的几个具体实施例，显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (12)

  1. 一种数字证书签发的方法，其特征在于，所述方法包括：
    代理设备接收终端实体发送的终端实体证书授权请求，所述终端实体证书授权请求包含第一终端实体公钥；
    所述代理设备根据所述终端实体证书授权请求，对所述第一终端实体公钥生成第一终端实体证书，使用第一代理设备私钥对所述第一终端实体证书进行数字签名，获得所述第一终端实体证书的数字签名值，生成终端实体证书授权响应，其中，所述终端实体证书授权响应包含所述第一终端实体证书和所述第一终端实体证书的证书链，所述第一终端实体证书包含所述第一终端实体公钥和所述第一终端实体证书的数字签名值，所述第一终端实体证书的证书链用于验证所述第一终端实体证书的数字签名值是否正确，所述第一终端实体证书的证书链包含授权认证CA根证书和第一中间证书，其中，所述第一中间证书包含第一代理设备公钥，所述第一代理设备公钥和所述第一代理设备私钥为所述代理设备生成的一对密钥对；
    所述代理设备向所述终端实体发送所述终端实体证书授权响应。
  2. 根据权利要求1所述的方法，其特征在于，还包括：所述代理设备向CA服务器发送中间证书授权请求，所述中间证书授权请求包含所述第一代理设备公钥；
    所述代理设备接收所述CA服务器发送的中间证书授权响应，所述中间证书授权响应包含了第一中间证书和第一中间证书的证书链，所述第一中间证书包含所述第一代理设备公钥和第一中间证书的数字签名值，其中，所述第一中间证书的证书链包含所述CA根证书，所述CA根证书包含CA根公钥，所述第一中间证书的数字签名值由所述CA服务器使用CA根私钥对所述第一中间证书进行数字签名获得的，所述CA根公钥和所述CA根私钥为所述CA服务器生成的一对密钥对；
    所述代理设备使用所述第一中间证书的证书链验证所述第一中间证书的数字签名值是正确的。
  3. 根据权利要求1或2所述的方法，其特征在于，还包括：所述代理设备接收所述终端实体发送的第一证书更新请求，所述第一证书更新请求包含第二终端实体公钥；
    所述代理设备根据所述第一证书更新请求，对所述第二终端实体公钥生成第二终端实体证书，并使用第一代理设备私钥对所述第二终端实体证书进行数字签名，获得所述第二终端实体证书的数字签名值，生成第一证书更新响应，其中，所述第一证书更新响应包含所述第二终端实体证书和所述第二终端实体证书的证书链，所述第二终端实体证书包含所述第二终端实体公钥和所述第二终端实体证书的数字签名值，所述第二终端实体证书的证书链用于验证所述第二终端实体证书的数字签名值是否正确，所述第二终端实体证书的证书链包含所述CA根证书和第一中间证书；
    所述代理设备向所述终端实体发送所述第一证书更新响应。
  4. 根据权利要求1或2所述的方法，其特征在于，还包括：所述代理设备向所述CA服务器发送第二证书更新请求，所述第二证书更新请求包含第二代理设备公钥；
    所述代理设备接收所述CA服务器发送的第二证书更新响应，所述第二证书更新响应包含第二中间证书和第二中间证书的证书链，所述第二中间证书包含所述第二代理设备公钥和第二中间证书的数字签名值，其中，所述第二中间证书的数字签名值由所述CA服务器使用CA根私钥对所述第二中间证书进行数字签名获得的；
    所述代理设备使用所述第二中间证书的证书链验证所述第二中间证书的数字签名值是正确的，并将所述第一中间证书替换为所述第二中间证书。
  5. 根据权利要求4所述的方法，其特征在于，还包括：
    所述代理设备接收所述终端实体发送的第三证书更新请求，所述第三证书更新请求包含所述第一终端实体公钥；
    所述代理设备根据所述第三证书更新请求，对所述第一终端实体公钥生成第三终端实体证书，并使用第二代理设备私钥对所述第三终端实体证书进行数字签名，获得所述第三终端实体证书的数字签名值，生成第三证书更新响应，其中，所述第三证书更新响应包含所述第三终端实体证书和第三终端实体证书的证书链，所述第三终端实体证书包含所述第一终端实体公钥和所述第三终端实体证书的数字签名值，所述第三终端实体证书的证书链用于验证所述第三终端实体证书的数字签名值是否正确，所述第三终端实体证书的证书链包含所述CA根证书和所述第二中间证书，所述第二代理设备私钥和所述第二代理设备公钥为所述代理设备生成的一对密钥对；
    所述代理设备向所述终端实体发送所述第三证书更新响应。
  6. 根据权利要求4所述的方法，其特征在于，所述使用所述第二中间证书的证书链验证所述第二中间证书的数字签名值是正确的，具体为：
    所述代理设备利用CA根公钥验证所述CA根证书的数字签名值是否正确，当验证所述CA根证书的数字签名值为不正确时，确定所述第二中间证书是不正确的；当验证所述CA根证书的数字签名值为正确时，利用所述CA根公钥验证所述第二中间证书的数字签名值是否正确，当验证所述第二中间证书的数字签名值为不正确时，则确定所述第二中间证书是不正确的；当验证所述第二中间证书的数字签名值为正确时，则确定所述第二中间证书是正确的。
  7. 一种数字证书签发的装置，其特征在于，所述方法包括：
    接收单元，用于接收终端实体发送的终端实体证书授权请求，所述终端实体证书授权请求包含第一终端实体公钥；
    证书签发单元，用于根据所述终端实体证书授权请求，对所述第一终端实体公钥生成第一终端实体证书，使用第一代理设备私钥对所述第一终端实体证书进行数字签名，获得所述第一终端实体证书的数字签名值，生成终端实体证书授权响应，其中，所述终端实体证书授权响应包含所述第一终端实体证书和所述第一终端实体证书的证书链，所述第一终端实体证书包含所述第一终端实体公钥和所述第一终端实体证书的数字签名值，所述第一终端实体证书的证书链用于验证所述第一终端实体证书的数字签名值是否正确，所述第一终端实体证书的证书链包含授权认证CA根证书和第一中间证书，其中，所述第一中间证书包含第一代理设备公钥，所述第一代理设备公钥和所述第一代理设备私钥为所述代理设备生成的一对密钥对；
    发送单元，用于向所述终端实体发送所述终端实体证书授权响应。
  8. 根据权利要求7所述的装置，其特征在于，还包括：验证单元，其中：
    所述发送单元，还用于向CA服务器发送中间证书授权请求，所述中间证书授权请求包含第一代理设备公钥；
    所述接收单元，还用于接收所述CA服务器发送的中间证书授权响应，所述中间证书授权响应包含了第一中间证书和第一中间证书的证书链，所述第一中间证书包含所述第一代理设备公钥和第一中间证书的数字签名值，其中，所述第一中间证书的证书链包含所述CA根证书，所述CA根证书包含CA根公钥，所述第一中间证书的数字签名值由所述CA服务器使用CA根私钥对所述第一中间证书进行数字签名获得的，所述CA根公钥和所述CA根私钥为所述CA 服务器生成的一对密钥对；
    所述验证单元，用于使用所述第一中间证书的证书链验证所述第一中间证书的数字签名值是正确的。
  9. 根据权利要求7或8所述的装置，其特征在于，所述接收单元，还用于接收所述终端实体发送的第一证书更新请求，所述第一证书更新请求包含第二终端实体公钥；
    所述证书签发单元，还用于根据所述第一证书更新请求，对所述第二终端实体公钥生成第二终端实体证书，并使用第一代理设备私钥对所述第二终端实体证书进行数字签名，获得所述第二终端实体证书的数字签名值，生成第一证书更新响应，其中，所述第一证书更新响应包含所述第二终端实体证书和所述第二终端实体证书的证书链，所述第二终端实体证书包含所述第二终端实体公钥和所述第二终端实体证书的数字签名值，所述第二终端实体证书的证书链用于验证所述第二终端实体证书的数字签名值是否正确，所述第二终端实体证书的证书链包含所述CA根证书和第一中间证书；
    所述发送单元，还用于向所述终端实体发送所述第一证书更新响应。
  10. 根据权利要求7或8所述的装置，其特征在于，还包括：替换单元，其中：
    所述发送单元，还用于向所述CA服务器发送第二证书更新请求，所述第二证书更新请求包含第二代理设备公钥；
    所述接收单元，还用于接收所述CA服务器发送的第二证书更新响应，所述第二证书更新响应包含第二中间证书和第二中间证书的证书链，所述第二中间证书包含所述第二代理设备公钥和第二中间证书的数字签名值，其中，所述第二中间证书的数字签名值由所述CA服务器使用CA根私钥对所述第二中间证书进行数字签名获得的；
    所述替换单元，用于使用所述第二中间证书的证书链验证所述第二中间证书的数字签名值是正确的，将所述第一中间证书替换为所述第二中间证书。
  11. 根据权利要求10所述的装置，其特征在于，所述接收单元，还用于接收所述终端实体发送的第三证书更新请求，所述第三证书更新请求包含所述第一终端实体公钥；
    所述证书签发单元，还用于根据所述第三证书更新请求，对所述第一终端实体公钥生成第三终端实体证书，并使用第二代理设备私钥对所述第三终端实体证书进行数字签名，获得所述第三终端实体证书的数字签名值，生成第三证书更新响应，其中，所述第三证书更新响应包含所述第三终端实体证书和第三终端实体证书的证书链，所述第三终端实体证书包含所述第一终端实体公钥和所述第三终端实体证书的数字签名值，所述第三终端实体证书的证书链用于验证所述第三终端实体证书的数字签名值是否正确，所述第三终端实体证书的证书链包含所述CA根证书和所述第二中间证书，所述第二代理设备私钥和所述第二代理设备公钥为所述代理设备生成的一对密钥对；
    所述发送单元，还用于向所述终端实体发送所述第三证书更新响应。
  12. 根据权利要求20所述的方法，其特征在于，所述替换单元，具体用于利用CA根公钥验证所述CA根证书的数字签名值是否正确，当验证所述CA根证书的数字签名值为不正确时，确定所述第二中间证书是不正确的；当验证所述CA根证书的数字签名值为正确时，利用所述CA根公钥验证所述第二中间证书的数字签名值是否正确，当验证所述第二中间证书的数字签名值为不正确时，则确定所述第二中间证书是不正确的；当验证所述第二中间证书的数字签名值为正确时，则确定所述第二中间证书是正确的。
PCT/CN2021/125960 2020-12-04 2021-10-25 数字证书签发的方法、装置、终端实体和*** WO2022116734A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011402744.8A CN114598455A (zh) 2020-12-04 2020-12-04 数字证书签发的方法、装置、终端实体和***
CN202011402744.8 2020-12-04

Publications (1)

Publication Number Publication Date
WO2022116734A1 true WO2022116734A1 (zh) 2022-06-09

Family

ID=81812368

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/125960 WO2022116734A1 (zh) 2020-12-04 2021-10-25 数字证书签发的方法、装置、终端实体和***

Country Status (2)

Country Link
CN (1) CN114598455A (zh)
WO (1) WO2022116734A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115567314A (zh) * 2022-10-14 2023-01-03 中电云数智科技有限公司 一种基于硬件可信信任链的License安全代理方法和平台

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116865971B (zh) * 2023-06-12 2024-02-27 淮南市公安局 一种基于数字证书的物联网终端身份认证方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101488851A (zh) * 2009-02-25 2009-07-22 中国人民解放军信息工程大学 一种可信计算中签发身份证明证书的方法及装置
CN102546173A (zh) * 2011-12-19 2012-07-04 河海大学 基于证书的数字签名***及签名方法
CN104486356A (zh) * 2014-12-29 2015-04-01 芜湖乐锐思信息咨询有限公司 基于互联网在线交易的数据传输方法
CN107360003A (zh) * 2017-08-17 2017-11-17 上海市数字证书认证中心有限公司 数字证书的签发方法、***、存储介质以及移动终端
US10547457B1 (en) * 2016-10-21 2020-01-28 Wells Fargo Bank N.A. Systems and methods for notary agent for public key infrastructure names

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101488851A (zh) * 2009-02-25 2009-07-22 中国人民解放军信息工程大学 一种可信计算中签发身份证明证书的方法及装置
CN102546173A (zh) * 2011-12-19 2012-07-04 河海大学 基于证书的数字签名***及签名方法
CN104486356A (zh) * 2014-12-29 2015-04-01 芜湖乐锐思信息咨询有限公司 基于互联网在线交易的数据传输方法
US10547457B1 (en) * 2016-10-21 2020-01-28 Wells Fargo Bank N.A. Systems and methods for notary agent for public key infrastructure names
CN107360003A (zh) * 2017-08-17 2017-11-17 上海市数字证书认证中心有限公司 数字证书的签发方法、***、存储介质以及移动终端

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115567314A (zh) * 2022-10-14 2023-01-03 中电云数智科技有限公司 一种基于硬件可信信任链的License安全代理方法和平台
CN115567314B (zh) * 2022-10-14 2024-01-30 中电云计算技术有限公司 一种基于硬件可信信任链的License安全代理方法和平台

Also Published As

Publication number Publication date
CN114598455A (zh) 2022-06-07

Similar Documents

Publication Publication Date Title
US10382485B2 (en) Blockchain-assisted public key infrastructure for internet of things applications
US8788811B2 (en) Server-side key generation for non-token clients
US7512785B2 (en) Revocation distribution
US9621355B1 (en) Securely authorizing client applications on devices to hosted services
US20190166117A1 (en) System and method for securing data transport between a non-ip endpoint device that is connected to a gateway device and a connected service
US7181620B1 (en) Method and apparatus providing secure initialization of network devices using a cryptographic key distribution approach
US9225525B2 (en) Identity management certificate operations
US8898457B2 (en) Automatically generating a certificate operation request
US9137017B2 (en) Key recovery mechanism
US7865721B2 (en) Method and system for configuring highly available online certificate status protocol
US20110296171A1 (en) Key recovery mechanism
JP5215289B2 (ja) 分散式の委任および検証のための方法、装置、およびシステム
US20060155855A1 (en) Apparatus, methods and computer software productus for judging the validity of a server certificate
US8806195B2 (en) User interface generation in view of constraints of a certificate profile
US20060085637A1 (en) Authentication system and method
KR20040013668A (ko) 공개키 기반구조에서 인증서 정책 및 인증서 정책사상을이용한 인증서 검증서버에서의 인증서 검증방법
WO2006076382A2 (en) Method and apparatus providing policy-based revocation of network security credentials
JP2004032311A (ja) Ｐｋｉ対応の証明書確認処理方法及びその装置、並びにｐｋｉ対応の証明書確認処理プログラム
WO2022116734A1 (zh) 数字证书签发的方法、装置、终端实体和***
CN113472790A (zh) 基于https协议的信息传输方法、客户端及服务器
US20100223464A1 (en) Public key based device authentication system and method
JP2004248220A (ja) 公開鍵証明書発行装置、公開鍵証明書記録媒体、認証端末装置、公開鍵証明書発行方法、及びプログラム
JP2022552420A (ja) 証明書認証用の分散台帳に基づく方法およびシステム
JP2024513521A (ja) 組み込みデバイスの安全な信頼の起点登録及び識別管理
Perugini et al. On the integration of Self-Sovereign Identity with TLS 1.3 handshake to build trust in IoT systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21899768

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21899768

Country of ref document: EP

Kind code of ref document: A1