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 https://www.amazon.com, Amazon's server will send you a certificate. This certificate binds a particular public key to the name "www.amazon.com" 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, "www.amazon.com,"
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.

• Domain-validated certificates. DigiCert asks for an e-mail address (of the Acme Corp employee) and a person's name plus Acme Corp's web domain. The person in question must match the registration information held for the registered domain (acmecorp.com). Likely, DigiCert sends a confirmation e-mail to the presumed person to ensure he controls the domain. (This can be done in an automated way too.)
• Extended validation. Human interaction can be a way to research Acme Corp and the person applying for the certificate. This is done by telephone, paper documents signed or even a face-to-face is required before the issuing authority trusts the applicant and issues him a certificate.
• Agreed-upon change to website. DigiCert asks the applicant to make a change to Acme Corp's website, then verifies that the change has been made as specified.

Let's get a certificate (for free)

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

1. Go to letsencrypt.org.
2. Click Get Started.
3. Visit certbot.eff.org 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 0.0.0.0:80              0.0.0.0:*               LISTEN      9/nginx
   

4. It appears that certbot.eff.org's software runs in Snap on Linux. (I loathe Snap, but...).

Appendix

Here are some older notes on certificates.

Links

• http://www.explainthatstuff.com/encryption.html
• http://computer.howstuffworks.com/digital-signature.htm
• http://en.wikipedia.org/wiki/Public-key_cryptography
• http://www.pgpi.org/doc/pgpintro/

Internal structure of an X.509 v3 certificate

How public encryption works (step-by-step)

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