1. Certificate
   1. Digitally signed electronic documents that bind a public key with a user identity.
2. Information Contained Within a Certificate
   1. Serial Number:
      1. Assigned by the CA and used to uniquely identify the certificate
   2. Subject:
      1. The person or entity that is being identified
   3. Signature Algorithm:
      1. The specific algorithm used for signing the digital certificate
   4. Signature:
      1. The digital signature from the certificate authority, which is used by devices that want to verify the authenticity of the certificate issued by that CA
   5. Issuer:
      1. The entity or CA that created and issued the digital certificate
   6. Valid From:
      1. The date the certificate became valid
   7. Valid To:
      1. The expiration date of the certificate
   8. Key Usage:
      1. The functions for which the public key in the certificate may be used
   9. Public Key:
      1. The public portion of the public and private key pair generated by the host whose certificate is being looked at
   10. Thumbprint Algorithm:
       1. The hash algorithm used for data integrity
   11. Thumbprint:
       1. The actual hash
   12. Certificate Revocation List Location:
       1. The URL that can be checked to see whether the serial number of any certificates issued by the CA have been revoked
3. Certificate Authentication Process
   1. Authenticate the Certificate Authority (CA):
      1. The client authenticates the CA server. This requires the server's public key. To obtain a copy of this public key, these options are available:
         1. For well-known CA servers, your web browser automates this process
         2. For less well-known CA servers, download the root certificate and use an out-of-band method to validate it. Call the root CA owner and compare their provided hash value to the hash value on your digital certificate.
   2. Request an Identity Certificate:
      1. Generate a public-private key pair.
      2. Include this generated public key in requests for your identity certificate, sent to the CA server.
      3. Your Identity Certificate is sent back to you, digitally signed by the CA server.
      4. Because you already authenticated the CA server and can now verify its digital signature, you know your Identity Certificate is valid.
4. TLS Certificate Types
   1. Wildcard Certificate:
      1. A single public key certificate that can be used by multiple subdomains (or all subdomains) of a single domain.
      2. A single wildcard certificate for https://*.example.com will secure all subdomains on the https://*.example.com domain
      3. Because the wildcard only covers one level of subdomains, this wildcard certificate would not be valid for the domain test.login.example.com
      4. Takes this form:
         1. *.example.com
      5. test.login.example.com
   2. Subject Alternative Name:
      1. An extension to X.509 used to tie multiple addresses, IDs, or DNS hostnames to an Identity (Certificate).
      2. Allows these values to be associated with a security certificate using a subjectAltName field:
         1. Email addresses
         2. IP addresses
         3. URIs
         4. DNS names
         5. Directory names
         6. Object IDs
      3. Takes this form:
         1. links.example.com
         2. tech-support.example.com
         3. example.com
         4. answers.tech-support.example.com
         5. answers.tech-support.example.com/info
5. Single-Sided and Dual-Sided Certificates
   1. Single-Sided Certificates:
      1. Most secure communication sessions use single-sided certificates.
      2. The server validates itself to certificate recipients. Users do not need to validate their own identity.
      3. This model is used for web servers with thousands of connections, where availability is more important than two-way authentication.
   2. Dual-Sided Certificates:
      1. When a limited number of computers and sessions are involved, the organization can prioritize security (two-way authentication) and also have availability.
6. Trust Models
   1. Chain of Trust:
      1. Beginning with the root certificate authority to the end entity (user or program), each link in the list of certificates has been validated.
      2. This ensures that only trusted software and hardware are used, while maintaining flexibility.
      3. Trust Anchor:
         1. Digitally-signed software can be trusted.
         2. If it had been illegally modified, its signature would be invalid.
         3. The software that signed it can be trusted for the same reason.
         4. The trustworthiness of each layer is guaranteed by the one before, back to the trust anchor.
   2. Web of Trust
      1. A decentralized model used for sharing certificates without the need for a centralized CA.
      2. An alternative PKI trust architecture that enables all CAs as Root CAs.
      3. Protocols such as PGP (Pretty Good Privacy) are the utmost users of web of trust.
      4. Decentralization extends all the way to the end user.