PKI and certificates: how a public key gets a name

The problem: anyone can make a key and claim a name

In Article 1, Ibrahima verified Mariama’s signature on a loan contract with her public key. The check proved something precise: whoever holds the matching private key signed those exact bytes.

It did not prove that the holder was Mariama. The public key came attached to an email, and anyone can generate a key pair, write “Mariama Diallo” in a message and send it along. FIPS 186-5 names the risk: without assurance that the signer owns the key pair, “the problem of forging a signature is reduced to the problem of falsely claiming an identity”. It also names the fix: that assurance “can only be provided if the owner’s identity and public key are bound together, such as in a certificate issued from a public key infrastructure” (FIPS 186-5, §3).

This article is about that binding: what a certificate contains, who issues it, how Mariama asks for one, and how Ibrahima checks it.

What a certificate is

Someone relying on a public key needs confidence that the matching private key belongs to the right subject, a person or a system. RFC 5280, the Internet profile of X.509, provides it with certificates: data structures that bind a public key to a subject. A trusted certification authority (CA) asserts the binding by digitally signing each certificate (RFC 5280, §3.1).

This is Article 1’s sign-and-verify applied to a new kind of document. “By generating this signature, a CA certifies the validity of the information in the tbsCertificate field. In particular, the CA certifies the binding between the public key material and the subject of the certificate” (§4.1.1.3).

Two consequences follow. First, a certificate protects itself: anyone with the CA’s public key can check its signature and dates, so it can travel over untrusted channels (§3.1). Mariama can email hers.

Second, a certificate is only as good as the checks the CA made before signing, and RFC 5280 does not fix what those are. The CA may rely on a technical proof that the subject holds the private key, on presentation of the private key, or simply on the subject’s own assertion (§3.1). So RFC 5280 tells relying parties to “review the certificate policy generated by the certification authority (CA) before relying on the authentication or non-repudiation services”, and says it “does not prescribe legally binding rules or duties” (§2).

Inside an X.509 certificate

X.509 is an ITU-T and ISO standard first published in 1988; version 3, from 1996, added extensions (§3.1). A certificate is three fields: the contents to be signed (tbsCertificate), the CA’s signatureAlgorithm, which must match the identifier repeated inside the contents, and the signatureValue, computed over the DER encoding of the contents (§4.1, §4.1.1). The contents hold what a verifier reads:

A name can also sit in the subjectAltName extension. New certificates must put email addresses there; an email attribute in the DN is “deprecated but permitted” (§4.1.2.6).

Extensions: what the key may do

Each extension is critical or not. A system must reject a certificate carrying a critical extension it does not recognise or cannot process (§4.2).

Key usage is a set of bits naming the key’s purposes, among them digitalSignature, nonRepudiation, keyEncipherment, keyCertSign and cRLSign (§4.2.1.3). digitalSignature covers signatures other than on certificates and CRLs. nonRepudiation is set when the key verifies signatures in a service that protects against the signer falsely denying an action; RFC 5280 notes that recent X.509 editions renamed it contentCommitment, and leaves finer distinctions between the two bits to certificate policies. keyCertSign is for keys that verify other certificates, and requires the certificate to be marked as a CA.

Basic constraints says whether the subject is a CA. If the cA flag is absent, the key must not be used to verify certificate signatures. An optional path length constraint limits how many intermediate CAs may follow; zero means only end-entity certificates (§4.2.1.9).

Key identifiers help software find the right issuer certificate. The subject key identifier is usually a hash of the public key; the authority key identifier points at the issuer’s key (§4.2.1.1, §4.2.1.2).

Certificate policies carry identifiers that, in an end-entity certificate, “indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used” (§4.2.1.4). This is where a relying party learns how the CA checked the subject. Article 4 covers the policy documents themselves.

Extended key usage can add or narrow purposes. When both it and key usage are present, the certificate may only be used for a purpose consistent with both (§4.2.1.12).

