Certificates

Last Updated: 2024-01-31

A certificate is itself signed by a certificate authority (CA) using CA's private key. This verifies the authenticity of the certificate.

The binding is asserted by having a trusted Certification Authority (CA).

CAs use a private key to cryptographically sign all issued certificates.

• format: publicly trusted PKIs (i.e. those trusted by the browsers) must conform to RFC 5280, which requires the use of the X.509 v3 format.
• signatures: prove that a certificate was issued by a specific CA and that it was not modified after it was signed.
• certification path: To verify a certificate, a browser will obtain a sequence of certificates, each one having signed the next certificate in the sequence, connecting the signing CA’s root to the server’s certificate.

server’s certificate is called the leaf or end entity certificate.

The signature on the certificate can be verified using normal public key cryptography.

X.509

X.509 digital certificate asserts the authenticity of the public key.

certificate = public key + identity

fields: X.509 version, algorithm, issuer (the CA), subject (the identity the certificate is issued to), validity perirod.

Examples:

• The most common use case of X.509-based PKI is TLS.
• SSH keys are a form of X.509 certificate.

Certificate Attributes (subject)

• CN: Common Name.
• OU : OrganizationalUnit.
• O : Organization.
• L: Locality.
• S: StateOrProvinceName.
• C: CountryName.

Encoding schemes

Two major encoding schemes for X.509 certificates and keys: PEM (Base64 ASCII), and DER (binary).

PEM format: the most common format for X.509 certificates, CSRs, and cryptographic keys. A PEM file is a text file containing one or more items in Base64 ASCII encoding, each with plain-text headers and footers.

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Certificate Manager

• obtain certificates from a variety of Issuers.
• ensure the certificates are valid and up-to-date.
• attempt to renew certificates at a configured time before expiry.

Kubernetes cert-manager: adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates. Read more: cert-manager

How to generate a Certificate from CA

                    (genrsa) => ca.key
                      ca.key => ca.crt
                    (genrsa) => server.key
                    (create) => csr.conf
       server.key + csr.conf => server.csr
ca.key + ca.crt + server.csr => server.crt

• generate a private key
• use the private key to create a CSR (Certificate Signing Request) with requested info (A CSR contains details about location, organization, and FQDN )
• send the CSR to CA
• CA generates and signs the certificate with root CA and key
• CA returns the certificate to user

CSR (Certificate Signing Request) is the message that's sent to the CA in order to get a digital certificate created.

Selfsigned

self-signed certificates are public key certificates that are not issued by a certificate authority (CA).

root certificate, is a form of self-signed certificate.

• user creates their own CA (root certificate and CA private key)
• user generates a Server private key
• user creates a CSR using the server private key
• create a self-signed certificate with the CSR using root certificate and CA private key
• deploy the self-signed certificate (server)
• install rootCA in browser or OS

How to add a self-signed CA cert

$ sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
$ sudo update-ca-certificates

update-ca-certificates updates /etc/ssl/certs / /etc/ssl/certs/ca-certificates.crt according to /etc/ca-certificates.conf

/etc/ca-certificates.conf: Each line gives a pathname of a CA certificate under /usr/share/ca-certificates that should be trusted.

All certificates with a .crt extension found below /usr/local/share/ca-certificates are also included as implicitly trusted.

Directory of CA certificates.

/usr/share/ca-certificates
/usr/local/share/ca-certificates

Two types of certificates

• CA certificate: A CA can issue other certificates. The top level, self-signed CA certificate is sometimes called the Root CA certificate. Other CA certificates are called intermediate CA or subordinate CA certificates.
• end-entity certificate. An end-entity certificate identifies the user, like a person, organization or business. An end-entity certificate cannot issue other certificates. An end-entity certificate is sometimes called a leaf certificate since no other certificates can be issued below it.

ASN.1

Abstract Syntax Notation One (ASN.1): an IDL (interface description language) to define data structures that can be serialized and deserialized in a cross-platform way.

Root of trust

• Online: use a wellkown public CA, e.g. DigiCert, Verisign, etc.
• Airgapped (no external internet connection): use a TPM device (e.g. Thales k570) as roots of trust.

Public Key Infrastructure (PKI)

PKI is sometimes used as a synonym for a CA implementation.

• Registration Authority (RA): accepts requests for digital certificates and authenticating the entity making the request; does NOT sign or issue certificates.
• Certificate Authority (CA): issuess certificates and publish the public keys associated with individuals' private keys.
  • When a certificate is signed by a trusted CA, the certificate user can be confident that the certificate owner or hostname/domain has been validated, while self-signed certificates can be trusted to a lesser extent as the owner doesn't go through any additional validation before issuance.
• Validation Authority (VA): verifies the validity of a digital certificate. Does NOT issue or revoke certificates; it get updates from CA.
• Central directory: a secure location in which keys are stored and indexed.

ACME

Let's Encrypt uses the Automatic Certificate Management Environment (ACME) protocol which is why the configuration is under a key called acme.