For full text search please use the '?' prefix. e.g. ? Onboarding

TLS Certificates

Server certificate

In order to establish a secure connection between client and server, the server must provide a digital certificate, proving their identity to the client.

The client then conducts certification path validation, ensuring that:

  1. The subject of the certificate matches the host name (not to be confused with the domain name) to which the client is trying to connect.
  2. A trusted certificate authority has signed the certificate.
  • the certificate path starts with the Subject certificate, and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted certificate authority (CA).

Once the client has validated successfully, a secure connection is established between it and the server.

The certificate has a Subject field which identifies the primary host name of the server as the Common Name

  • a certificate may specify more than one hostname (e.g. a domain and its subdomains), which are called Subject Alternative Name (SAN) certificates, which contain a Subject Alternative Name field

Client Certificate

Client certificates authenticate the client connecting to a TLS service.

  • ex. To connect to Zscaler VPN, we must have a certificate issued by Zscaler in our filesystem.

ex. Zscaler?

Certificate chain

A certificate chain is an ordered list of certificates, containing an SSL/TLS server certificate, intermediate certificate, and Certificate Authority.

  • There are 1 or more intermediate certificates, and act as middlemen between the protected root certificates and the server certificates issued out to the public.

When we install the TLS certificate, we will also be sent an intermediate root certificate.

When a browser downloads our website’s TLS certificate upon arriving at our homepage, it begins chaining that certificate through the intermediate certificates, all the way back to the trusted root certificate.

  • if it can't be chained back to a trusted root, the browser will issue a warning about the certificate.

To view the certificate chain for google.com, run:

openssl s_client -connect google.com:443 -servername google.com

Example output:

0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

Understanding the output:

  • the numbered lines are:
    • 0: server certificate
    • 1: intermediate
    • 2: root
  • s: indicates the certificate subject
  • i: indicates the issuing certificate’s subject.

The certificate chain is valid if:

  • Subject of each certificate matches the Issuer of the preceding certificate in the chain (except for the server certificate).
  • Subject and Issuer are the same for the root certificate.

In other words:

  • The Subject of the intermediate certificate matches the Issuer of the server certificate.
  • The Subject of the root certificate matches the Issuer of the intermediate certificate.
  • The Subject and Issuer are the same in the root certificate.

Self-signed Certificate

A self-signed certificate refers to a certificate that is created and signed by the same (server) entity whose identity it certifies

  • ex. we create a certificate from our Synology NAS, and it is also the same NAS that certifies the machine's identity.

Self-signed certificates are signed with the private key generated by the entity

Because self-signed certificates are not issued by third-party certificate authorities, they provide less proof of the identity of the server and are usually only used to secure channels between the server and a group of known users.

  • therefore a "self-signed certificate in certificate chain" error arises because the client doesn't trust the authenticity of the server, due to the fact that there is no certificate chain that leads back to a root trusted CA.

Using self-signed certificates have a much different impact depending on the environment. If we are talking about self-signed certificates in the context of your application server trying to connect to your managed database, then self-signed certificates are much more acceptable, since we generally trust the certificates issued by organizations such as DigitalOcean.

  • this is especially true if you're connecting over a private or trusted network (such as having an application server on the same VPC as your managed database).
  • contrast this with public-facing websites accessed by browsers. In this context, self-signed certificates are not considered secure because anyone could generate one. Without trust from a publicly recognized CA, browsers can't be sure that the server they're communicating with is legitimate. This is why browsers will warn users about self-signed certificates with messages like "This connection is not private."

Server Certificate

Used to authenticate the identity of a server to the client that is trying to connect to it.

  • this is the certificate that is issued to the specific domain the user is needing coverage for

When a server certificate gets installed on a website, HTTPS gets enabled, and the certificate chain gets created, the result of which vouches for the authenticity of the website.

  • When we hop on to our computers and type in a website URL, the server certificate ensures that the data flow between our client browser and the domain we’re trying to reach stays secure

Also known as SSL/TLS certificates

Based on PKI

Client Certificate

Used to validate the identity of a client.

  • In this way, it serves as a password, as in theory, no one should be able to produce that certificate but the true client.
  • Client certs don't encrypt any data.

Client certificates exist because passwords aren't that secure.

Client certificates use the Public Key Infrastructure (PKI) for authentication (just as server certificates do).

  • Difference is that client certificates don't encrypt any data; they are just for validation purposes.

Contain "Issued to" and "Issued by" fields

Based on PKI

Children
  1. CA (Certificate Authority)
Backlinks