TLS Authentication

The aim of authentication is to establish the identity of a party.

There are two components required for TLS authentication:

  1. A key
  2. A certificate

The bouncer analogy

The certificate is an authentication factor offered to the browser and is somewhat analogous to offering a card to a bouncer. First we establish that they have a card (certificate) and that the face/photo match (checking the key fingerprint). The bouncer is not going to accept a card that simply has your name and photo, it has to be a drivers license or passport as these are issued by a trusted authority.

TLS authentication works like this. We first check that the key's fingerprint matches, we then need to check that the subject (normally the domain name) matches the certificate

We then need to establish whether or not the certificate provided is trustworthy. This is the authentication of the certificate itself by checking that it has been issued by a certificate authority.

TLS authentication is commonly used by clients to authenticate servers, however, it can also be used by servers to authenticate clients. In any case, it either case, you offer a certificate as proof of your key.


A certificate is composed chiefly of three things.

  • A public key
  • A "fingerprint" of the private key.
  • Metadata such as to whom the certificate is issued and for what it is valid for.

Looking at a certificate

openssl s_client -showcerts -connect -servername 2>/dev/null <<<''| openssl x509 -text --noout   
        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = FR, ST = Paris, L = Paris, O = Gandi, CN = Gandi Standard SSL CA 2
            Not Before: Mar  9 00:00:00 2017 GMT
            Not After : Mar  9 23:59:59 2019 GMT
        Subject: OU = Domain Control Validated, OU = Gandi Standard SSL, CN =
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:

            X509v3 Subject Key Identifier:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies:

            X509v3 CRL Distribution Points:

                Full Name:

            Authority Information Access:
                CA Issuers - URI:
                OCSP - URI:

            X509v3 Subject Alternative Name:
    Signature Algorithm: sha256WithRSAEncryption

The core function of certificates is to prove an association between a public key and its corresponding private key.

The difference between certificates and public keys

Public keys on their own have virtually no security because we have no way of proving the identity of the receiving party x

If you send a message with a public key, only the owner of the corresponding private key can decrypt the message. But we need a way to authenticate this key so we can be sure we are sending the message to the owner of the private key.

So a certificate contains the private key and also a hash of the private key. Before a browser begins any communication, the server must provide a hash (usually SHA256) of the private key, and the browser checks it matches the cert.

Verifying certificates

Now if you've ever set up a encrypted web server before, you know it's actually the server who provides the certifciate. So isn't this the same problem with using public keys?

Yes. There are two ways to authenticate the fingerprint.

  1. The browser actually has a copy of the certificate itself (this is the case when using self signed certs)
  2. Certificate authorities

The browser has a pre-bundled set of certificates that are trusted by default. We can also manually insert certificates on our own.

There are billions of web servers and we can't possibly include all of them in every web browser. So certificate authorities are needed.

These pre-bundled authority certificates are issued by "trusted" organizations, or more accurately, by trusted private keys.

Certificate authorities

With self-signed server certificates, it proves the fingerprint of the server itself. Unless you issued it yourself, and have a copy of the cert in your browser, you're taking it at their own word that they are trustworthy (have a valid key).

While server certificates validate the intgerity of public key with respect to a private key, what certificate authorities do is a bit different.

They validate whether or not the private key is actually reputable by seeing if they can establish that the requester actually has a legitimate relationship with the subject (generally domain name).

You send them a request containing a hash of your certificate (CSR) claiming to represent the CN

They will send you a token.Having this token is sufficient to establish that you were the one who sent the request (therefore possessing the server private key )

If they can receive the token by visiting the common name (via http or email) then that proves you actually have control of the domain. and if they are happy with it, they add the fingerprint of their own private key and therefore making your certifcate trustworhy to browsers.

Running your own certificate authority?
For certain internal operations, it's okay and sometimes even better to run your own CA.

However, browsers don't like this.

With my own CA, I can issue a very dubious certificate for In fact, I may have even gotten it into their browser's "trustworthy" bundle making it a sketchy but technically "valid" certificate for

Ideally, the browser will present a scary warning before allowing the connection to go through because it doesn't know who issued the cert. However, if I have gotten my CA cert into their browser, it will only present the warning once. (We will see how to combat this with CAA records and Public key stapling)