Digital Signature vs. Digital Certificate | Keyfactor

Public key cryptography, also called asymmetric encryption, is based on computations that are almost impossible to break using today’s fastest computers. But, there is still one problem when using encryption with private and public keys. It is assumed that the public keys are open, meaning that everyone has access to these keys. Nothing is hindering a malevolent actor from claiming a public key that is not his. This creates an integrity problem that can be solved by utilizing Public Key Infrastructure (PKI).

With PKI, users can securely and privately exchange information on an insecure network such as the Internet. To accomplish this, PKI uses two similar-sounding technologies: digital signatures and digital certificates; both are essential components in the certificate authority trust model.

Understanding the Differences

The primary difference between the digital signature and the digital certificate:

  1. The certificate ties the digital signature to a data object, while the digital signature secures the data in transit.
  2. The digital certificate uses the public key to identify the data’s source, while the digital signature uses the public key to verify the data’s integrity.

Digital Signature Example

Let’s take a look at an example scenario to help understand the general process flow when encrypting a message using digital signatures and digital certificates.

Allow me to reintroduce our common actors named Alice and Bob.

  • The creation of a digital signature begins when Alice uses her private key to encrypt a message.
  • The output, also known as a hash value, is then attached to the message and sent to Bob.
  • When Bob receives the message, he first decrypts it with the public key that Alice has provided, proving it came from Alice.
  • Then Bob passes the message into the same one-way hashing function and compares it to the attached hash value.
  • If the hash values are the same, the message has not been altered.
  • Bob needs to prove the authenticity of his public key to Alice. He must obtain a digital certificate by registering his public key and information about himself to a certificate authority. Bob’s is issued a certificate containing his public key and the information he provided. The CA then uses its private key to digitally sign Bob’s certificate and attaches the CA public key to Bob’s new certificate.
  • Bob shows Alice his new digital certificate. She can prove that Bob’s public key is valid by decrypting and validating the signature using the certificate authority’s public key.
  • Then Alice passes Bob’s certificate into the same one-way hashing function used when the certificate was created. Bob’s public key is authentic if the hash value matches the one provided in the certificate.
  • If the hash values don’t match, then something in Bob’s certificate has been changed since the CA last signed it. Therefore Alice cannot trust the information on the certificate, including Bob’s public key.

Bob now knows whether he can trust that Alice has digitally signed the message and verified if it has been changed. 

Digital Certificates Example

X.509 PKI certificates safely distribute public keys to ensure the public keys are owned by legitimate owners and not forged by malevolent actors. The X.509 certificates are created and signed by a trusted certificate authority.

Alice and Bob are back, and this time Alice wants to confirm the authenticity of Bob’s signed certificate.

  • Bob needs to prove the authenticity of his public key to Alice. He must obtain a digital certificate by registering his public key and information about himself to a certificate authority. Bob’s is issued a certificate containing his public key and the information he provided. The CA then uses its private key to digitally sign Bob’s certificate and attaches the CA public key to Bob’s new certificate. 
  • Bob shows Alice his new digital certificate. She can prove that Bob’s public key is valid by decrypting and validating the signature using the certificate authority’s public key.
  • Then Alice passes Bob’s certificate into the same one-way hashing function used when the certificate was created. Bob’s public key is authentic if the hash value matches the one provided in the certificate. 
  • If the hash values don’t match, then something in Bob’s certificate has been changed since the CA last signed it. Therefore Alice cannot trust the information on the certificate, including Bob’s public key.

Types of Authorities

The registration authority (RA) is a server that waits for clients to send their Certificate Signing Requests (CSR). Typically, the creation of a public key certificate is started by the subject issuing a request to the RA. The subject generates a key pair, which is then sent together with a certificate request to the RA.

When requests are received, validated, and signed, the certification authority can create a certificate from the submitted key pair. The RA then validates and signs the CSR, which is then sent to a certification authority.

If the key pair that was generated by the subject is invalid or the request does not contain the information which is needed to create a valid certificate, the request is not forwarded to a certification authority. Thereby lessening the load on the certificate authorities.

Certification authorities are trusted by one or more entities with the responsibility to create and sign public-key certificates. Optionally a certification authority may issue the subject’s keys or have them provided by the subject via a Registration Authority.

Certification authorities are regarded as trusted because they have a CA certificate that is signed by another trusted CA; they can also be responsible for Certificate revocations.

