Notes on digital certificates

August 2018
last update:

What does it mean for a digital certificate to be signed?

Digital signatures are created using a private key. A certificate contains a corresponding public key that can be used to verify that the signature is valid.

It means that "someone" has looked at the generated certificate and decided that it's correct and legitimate. Basically, "someone who knows the private key has verified that this data is as it must be" and the certificate says, in essence, that the signature was made (by server XYZ) and therefore means that (server XYZ) knows the private key that corresponds to the public key in this certificate. Someone" uses his signing key to sign the certificate. (This costs money in a carefully garded and secure transaction during which the signer, the certificate authority, is entrusted with the public key.)

When "someone else" gets the certificate, he can see who signed it. If the signer is trusted, then "someone else" will (presumably) trust it as well.

The signing depends on what kind of certificate is issued. A digital certificate consists of three parts:

  1. a public key,
  2. certificate information (username, user id, etc.)
  3. and one or more digital signatures.*

* A signature is done by computing the hash of the certificate, encrypting it using the signer's private (signing) key, then adding the result to the (list of) digital signatures.

Certificates only prove identity; they perform no other useful function (i.e.: like being used to encrypt or hash something). In a typical SSL certificate, for instance, the information in the certificate is a binding between a public key and a common name. When you point your browser at, Amazon's server will send you a certificate. This certificate binds a particular public key to the name "" and your browser can confirm by three things that it's talking to the real Amazon:

  1. server presented a certificate that was valid and signed by a key it trusts,
  2. certificate binds to the identity, ","
  3. server proves it possesses the private key corresponding to the certificate.

Here's an illustration I largely plagerized from a Wikipedia article. The narrative is

  1. The Acme Corporation wants a certificate its shopping website can give users. It uses a program to generate a public key and creates information identifying itself.
  2. A certificate authority, like DigiCert, verifies the authenticity and honor of Acme Corp then uses its own private key to encrypt this information creating a certificate containing
    1. Acme Corp's public information,
    2. Acme Corp's public key and
    3. DigiCert's own signature using the portion they encrypted.
  3. Acme Corp pays DigiCert their fee for this service and takes delivery of their signed certificate. They give a copy of this certificate to each customer engaging transactions with their website.
  4. Because browsers (and other web-intelligent applications) ship with a hundred or so certificates containing various trusted, certificate-authority certificates, the customer's browser uses Acme Corp's certificate (that came down to it when the customer navigated to Acme Corp's website) to verify the legitimacy of Acme Corporation as a worthy of the customer's transaction.

In step 2 of the example above, how does DigiCert trust that Acme Corp's request is honorable? How does DigiCert know that there's not some bogus person claiming to work for Acme Corp asking for a certificate that he will then use to subvert transactions from unsuspecting customers?

Each certificate authority is different and each uses many ways of doing this, but here are some of the methods employed. There are many other (in fact, what are known as the Ten Blessed Methods), but these give a good idea.

Let's get a certificate (for free)

First time, that is. Let's consider that I want a certificate for It's running on a Linux server and I have ssh access to it.

  1. Go to
  2. Click Get Started.
  3. Visit to get customize instructions for proving that I have control over this domain. My pages are served up by Apache 2 on Ubuntu 14.04 LTS. Port 80 should be open, i.e.: available to the Internet.
    russ@tirion ~/bin $ ssh -2022 [email protected]
    root@javahotchocolate-655bc85c77-v44w4:~# cat /etc/issue
    Ubuntu 14.04.6 LTS \n \l
    root@javahotchocolate-655bc85c77-v44w4:~# netstat -tulpn | grep LISTEN | grep :80
    tcp        0      0    *               LISTEN      9/nginx
  4. It appears that's software runs in Snap on Linux. (I loathe Snap, but...).


Here are some older notes on certificates.


Internal structure of an X.509 v3 certificate

How public encryption works (step-by-step)

The following is "sort-of" how it works.