What is a x.509 certificate?

What is an X.509 certificate

It is a small data file, usually under two kilobytes, in a format called ASN.1 and normally saved as .cer, .crt, .pem or .der. Anyone may read it. It carries no secrets: the matching private key is kept elsewhere.

The certificate is signed by the issuer. If a single character of the name is changed, the issuer’s signature no longer matches and the certificate is rejected. That makes it tamper-evident.

X.509 certificate fields

A version 3 certificate, the version in use today, has these main fields:

• Version: 3 for modern certificates.
• Serial number: unique for each certificate from one issuer. Revocation lists use it.
• Signature algorithm: how the issuer signed, for example RSA with SHA-256.
• Issuer: the name of the certifying authority.
• Validity: a start and end date and time.
• Subject: who the certificate is for.
• Subject public key info: the public key and its algorithm.
• Extensions: optional fields that add rules, described below.
• The issuer’s signature over all of the above.

Extensions in version 3

Version 3 added extensions, which is where most of the practical rules sit:

• Key usage: whether the key may sign documents, encrypt data or sign other certificates.
• Basic constraints: whether this is a CA certificate and how long a chain below it may be.
• Subject alternative name: extra names, such as website domains or an email address.
• CRL distribution points: where to download the revocation list.
• Authority information access: where to find the issuer certificate and the OCSP service.

How a certificate is trusted

A certificate is trusted because its issuer is trusted. The issuer’s own certificate is signed by a higher authority, up to a root certificate that the software already knows. This is the chain of trust. A checker walks up the chain, confirms each signature and each date, then checks that none has been revoked.

X.509 vs PGP and other formats

X.509 uses a hierarchy: authorities vouch for people. PGP uses a web of trust, where people vouch for each other, and has no central authority. Legal digital signatures in Nepal rely on PKI and licensed authorities, so X.509 is the format that applies. Other formats exist for special uses, such as attribute certificates, but the identity certificate is the common one.

How to read an X.509 certificate

In a PDF reader, open the signature panel and choose to view the certificate. It shows the subject, issuer and dates. On a computer with OpenSSL, the command openssl x509 -in file.cer -text -noout prints every field. For a step-by-step on checking a signed document, see how to check a signed PDF.

Example: reading a signer’s certificate in a loan PDF

A bank officer opens a signed loan agreement and views the borrower’s certificate. The subject shows the borrower’s name. The issuer shows the licensed certifying authority. The validity field shows two dates, and the officer checks that the signing date falls between them. Key usage lists digital signature, which is the permission needed for signing documents. The signature algorithm line shows which hash and key type the authority used.

None of those fields says the borrower is trustworthy as a borrower. They say an authority checked the borrower’s identity and tied it to this key. The decision to lend remains the bank’s.

File formats and encoding

Behind the fields, a certificate is a structure written in ASN.1 and encoded in a binary form called DER. The same bytes can be wrapped in text as PEM, which is the version with lines starting BEGIN CERTIFICATE that you can paste into an email. The file extensions follow habit more than rule: .cer and .crt usually hold one certificate, .pem is text, and .p12 or .pfx packs a certificate with its private key under a password.

This matters when a counterparty asks you to send your certificate. Send only the certificate file, never the .p12 or .pfx bundle, because the bundle contains your private key. If someone asks for it, the request is either a mistake or an attack.

Common problems with certificates

Four faults cause most failures. The certificate has expired. The signer’s software did not include the intermediate certificate, so the chain cannot be built. The certificate’s key usage does not allow the action, for example a website certificate used to sign a contract. Or the reader does not trust the issuing root.

Each fault shows a different error, and each has a different fix: renew, add the intermediate, get the right kind of certificate, or update the reader. Reading the error against the fields above usually points to the cause within a minute.

Why version 3 and what came before

Version 1 certificates had only the basic fields and no way to say what the key was for. Version 2 added unique identifiers that were rarely used. Version 3 added extensions, and with them rules such as key usage and basic constraints, which stop a signing certificate from being misused to issue other certificates. Almost every certificate in use today is version 3.

Certificate revocation lists have their own versions, with version 2 being current. RFC 5280 profiles both for internet use, which is why that number comes up in nearly every discussion of certificates.