How digital certificates bind identities to public keys, how trust chains work, and what signatures can verify.
What is a digital certificate?
A digital certificate is a signed electronic record that binds a public key to an identity, such as a website name, a person or an organisation. The issuer signs that binding so others can check it.
Suppose a website gives your browser a public key. Anyone could generate a key and claim it belongs to that website. A certificate helps your browser decide whether to accept the claim.
The common format used for website certificates is X.509. Here, “certificate” means a public-key certificate. A school qualification stored as a PDF or on an NFC tag is a different kind of record, although digital signatures can protect both.
What does it contain?
- Subject and names: who or what the certificate identifies. Website names are normally listed in the Subject Alternative Name extension.
- Public key: the key being certified, together with information about its algorithm.
- Issuer and serial number: who issued the certificate and its identifier within that issuer's records.
- Validity period: the dates between which it may be accepted, subject to the other checks.
- Permitted uses: extensions can restrict whether the key may authenticate a server, sign certificates or serve another purpose.
- Signature: the issuer's signature over the certificate's signed fields.
A certificate contains the public key. Its matching private key must stay secret and is not part of the certificate.
How is it trusted?
A certificate authority, or CA, checks a request according to its issuance policy and signs a certificate. For a domain-validated website certificate, the check concerns control of the domain; it does not establish that the business is honest.
Your browser starts with trusted root authorities. A website usually supplies its own certificate and intermediate certificates, allowing the browser to build a chain back to a trusted root.
A root is trusted because the browser or system has accepted it as a trust anchor. Its self-signature alone does not make it trustworthy. A private organisation can also operate its own CA and distribute that trust explicitly.
What does verification check?
- The certificate's signatures and chain lead to an accepted trust anchor.
- The requested website name matches an allowed name in the certificate.
- The certificate is within its validity period and allowed for the intended use.
- The chain satisfies applicable constraints and the client's revocation policy.
The peer must also prove possession of the corresponding private key through the connection protocol. Copying a public certificate does not provide that proof.
Certificates can expire or be revoked, for example after a private key is exposed. Revocation information may be distributed through certificate revocation lists or online status services. Clients differ in how they obtain and enforce it.
How does this relate to encryption?
A certificate identifies a public key; it does not itself encrypt a conversation. In a typical certificate-based TLS 1.3 connection, certificates and signatures authenticate the server, key agreement establishes shared secrets, and symmetric authenticated encryption protects the traffic.
Encryption answers “who can read this?” A signature helps answer “was this signed with the expected private key, and has it changed?” A certificate helps answer “whose public key should I use?”
Can it verify a qualification on an NFC tag?
Imagine a board issuing a student's qualification. It signs an agreed representation of the qualification details, including an identifier. A verifier reads the details and signature from the tag and checks them using the board's trusted public key. A public-key certificate can help establish which key belongs to the board.
The signature can be checked offline if the verifier already has the required keys, certificates and trust information. Offline checking cannot by itself reveal a newly revoked certificate or a recently withdrawn qualification.
A plain hash stored beside the details is insufficient: someone could replace both. A digital signature resists that substitution without requiring every verifier to hold the board's private key.
In a hash-and-sign scheme, the board computes a digest of the exact qualification data and signs that digest with its private key. The verifier computes a fresh digest from the received qualification and checks it with the signature and the board's public key.
Imagine an attached fingerprint slip: the fingerprint represents the hash, and the issuer's signature authenticates it. Changing the qualification changes its fingerprint, so the original signature fails verification. Merely replacing the hash does not help an attacker who cannot produce a valid new signature.
For the RSA PKCS#1 v1.5 example, the verifier uses the public key to recover the signed digest and compares it with a fresh hash of the received qualification. They must match exactly. A public-key certificate lets the verifier check whose verification key it is using. See RFC 8017, section 8.2.2.
Signing does not hide the student's details. It also does not prevent copying the whole record to another tag. Preventing cloning or proving that the bearer is the named student requires additional measures.
What does a valid certificate prove?
A valid certificate supports a particular identity-to-key binding under a particular trust policy. It does not guarantee that a website is safe, that signed statements are true, or that a private key has never been stolen.
For the field layout, see certificate structure.
References
The NFC example is adapted from my earlier document-authentication design notes; it illustrates the distinction between authenticating a record and preventing its copying.
Ai disclosure: written with the help of AI (ChatGPT). You are encouraged to point out errors and omissions.