Who does what in a PKI

RFC 5280 describes a PKI through a few roles (§3): the end entity, the subject of a certificate (Mariama); the CA, which issues certificates and is responsible for their revocation status; the registration authority (RA), an optional system to which a CA delegates some management functions; the CRL issuer; and the repository that stores certificates and CRLs.

Three functions connect them (§3.5). Registration is “the process whereby a user first makes itself known to a CA (directly, or through an RA), prior to that CA issuing a certificate”. Initialization gives the client the trusted CA’s public key, and usually its own key pair. Certification is the CA issuing the certificate and returning it, publishing it in a repository, or both. None of these has to happen online, and they can be combined into one exchange.

Enrollment: the CSR and proof of possession

Mariama asks for a certificate with a certificate signing request (CSR), defined by PKCS #10. She assembles her distinguished name, her public key and optional attributes, signs their DER encoding with her private key, and packages the two together (RFC 2986, §3, §4.1, §4.2). The request carries the public key, never the private key. It has no issuer name, serial number or validity period: the CA chooses those (§3, Note 4).

Why sign a request? The signature “prevents an entity from requesting a certificate with another party’s public key” (§3, Note 2). Without it, an attacker could copy Mariama’s public key, put their own name on a request, and get a certificate claiming her key as theirs. RFC 4211 calls the general idea proof of possession (POP): the requester shows it can use the private key matching the public key in the request, so the CA or RA can check the binding between subject and key pair (RFC 4211, §4). The CSR’s signature is one way to provide it.

POP is not identity. PKCS #10 describes the CA’s work as two steps: it fulfils the request “by authenticating the requesting entity and verifying the entity’s signature” (RFC 2986, §3). The signature shows the requester holds the key. Checking that this really is Mariama is a separate job, done as the CA’s policy says; RFC 4211 likewise leaves the POP method to local policy and lets the RA, the CA or both perform the check (§4). How the request travels is out of scope for PKCS #10: “Both paper and electronic forms are possible” (§3, Note 3).

Chains and trust anchors

Ibrahima’s software cannot hold every CA’s public key. It starts from a few CA keys it trusts and builds a chain down to Mariama’s certificate. RFC 5280 calls the chain a certification path: the end entity’s certificate plus zero or more CA certificates (§3.2).

End-entity certificates go to subjects that may not issue certificates. CA certificates include self-signed ones, whose signature verifies with the public key they contain, and these convey the public key that begins a path (§3.2). That starting key is the trust anchor. Valid paths begin with certificates issued by a trust anchor, and choosing one is a matter of policy (§6.1). The anchor is trusted because it reached the verifier by a trustworthy out-of-band procedure (§6.1.1(d)), not because of its signature: a self-signed certificate’s signature “proves that the issuer possesses both the public and private keys” (§4.2.1.1), and nothing about who that issuer is. When the anchor is given as a self-signed certificate, it is not part of the path being validated (§6.1). A server’s own self-signed certificate, made by an entity that is not a CA, is outside RFC 5280’s scope (RFC 6818, §2).

Validation works down from the anchor (§6.1.3, §6.1.4). For each certificate, the verifier checks that its signature verifies with the key above it, that the current time is within its validity period, that it is not revoked, and that its issuer matches the subject above. For each intermediate CA it also checks that basic constraints marks it as a CA, that no path length limit is exceeded, and that keyCertSign is set if key usage is present. RFC 5280 specifies only validation; how software finds the certificates to build the path is out of its scope (§6.1).

Mariama enrolls, Ibrahima checks

Back to the loan contract, now with a generic PKI like the one in the hands-on below.

