Read your tenant's TLS certificate field by field

Setup

Every value in this lab comes from the certificate your Lab Photos host actually presents. Nothing in the tenant changes. You need openssl 3.x.

1. Work in a folder for the certificate labs and set the host:

mkdir -p ~/btl-pki-lab && cd ~/btl-pki-lab
ISSUER=https://tenant-<id>.beyondthelogin.dev
HOST=${ISSUER#https://}

Walkthrough

1. A key needs a name. Fetch and save the certificate your tenant host sends, then decode it:

openssl s_client -connect "$HOST:443" -servername "$HOST" </dev/null 2>/dev/null | openssl x509 -outform PEM > tenant.pem
openssl x509 -in tenant.pem -noout -text | less

Why it matters: this is the signed statement the lesson describes: this public key belongs to this name, for these purposes, during this period, according to this issuer.

2. Inside the certificate, fill in a table from the output. For each field, write the question it answers.

Why it matters: the serial number lets the CA name this exact certificate later, for example when revoking it, and the last extensions point beyond the certificate to its issuer, its revocation list and its Certificate Transparency receipts.

3. Names. Read the subject alternative names and test them:

openssl x509 -in tenant.pem -noout -ext subjectAltName
openssl x509 -in tenant.pem -noout -checkhost "$HOST"
openssl x509 -in tenant.pem -noout -checkhost "a.$HOST"
openssl x509 -in tenant.pem -noout -checkhost "$HOST.evil.example"

Expected: your host matches, either exactly or through a wildcard, and the other two do not.

Why it matters: clients match the hostname against the SAN, not the common name. A wildcard covers exactly one label in its position, so it cannot cover a. in front of your host.

4. Permitted uses. Find Extended Key Usage, which shows TLS Web Server Authentication, and Basic Constraints, which shows CA:FALSE.

Why it matters: this certificate may identify a server. It may not sign software or other certificates.

5. One key, one purpose. Compare the certificate's public key with the keys your tenant publishes for tokens:

openssl x509 -in tenant.pem -noout -pubkey
curl -s "$ISSUER/oauth/jwks" | jq '.keys[] | {kid, kty, alg}'

Neither token key is the TLS key.

Why it matters: the TLS key proves the host during the connection; the key set signs tokens. Each key has a single purpose, as the Storing and using keys lab showed.

6. What the certificate does not say. Check whether the Subject has an organization (O=) at all. Write down three things this certificate does not tell you: who owns the tenant, whether the service is honest, and whether this is the site you meant to visit.

Why it matters: most web certificates are domain validated. A look-alike address can hold a perfectly valid certificate for its own name.

7. Certificates are public. Anyone can run step 1. Compute the fingerprint:

openssl x509 -in tenant.pem -noout -fingerprint -sha256

Why it matters: copying tenant.pem gives an attacker nothing. Impersonating the host needs the private key, which never leaves the server.

Break it

1. Fetch the certificate for beyondthelogin.dev the same way into site.pem, and run openssl x509 -in site.pem -noout -checkhost "$HOST". Depending on its SAN list it may not cover your tenant host: each certificate speaks only for the names it lists.

2. Run openssl x509 -in tenant.pem -noout -checkend 0, which reports whether the certificate is valid now, then -checkend 31536000, which almost certainly reports that it expires within a year.

Check your work

This lab reads a certificate and does not touch the tenant's services, so there are no tenant events to check. You should have:

• a completed field table with your tenant certificate's real values

• checkhost results: a match for your host, and no match for the other two names

• the certificate's SHA-256 fingerprint

Cleanup

1. Keep tenant.pem and the ~/btl-pki-lab folder for the next three labs. Delete site.pem.