Public key Infrastructure is a centralized trust model that establishes trust using certificates and certificate authorities to convey a public key to establish encrypted communication. A system that wants to provide encrypted communication will create a private and public key pair. A widely trusted certificate authority will provide a signed certificate with that systems public key. All clients that trust the certificate authority will trust the public key that belongs to the server because the certificate with the public key is signed by the certificate authority. This uses the already trusted certificate authority to “vouch” for the server. This mitigates a man-in-the-middle attack. PKI can still be vulnerable to man-in-the-middle attacks if the certificate authority’s private key compromised. Expiration of the certificates mitigates this.

Certificates

Is an electronic document used to prove the ownership of a public key and prove an entity is who it claims it is. The certificate standard that is most commonly used is X.509 defined by the ITU-T. X.509 certificates are in ASN.1 format like other ITU-T standards (LDAP) . The PEM format is the ASN.1 certificate encoded to base64 and preceded by “—–BEGIN FOO —-” and followed by “—–END FOO—–,”

SEQUENCE {
    SEQUENCE {
       [0] {
          INTEGER 0x02 (2 decimal)
       }
       INTEGER 0x00bb4ecb7796340a46
       SEQUENCE {
          OBJECTIDENTIFIER 1.2.840.113549.1.1.5 (sha1WithRSAEncryption)
          NULL
        }
       SEQUENCE {
          SET {
             SEQUENCE {
                OBJECTIDENTIFIER 2.5.4.6 (countryName)
                PrintableString 'US'
             }
          }
          SET {
             SEQUENCE {
                OBJECTIDENTIFIER 2.5.4.8 (stateOrProvinceName)
                PrintableString 'Connecticut'
             }
          }
          SET {
             SEQUENCE {
                OBJECTIDENTIFIER 2.5.4.7 (localityName)
                PrintableString 'Fairfield'
             }
          }
...

What is above encoded to ASN.1 in hex

30 82 04 39 30 82 03 21 a0 03 02 01 02 02 09 00 bb 4e cb 77 96 34 0a 46 30 0d 06 09 2a  
86 48 86 f7 0d 01 01 05 05 00 30 70 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 14 30 12  
06 03 55 04 08 13 0b 43 6f 6e 6e 65 63 74 69 63 75 74 31 12 30 10 06 03 55 04 07 13 09  
46 61 69 72 66 69 65 6c 64 31 14 30 12 06 03 55 04 0a 13 0b 49 50 43 20 66 61 6b 65 20  
43 41 31 10 30 0e 06 03 55 04 0b 13 07 66 61 6b 65 20 43 41 31 0f 30 0d 06 03 55 04 03  
13 06 46 41 4b 45 43 41 30 1e 17 0d 32 30 30 32 32 38 32 30 30 38 33 33 5a 17 0d 32 33  
30 32 32 37 32 30 30 38 33 33 5a 30 70 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 14 30  
12 06 03 55 04 08 13 0b 43 6f 6e 6e 65 63 74 69 63 75 74 31 12 30 10 06 03 55 04 07 13  
09 46 61 69 72 66 69 65 6c 64 31 14 30 12 06 03 55 04 0a 13 0b 49 50 43 20 66 61 6b 65  
20 43 41 31 10 30 0e 06 03 55 04 0b 13 07 66 61 6b 65 20 43 41 31 0f 30 0d 06 03 55 04  
03 13 06 46 41 4b 45 43 41 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03  
82 01 0f 00 30 82 01 0a 02 82 01 01 00 b9 49 4b e5 13 ed 23 e8 ea f2 c9 e7 29 eb 17 d1  
db 61 1b 11 e2 1b 80 c4 5c 3f 6a de 68 9f a1 78 11 e3 92 90 24 4e 60 53 6a 0e 0e 5d 4c  
5a 0b 04 71 27 7a 93 de a8 93 23 68 36 bc 51 00 14 c2 0c d7 00 8a d1 1e ee 67 a9 fe 06  
6a 8f 7a 1b 7e 2e ae 40 dc 9a ee f7 97 be b9 8e b9 c5 95 e6 e3 95 54 2d 34 ef d4 94 d2  
41 15 ac 83 62 78 07 16 91 27 ee ad 60 e6 fd 7f 4e 73 51 45 f5 f8 05 19 5a d1 8a dd ea  
02 dc 1c 06 ff a6 6e a7 2f 50 cc  
...

What is above encoded to base64

MIIEOTCCAyGgAwIBAgIJALtOy3eWNApGMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
BAYTAlVTMRQwEgYDVQQIEwtDb25uZWN0aWN1dDESMBAGA1UEBxMJRmFpcmZpZWxk
MRQwEgYDVQQKEwtJUEMgZmFrZSBDQTEQMA4GA1UECxMHZmFrZSBDQTEPMA0GA1UE
AxMGRkFLRUNBMB4XDTIwMDIyODIwMDgzM1oXDTIzMDIyNzIwMDgzM1owcDELMAkG
A1UEBhMCVVMxFDASBgNVBAgTC0Nvbm5lY3RpY3V0MRIwEAYDVQQHEwlGYWlyZmll
bGQxFDASBgNVBAoTC0lQQyBmYWtlIENBMRAwDgYDVQQLEwdmYWtlIENBMQ8wDQYD
VQQDEwZGQUtFQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5SUvl
E+0j6Oryyecp6xfR22EbEeIbgMRcP2reaJ+heBHjkpAkTmBTag4OXUxaCwRxJ3qT
3qiTI2g2vFEAFMIM1wCK0R7uZ6n+BmqPeht+Lq5A3Jru95e+uY65xZXm45VULTTv
1JTSQRWsg2J4BxaRJ+6tYOb9f05zUUX1+AUZWtGK3eoC3BwG/6Zupy9QzH7OQ84u 
...

How a certificate works

A certificate has four main pieces that make it work and other elements we will get into later.

  • Public key – This is the public key that is used for the symmetrical encryption key. See Asymetric Cryptography or Public-key Cryptography
  • Subject – Describes who this certificate which includes the FQDN or IP address the far end would use
  • Issuer – Describes who signed the certificate.
  • Signature – hash of the certificate encrypted with the private key

Subject

Subject is a comma separated list of fields that describe the organization and system the public key is for.

C = US,ST = Connecticut,L = Fairfield,O = IPC fake CA,OU = fake CA,CN = FakeCA.ipc.com

Issuer

Issuer is the subject of the certificate authority that signed the certificate

Signature

A signature is a hash of the certificates contents , encrypted with a private key by the issuer also know as the certificate authority .

A hash is an algorithm that produces a fixed size number called a hash from a set of data where the original data can not be derive from the number. If you input single character into a hash function or input the whole contents of a DVD into a hash function the output would be a 128 bit number in both scenarios in the case of using the SHA1 hash algorithm in this example. The 128 bit number will be different for both scenarios but will produce the same 128 bit number every time on every machine using the SHA1 hash algorithm. It is also nearly impossible to derive the original set of data input into the has function from the 128 bit number. Hash functions have many uses such as when storing user passwords in a system that authenticates users, verify data integrity of a file, and is what makes block-chain work. CRC, MD5, SHA1 and SHA2 are popular hash algorithms. SHA1 and SHA2 are what is used today in certificates. SHA2 includes many different hash algorithms such as SHA256.

$ sha1sum helloWorld.txt  
b73e25f9f6c8d8639743525756764927b2630545 helloWorld.txt

When a certificate is signed, the contents of the certificate is hashed. This is used to verify the contents of the certificate has not changed. The hash is then encrypted with private key.

When the client receives the certificate it hashes the content. Then it decrypts the signature with the certificate authorities public key the client has since it trusts the certificate authority and gets the hash that was generated by the certificate authority of the certificate’s contents provided to the certificate authority by the server. The client will check the hashes are the same which verifies the certificate was signed by the certificate authority and can trust the certificate from the server since the client trust the certificate authority.

Self-signed Certificate

A self-signed certificate is similar to above but instead of a certificate authority signing the certificate, the server signs the certificate and the client uses the servers public key to decrypt the signature. This is just a way for a server to convey a public key to a client in the case you dont want to use a certificate authority or in the case of a certificate authority self-signs its certificates it gives to the clients.

Client Trust With Certificate Authority

A certificate authority creates a private and public key pair. It uses the private key to sign server certificates ans self sign a certificate with the public key to give to clients. These are called CA certificates. The clients get the CA certificates with the installation of the operating system or when a system administrator installs it. The operating system developers get the CA certificates from the known and well trusted certificate authorities

CA certificates come with windows

on a linux system they are located under /etc/ssl/certs

/etc/ssl/certs# ls G* 
GeoTrust_Global_CA_2.pem
GeoTrust_Universal_CA_2.pem
GlobalSign_Root_CA.pem
GeoTrust_Global_CA.pem
GeoTrust_Universal_CA.pem
GlobalSign_Root_CA_-_R2.pem
GeoTrust_Primary_Certification_Authority_-_G2.pem
Global_Chambersign_Root_-_2008.pem
GlobalSign_Root_CA_-_R3.pem
GeoTrust_Primary_Certification_Authority_-_G3.pem
GlobalSign_ECC_Root_CA_-_R4.pem
Go_Daddy_Class_2_CA.pem
GeoTrust_Primary_Certification_Authority.pem
GlobalSign_ECC_Root_CA_-_R5.pem
Go_Daddy_Root_Certificate_Authority_-_G2.pem

Signing the Server Certificate

For a server to get a certificate signed by certificate authority, The certificate authority has to verify the identity of the organization that is requesting a certificate for their server. It can be as strict as establishing a relationship with background check process or simply verifying that the organization owns the FQDN it is requesting to get signed by sending an email from the FQDN or the certificate authority will give a code to be put on a page on a web server for that the FQDN resolves to. There are two processes a server can get a signed certificate from a certificate authority.

  1. The certificate authority creates a public/private key pair for the server and creates and signs a certificate containing the public key of the key pair. The certificate and key pair are given to the organization that owns the server by hand, and the organization installs the key pair and certificate on the server.
  2. The server generates the public/private key pair and a Certificate Sign Request(CSR) that contains the public key of the key pair. The organization emails or uploads the CSR to the certificate authority. Since it contains only the public key, which will be public, there is nothing secret in the CSR and can be transmitted to the certificate authority insecurely. This is the easiest and most popular method.

A CSR is essentially a certificate without a signature. It contains a subject and public key . The certificate authority uses to information in the CSR to create the data in the certificate. The certificate authority may add features and constraints to the certificate to broaden or narrow what the server it is signing the certificate for can be trusted to do. For example it can provide a wild card for sub-domains , it can provide a certificate revocation list where clients can check an online list to see if the certificate authority revoked the certificate or it can allow a server to be a intermediate certificate authority and sign on behalf of the certificate authority.

Certificate Authority Chain of Trust

Since a certificate authority can allow another certificate authority sign certificates on their behalf, a chain of trust can be created. This makes operations of signing certificates easier since one system does not have to sign all the certificates, also this allows a globally trusted certificate authority to give an organization the ability to sign certificates within their infrastructure. The certificate authority does not have to sign all the certificates for all the servers at an organization. It can sign one for the organization’s internal certificate authority and allow it to only sign certificates for that organization. The certificate authority that starts the chain is called either the root or the anchor.

Since a client might know of and trust all the intermediate certificate authorities but will trust the root, a list of the chain of trust is provided by the server with the all certificates of all the intermediate certificate authorities. This list is called a bundle or chain and it can include the root or it may not. Some servers require the root or anchor to be included in the bundle and some require that the bundle not contain the root some will take it both ways. When a client connects to a server it will be given a the signed certificate and a bundle. If there is no intermediate certificate authorities the root CA certificate will be the bundle. This is specified in RFC5246 7.4.2

certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.