1. Mariama generates a P-256 key pair and builds a CSR with her name and public key, signed with her private key.
2. She registers with the RA and sends the CSR. The RA checks her identity as the CA’s policy requires, and verifies the CSR’s signature.
3. The issuing CA sets the issuer, serial, validity and extensions (CA:FALSE, key usage digitalSignature and nonRepudiation), signs the certificate and returns it.
4. Mariama signs the contract as in Article 1, and sends the contract, the signature, her certificate and the issuing CA’s certificate.
5. Ibrahima’s trust store already holds the root. His software builds the path root → issuing CA → Mariama, checks each signature, date and constraint, then verifies the contract’s signature with the public key from her certificate.

If Ibrahima trusted only a stranger’s root, step 5 would fail: no path leads from that anchor to Mariama’s certificate. A root certificate forwarded inside the message would not help either. The trust anchor is his choice, not the sender’s.

Try it: a toy PKI with OpenSSL

The script builds a root CA and an issuing CA, creates Mariama’s key and CSR, issues her a signing certificate, and verifies it against the right root and then an unrelated one. It runs in a throwaway container and writes nothing to your machine. Never reuse these keys or certificates.

Executable educational example · Docker · alpine:3.22 · OpenSSL 3.5.8 25 Aug 2026

docker run --rm -w /w alpine:3.22 sh -c '
apk add --no-cache openssl >/dev/null && openssl version &&
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key &&
openssl req -x509 -new -key root.key -sha256 -days 3650 \
  -subj "/C=GN/O=Demo PKI/CN=Demo Root CA" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -out root.pem &&
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out issuing.key &&
openssl req -new -key issuing.key \
  -subj "/C=GN/O=Demo PKI/CN=Demo Issuing CA" \
  -out issuing.csr &&
printf "basicConstraints=critical,CA:TRUE,pathlen:0\nkeyUsage=critical,keyCertSign,cRLSign\n" > issuing_ext.cnf &&
openssl x509 -req -in issuing.csr -CA root.pem -CAkey root.key -CAcreateserial \
  -days 1825 -sha256 -extfile issuing_ext.cnf -out issuing.pem &&
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out mariama.key &&
openssl req -new -key mariama.key \
  -subj "/C=GN/CN=Mariama Diallo" \
  -out mariama.csr &&
printf "basicConstraints=critical,CA:FALSE\nkeyUsage=critical,digitalSignature,nonRepudiation\n" > mariama_ext.cnf &&
openssl x509 -req -in mariama.csr -CA issuing.pem -CAkey issuing.key -CAcreateserial \
  -days 365 -sha256 -extfile mariama_ext.cnf -out mariama.pem &&
echo "--- verify: root + issuing chain ---" &&
openssl verify -CAfile root.pem -untrusted issuing.pem mariama.pem &&
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out stranger.key &&
openssl req -x509 -new -key stranger.key -sha256 -days 3650 \
  -subj "/C=GN/O=Acme Corp/CN=Acme Corp Root CA" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -out stranger-root.pem &&
echo "--- verify: strangers unrelated root (expect failure) ---";
openssl verify -CAfile stranger-root.pem -untrusted issuing.pem mariama.pem; echo "exit=$?";
echo "--- Mariama certificate, decoded ---";
openssl x509 -in mariama.pem -text -noout'

• openssl req -x509 makes the root’s self-signed certificate; -addext sets its extensions and -days overrides the 30-day default. openssl req -new makes a PKCS #10 CSR from an existing key (openssl-req).
• openssl x509 -req -CA … -CAkey … acts as a “micro CA”: it takes the CA certificate’s subject as the new issuer and signs with the CA key. -CAcreateserial starts a random serial number. Extensions requested in a CSR are not copied by default; they come from -extfile, so the CA, not the requester, decides that Mariama’s certificate is CA:FALSE (openssl-x509). OpenSSL still spells the bit nonRepudiation (x509v3_config).
• openssl verify -CAfile root.pem loads the root as a trusted certificate. -untrusted issuing.pem supplies the intermediate for chain building without trusting it. OpenSSL itself ships no default set of trust anchors, but many Linux distributions configure one (openssl-verification-options). The bare container here has none.

