What Every Field in a TLS Certificate Means

Web browsing happens to be a normal part of life in most communities these days. And finding yourself getting a certificate error when you are going about your normal online business is an unpleasant surprise.

Worst? Losing trust. When that browser warning flashes, the one you got to know from some other browser sessions, you know your trust in whatever website you are visiting is at stake now. And you will need to know how to get to the root of the certificate error. And you have come to the right place.

Digging inside the TLS Certificate

In this article, we will go over the following key areas to help you diagnose the browser warning:

1. The certificate chain and issuer
2. The Subject Alternative Name field
3. The Certificate’s permitted use as indicated by keyUsage and extendedKeyUsage
4. The certificate’s validity period

First, let’s look at the certificate details section.

After a reinstall of both the agent software and the certificate in question, the network log shows the output of the certificate appears in the browser’s certificate viewer:

The hostname for the session is already shown: notebookdomain.local

Under “Details” in the certificate viewer, you may see:

Certificate hierarchy
Root: DNS: localhost
Intermediate: QuickSSL
Underlying certificate: notebookdomain.local

A "self-signed" certificate means that there is no intermediate link from a trusted authority in the chain of trust.

However, many browsers will display a warning for a self-signed certificate, saying the certificate issuer is not trusted. This is because.

The name in the subject indicates the certificate's own identity, such as the server name or organization name. This name appears in the certificate's viewer as:

Subject: CN=localhost

The issuer name is the name of the CA or entity who issued the certificate. When a certificate is self-signed, this field will be set to the same value as the subject name unless -set_issuer is given, as in the certificate above.

In this case, the certificate viewer shows:

Issuer: CN=localhost

Finding an issuer name that you do not recognize or that fails domain validation can trigger browser warnings for an untrusted issuer or wrong site name.

What’s in a Name?

Which names actually identify the server? While the Common Name field commonly used the old Subject name for this, today’s certificate viewers rely more on the Subject Alternative Name (SAN) field to carry this information.

SAN is a multi-valued extension that can carry DNS, IP, URI, email, RID, dirName, and otherName entries. In command line usage, SAN appears in the certificate file like this:

CN = localhost
subjectAltName=DNS:localhost, IP:127.0.0.1

This certificate is valid for localhost, and if you tried to access it from another name or IP, the browser would warn you of a name mismatch.

When the email option is used in SAN, it has special copy and move values, and copy can include email addresses from the subject name automatically.

You can extract SAN from a certificate with this command:

openssl x509 -in certificate.crt -noout -ext subjectAltName

This command will list the alternative names that SAN carry in the certificate. There should be a match between one of the names here and the name you entered in the browser for the session.

Not matching a SAN entry is another common cause of browser domain validation failure.

What the Certificate is Allowed to Do

The keyUsage and extendedKeyUsage fields indicate the permitted uses of the certificate. These fields are often overlooked, but browsers do take them into account. For example, Firefox can reject a certificate as a CA certificate used as an end-entity certificate, producing MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY.

An OpenSSL example shows keyUsage values including digitalSignature, keyEncipherment, and keyCertSign, and extendedKeyUsage set to serverAuth. The same certificate populates the subjectAltName with DNS names.

openssl req -new -x509 -key mykey.key -out mycert.pem -days 365 -sha256 -subj "/C=EU/ST=City/OU=Div/emailAddress=test-request@example-org/CN=www.example.com" -reqexts SAN -extensions SAN

keyUsage is used to indicate the purpose of the public key in a certificate. Key usage values include:

-

• digitalSignature: Digital signatures
• nonRepudiation: Non-repudiation
• keyEncipherment: Key transport
• dataEncipherment: Digital envelope
• keyAgreement: Key agreement
• certificateSign: Certificate signatures
• cRLSign: Certificate revocation (crlSign)

While keyUsage commonly appears on all certificates, extendedKeyUsage restricts the certificate’s use further to specific applications and protocols. It is not a required field, so it may be empty, but the certificate may enforce specific purposes.

Values can include:

• serverAuth: TLS Web Server Authentication
• clientAuth: TLS Web Client Authentication
• Any of the OIDs listed in PKIX
• And any end-entity application-specific OID that can be safely thought of as a synonym for the Certificate Policies extension

If the key usage does not match the server’s purpose, some browsers will show a warning.

Certificate Validity

Other entries that show in the Certificate’s details appear under "Valid From" and "Valid To", which are the "notBefore" and "notAfter" fields. These fields define the window of use for the certificate.

If the current date falls outside this window, the certificate is invalid. Today, almost all certificates use a 2038 bug workaround, which validates the notBefore and notAfter times as a 64-bit integer, rather than being treated as a date in an ANSI C struct.

Finally, the certificate viewer shows some chain of trust entries, OCSP status, and CT status. However, these fields require more detailed coverage that we may expand on in a future article once the primary-source information is verified.

Which fields cause the browser warnings?

• An untrusted issuer or intermediate
• A domain name that does not match a SAN entry
• A key usage or extendedKeyUsage that does not permit server authentication
• A date outside the cert's notBefore to notAfter validity window
• OCSP and CT status that indicates a certificate problem

By consulting these fields, you can drill down on a browser security message. The browser warning maps to the offending certificate field, and from there, you can decide whether you need to install an intermediate, re-issue a certificate that includes a proper name, or adjust the infrastructure settings.

Sources

• Baeldung article citing openssl x509 usage — baeldung.com