The CA manages this task by keeping a data structure called a certificate revocation list (CRL). A CRL contains identifiers for all revoked certificates issued by the same CA. The authenticity of the CRL itself is proved by digitally signing it in a similar way to a public key Certificate.

A validation authority can verify a certificate by downloading the CRL from a CA, verifying the signature, and then checking if the certificate is in the CRL. If it is found in the CRL, the certificate is invalid. Otherwise, it is regarded as a valid certificate.

Another way to handle the revocation of Certificates is by using the Online Certificate Status Protocol (OSCP). The protocol solves the problem that a CRL grows by each revoked certificate. Whenever a certificate needs to be verified, the client must download the full CRL. OSCP instead allows a client to query if a Certificate is valid instead of downloading a CRL. The report states that each response to a client must be signed so that a client can verify its authenticity.

Types of X.509 Certificates

X.509 is a widely accepted protocol that regulates the format of a digital certificate. Three versions of the x509 standard have been defined:

  • X.509 Version 1 was first published as part of the ITU X.500 Directory Services standard in 1988.
  • X.509 version 2 added two new fields to the format in 1993.
  • X. 509 version 3 defines the format for the certificate extensions used to store additional information about the holder of the certificate and to regulate the use of certificates.

X.509 certificates typically attach a digital signature with a public key, a validity period, an issuer, a subject, and a set of extensions. Extensions describe additional certificate features, such as extra certificate attributes or restrictions on the certificate’s use.

X.509 certificates must meet the following three requirements:

1. There is a verification path from the server certificate to a trusted root certificate;

2. The certificate attributes in the verification path meet specific criteria for that verification;

3. The certificate is not listed in the contents of any current CRL or the response of an OCSP request.

X.509 PKI consists of four different components: 

  1. An end entity server that requests a signed digital certificate
  2. A root certificate authority that can issue and verify digital certificates
  3. A registration authority which is the intermediary, and
  4. The end-user who wants to check a server’s public key certificate.

Root certificates, often called a trusted root, are at the source of trust chains in X.509 certificate-based PKI. Root CA can issue and sign trusted certificates, externally, and designate them with specific functions and purposes. But, because it is impossible to confirm the integrity of a self-signed certificate, an auditable certificate hierarchy is needed.  

Root X.509 certificates can be categorized into three different types:

  1. Self-issued Certificates – These certificates are CA certificates where the issuer and the subject have the same values.
  2. Self-signed certificates – These certificates are a different type of self-issued CA certificate where the issuer and subject objects have the same values. The difference between the self-signed and self-issued certificate is that the self-signed certificate is signed using the corresponding private key. This type of certificate might be used by the certificate authority to publicize their public keys.
  3. Cross-certificates – This is a CA certificate with the property that the issuer and subject are different certificate authorities. These are used to confirm and verify the existence of the subject CA.

End-entity certificates are public-key certificates issued by a certificate authority. These certificates have the property whose corresponding private key cannot be used to sign other public-key Certificates.

End-entity public-key certificates are used to verify that their corresponding public keys have not been forged. Even though all certificates issued by a certificate are inheritably trusted, the root CA doesn’t issue end-entity certificates directly. For these reasons, the root CA creates a protective layer of subordinate certificates.

Subordinate Certificates live online, between the root and the end-entity certificates, and chain-link back to the root certificates. This allows public viewers to validate end-entity certificates, even while the root certificate lives offline in a Hardware Security Module.

As long as they link back to a trusted root CA, it is possible to verify the entire trust chain, from the root to the end-entity certificate. There may be more than one layer of subordinate CA. Certificates that live between the subordinate certificates and end-entity certificates are often called intermediate certificates.

Intermediate certificates serve as the master links of trust chains. They may only perform tasks authorized by the root CA. On public hierarchies, one Intermediate CA is authorized to issue only SSL certificates, while another issue only S/MIME certificates.

Another common scenario is to authorize different intermediate CA to issue certificates for each department or location in an organization. Further, you might have one for certifying ECC keys and a different one for RSA keys.

The PKI also needs a directory to issue, store, revoke, and manage X.509 digital certificates.

Managing Digital Certificates

If you’re looking more around managing digital certificates and PKI best practices, check out these additional resources: 


*** This is a Security Bloggers Network syndicated blog from PKI Blog authored by Ryan Yackel. Read the original post at: https://blog.keyfactor.com/digital-signature-vs-digital-certificate