OpenSSL 3.5.8 25 Aug 2026 (Library: OpenSSL 3.5.8 25 Aug 2026)
Certificate request self-signature ok
subject=C=GN, O=Demo PKI, CN=Demo Issuing CA
Certificate request self-signature ok
subject=C=GN, CN=Mariama Diallo
--- verify: root + issuing chain ---
mariama.pem: OK
--- verify: strangers unrelated root (expect failure) ---
C=GN, O=Demo PKI, CN=Demo Issuing CA
error 20 at 1 depth lookup: unable to get local issuer certificate
error mariama.pem: verification failed
exit=2
--- Mariama certificate, decoded ---
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            64:42:dd:13:40:18:75:59:8c:e8:82:db:bc:7f:b6:73:22:77:c4:0b
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=GN, O=Demo PKI, CN=Demo Issuing CA
        Validity
            Not Before: Sep 23 08:32:24 2026 GMT
            Not After : Sep 23 08:32:24 2027 GMT
        Subject: C=GN, CN=Mariama Diallo
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:7b:44:39:62:a6:95:25:c7:04:ac:59:3a:ca:87:
                    52:5f:cf:40:d4:1a:1b:16:f4:a6:f5:63:e7:4a:1a:
                    93:58:72:38:cd:7d:15:33:01:ad:6d:39:0d:1d:1c:
                    6d:db:2e:d6:a6:47:bd:69:3e:ab:86:cb:cf:60:a6:
                    1d:13:2f:9b:56
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation
            X509v3 Subject Key Identifier:
                3A:44:B3:81:0E:C9:B2:60:78:C5:91:42:0D:30:68:01:C3:47:9B:57
            X509v3 Authority Key Identifier:
                29:B0:17:79:A7:33:74:A1:CA:2E:4D:1A:CB:1A:BC:40:6F:9A:10:C6
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:46:02:21:00:cf:c5:b2:b6:ab:e3:e7:c2:ea:89:ff:be:c3:
        c5:04:78:cc:03:d4:5a:9f:ec:73:3d:d9:3c:2d:3b:ae:63:f4:
        a1:02:21:00:87:e1:f7:74:77:e0:0c:c1:ef:7d:c4:22:ea:b2:
        1b:d5:6a:93:3a:a8:ee:8f:86:69:6e:44:3f:89:06:c6:8b:f0

The two “Certificate request self-signature ok” lines are openssl x509 -req checking each CSR’s signature before issuing, the tool’s proof-of-possession check. mariama.pem: OK means OpenSSL built a path to the trusted root and every signature and date checked out.

Against the stranger’s root, the error reads error N at D depth lookup (openssl-verify). Depth 0 is Mariama’s certificate; depth 1 is the issuing CA, printed on the line above. Error 20, “unable to get local issuer certificate”, occurs when the issuer of an untrusted certificate cannot be found (openssl-verification-options). The exit status is 2, which a script can test. In the decoded certificate, basic constraints is CA:FALSE and key usage is Digital Signature and Non Repudiation, both critical. The key identifiers were not requested: OpenSSL adds them by default (x509v3_config).

Every run generates new keys, -CAcreateserial picks a random serial, the dates follow the clock, and ECDSA uses a fresh random number per signature, so the serial number, dates, public key, key identifiers and signature value will differ on your machine. The chain logic does not change. alpine:3.22 tracks the latest 3.22.x build, so the OpenSSL version line depends on the Alpine package repository at install time. If Docker has to download the image first, its progress lines appear before this output.

OTP ≠ legal identity

Many signing flows send a one-time code (OTP) by SMS and ask the signer to type it in. It is tempting to treat that code as the signer’s identity. The standards and the law say otherwise.

NIST separates two things. Identity proofing is “the processes used to collect, validate, and verify information about a subject to establish assurance in the subject’s claimed identity” (SP 800-63-4, Appendix B). Authentication “demonstrates that the claimant has possession and control of one or more valid authenticators that are bound to the subscriber’s identity” (§2.3.2), a binding made earlier, at proofing and enrollment (§2.2).

A code sent by SMS or voice call is, in NIST’s terms, an out-of-band authenticator: it “establishes the claimant’s control of the out-of-band device” and is not phishing-resistant (SP 800-63B-4, §3.1.3). NIST reserves “OTP” for codes generated by a device holding a secret seed, though everyday usage calls both OTP. Codes over the phone network are a restricted option, and verifiers should weigh risks such as “device swap, SIM change, number porting” (§3.1.3.3).

So a correct code shows that someone controlled a phone number or device at that moment. It says who the person is only if earlier proofing tied that number to a verified identity, and even then it binds no public key to anyone.

Guinean law, L/2016/035/AN art. 34, speaks to this in several paragraphs (art. 34). Its fifth paragraph ties handwritten-equivalent value to a secure signature and a qualified certificate: « La signature électronique sécurisée liée à un certificat électronique qualifié, a la même force ou valeur probante que la signature est [sic] manuscrite. » Another paragraph presumes the reliability of a process that uses a secure signature and a qualified certificate. The first paragraph also uses handwritten-signature wording, under different conditions: a reliable, secure device under the signatory’s exclusive control, and a « certificat numérique ». How these paragraphs relate is open, and a question for a Guinean lawyer. A fourth paragraph protects signatures from outright refusal: « Une signature électronique ne peut être déclarée irrecevable au seul motif : qu’elle se présente sous forme électronique ; ou qu’elle ne repose pas sur un certificat qualifié ; ou qu’elle n’est pas créée par un mécanisme sécurisé de création de signature électronique. » In our translation: a signature may not be declared inadmissible solely because it is electronic, lacks a qualified certificate, or was not made with a secure creation mechanism. The conditions for « sécurisée » are left to a presidential decree, and the law does not mention OTPs, one-time codes or SMS.

Our reading, which is not legal advice: both paragraphs with handwritten-signature wording name a certificate among their conditions, and a certificate is a CA’s signed binding of a public key to a subject. An OTP is not a certificate, and both paragraphs name one among their conditions; whether a given OTP flow meets either is a question for a Guinean lawyer. Art. 34 still forbids refusing a signature solely for being electronic or for lacking a qualified certificate. To decide how much identity checking a document needs, see how much proof your document needs. Article 5 shows how to bind a code to one transaction, and Article 8 covers identity and the law in depth.

Where SEDEYA fits

A PAdES signature carries the certificate chain a verifier needs for the path validation above. SEDEYA signs PDFs in PAdES up to the B-LTA level, with RFC 3161 timestamps and the validation data embedded in the file. Ibrahima does not have to assemble chains with OpenSSL: he can upload the signed PDF to SEDEYA’s public verification page, or scan the QR code printed on it, and the page runs the checks. Later articles in this series cover the keys behind that signature and how long it stays verifiable.

Risks and misconceptions

Summary

• A public key alone says nothing about who holds it. A certificate binds it to a subject, and a CA asserts the binding with its signature.
• An X.509 certificate names its issuer, serial, validity, subject and public key; extensions such as key usage and basic constraints limit the key.
• A CSR’s signature is proof of possession, not proof of identity. The CA or RA authenticates the requester separately, by its policy.
• A verifier builds a path from a trust anchor it already holds down to the signer, checking every signature, date, name and constraint.
• In the hands-on, Mariama’s certificate verified against its own root and failed against an unrelated one with error 20.
• A one-time code shows control of a device. It is not a certificate, and art. 34 names a certificate among the conditions of both paragraphs that use handwritten-signature wording.

Check your understanding

Next step

A certificate binds Mariama’s name to her public key, but says nothing about where her private key lives or who can use it. Article 3 covers signing keys, hardware security modules and PKCS#11. In the meantime, talk to us and we will show you how a document signed with SEDEYA carries its certificate chain, and how anyone can verify it.