DEV Community: PKI security

Make provenance travel with public-interest images: a C2PA handoff checklist for small teams

PKI security — Sat, 10 Oct 2026 00:40:46 +0000

A community organization photographs a local event. A volunteer edits the images, a colleague uploads them, and a partner republishes one with a new caption. By the time a reader asks where the photograph came from, nobody is sure which copy was approved.

This hypothetical handoff is ordinary enough to be easy to overlook. For public-interest information, a lost original or changed caption can make a correction much harder. Small teams need a process that survives a change of person, tool, and file.

C2PA helps with provenance; the handoff still needs people

C2PA can bind signed provenance records to an asset. Those records may describe creation, editing, and source materials. They provide evidence about the asset's history within the scope of what was recorded. They do not certify the truth of a caption, grant publication rights, or guarantee that all previous activity is known. See the official C2PA explainer.

The practical aim is to preserve both the useful technical evidence and the human context needed to interpret it.

Conceptual illustration with fictional scenes, not a real verification result. The recorded fields depend on the file and software.

Preserve the original: Keep the received file separate from the publication copy.
Carry the context: Pass on the source, caption, permissions and contact privately.
Check the delivered copy: Record the credential result for what the reader receives.
Plan corrections: Name an owner who can update the caption and notify recipients.

Keep four things distinguishable

Item	Why keep it separate?	Suggested handling
Received original	Later transforms may change the file and its readable provenance	Preserve it with appropriate access controls
Working and publication copies	The approved edit and the delivered file may differ	Give each version an identifier and record its role
Caption and source notes	Text outside the image is not automatically covered by image verification	Track the caption, source URL, and unresolved claims
Private coordination record	Contact details and sensitive context need not be public	Keep access restricted and assign a responsible person

This is a proposed operating checklist, not a standard mandated by C2PA. A file hash can help distinguish two exact byte sequences, but it does not prove a photograph's truth, authorship, or permission status.

At intake: ask what you actually received

Record who supplied the file to the team, where it was obtained, and which facts are confirmed or unknown. Do not fill in a missing capture time from memory. Keep the received caption beside the file, and mark any later caption revisions separately.

Clarify the intended publication and any restrictions with the relevant people. A record that can be verified cryptographically is not evidence that a person depicted agreed to every possible reuse.

During editing: preserve the chain you can explain

Work on a copy. Note the tool, version, and operations that matter for understanding the image. Where your supported workflow produces a new manifest for an edited asset, retain the relationship to its ingredients as intended by that workflow.

Do not add a new record to an old photograph and describe that as recovery of its complete past. A new record can describe the operation now performed; it cannot create trustworthy knowledge of earlier events that were never recorded. The implementation guidance is a starting point for planning supported edit and distribution workflows.

Avoid placing sensitive contact details into a record just because the software offers a field. C2PA's harms analysis explains why privacy and later rediscovery of earlier information need consideration before publication.

At delivery: check what a reader receives

An upload completing successfully is not evidence that the final delivered file has the same readable provenance as the original. A content management system, thumbnail service, or content delivery network may transform the image.

Have the reviewer obtain the actual delivered copy and note:

which URL and file were checked;
the verifier and version, including relevant trust configuration;
which recorded details were readable and which checks completed;
any errors or unknowns, without relabeling them as proof of false content;
whether the surrounding caption still matches the approved explanation.

This article reports no measured preservation rate and no completed tool comparison. Run and record these checks in your own environment before making a claim about your pipeline.

Make correction ownership part of the package

Before handing a file to a partner, decide who receives a correction request and who contacts downstream publishers. Keep a short version note that can be shared without exposing private sources. Replacing one copy on your own website does not recall copies held elsewhere.

A useful handoff ends with a statement such as: “This is the approved publication copy. The date in the caption remains unconfirmed. Contact the designated editor before reusing it as evidence of a current event.” It gives the next person something concrete to act on.

PKI Channel's implementation playbook in Japanese and image-sharing verification guide in Japanese provide further checklists for planning this work. The goal is not to attach a badge to every picture. It is to make the evidence, limits, and responsibility travel with the image.

AI was used for research assistance, writing and illustration.

Missing Content Credentials is not a guilty verdict: build a fair upload flow

PKI security — Sat, 10 Oct 2026 00:37:40 +0000

Imagine a neighborhood newsroom accepting photographs after a storm. One contributor uses a new camera with provenance support. Another sends a useful photograph from an older phone. A third avoids identifying metadata because publication could put someone at risk.

These are hypothetical contributors, not the results of an experiment. They illustrate a design problem: an upload form can turn a technical signal into an unfair judgment about a person.

Do not make the absence of Content Credentials a verdict that a photograph is false. C2PA's own harms analysis discusses the risk of treating content without credentials as untrustworthy. A fair flow needs a path for incomplete evidence.

What the credential contributes

C2PA specifies ways to bind provenance claims to a digital asset and sign those claims. Provenance may describe creation, editing, or source materials. A verifier can evaluate the binding, signature, and other applicable requirements. The result depends on what was recorded and on the verification environment.

This is useful evidence. It is not proof that the depicted event happened as described, that every earlier step was recorded, or that the uploader has permission to publish. The official explainer draws these boundaries.

Conceptual illustration with fictional scenes, not a real verification result. The recorded fields depend on the file and software.

Keep the submission: A missing credential does not prove that a photo is false.
Describe the result: Separate not found, invalid and unable to check.
Offer another route: Ask for context or a source without demanding public identity.
Review fairly: Record what is known and unknown before deciding.

Model the result before choosing a badge

For a beginner-friendly product, start with distinct states. The following labels are a proposed interface model, not C2PA API constants:

Product state	What to tell the contributor	What happens next
Not found	We did not find readable provenance in this copy	Keep the submission and offer another way to provide context
Invalid	Some verification checks did not pass	Record the specific finding and route for review
Unable to check	This check could not be completed	Explain the limitation and offer a retry or review
Checks completed	Show the supported findings and relevant recorded details	Continue the editorial checks appropriate to the submission

An invalid result is also not a complete explanation of what happened. A transformation, unsupported feature, changed asset, or other condition needs investigation in its actual context. Preserve the verifier's detailed result for an appropriately authorized reviewer; do not collapse every problem into “fake.”

Use plain text as well as any icon. A red shield or green check alone hides the scope of the assessment and is inaccessible to some readers. C2PA's UX guidance is useful when deciding how to reveal details without presenting provenance as a universal authenticity score.

Offer context without demanding public exposure

A contributor might provide an original file, the original publication URL, or an explanation of where the image came from. Make clear which fields are optional, who can read them, and what will become public.

Do not demand a public home address or precise location as the price of a fair review. An authorized editor may need a private follow-up channel, but that channel should not silently become part of a public image description. Collect information for a stated purpose, with the minimum access needed for that purpose.

Also keep “permission to publish” separate from “provenance verified.” A well-formed record does not stand in for a discussion about consent, licensing, or the safety of people depicted. Those checks depend on your organization and the use of the image.

Try the flow with three paper scenarios

Before implementation, walk through these cases with your team:

An older device produces an image with no supported credential. Can the contributor still submit it for review?
A supported image passes through a resizing service. If verification changes, can the editor inspect the received copy and the original separately?
A contributor declines to expose identifying metadata. Is there a private route for necessary follow-up, rather than an automatic public credibility penalty?

These are proposed review scenarios. No software, detector, or upload pipeline was tested for this article. They can help expose a flawed decision rule before you write code.

Give the reviewer an outcome other than guilty or innocent

A useful review note might read: “No readable credential was found in the submitted copy. The contributor supplied an original publication URL. The location claim remains unconfirmed.” That is more actionable than a single trust score.

Keep a route for corrections and contributor responses. Provenance can make a submission easier to investigate; it should not make people with older devices, limited resources, or safety concerns disappear from the process.

For further technical context, PKI Channel provides a C2PA overview in Japanese and a verification workflow in Japanese. Use them to plan the checks, then document the exact tools and policies used in your own deployment.

AI was used for research assistance, writing and illustration.

Your first HTTPS certificate renewal: issue, install, check

PKI security — Thu, 08 Oct 2026 12:40:49 +0000

Your hosting dashboard says that a new certificate is ready. Does that mean your visitors are using it?

The answer depends on where HTTPS is managed. For your first renewal, write down who obtains the certificate, which service uses it, and how you will check the connection that a visitor actually makes. Those are separate questions, even when a hosting provider handles all of them for you.

Conceptual renewal workflow, not a production test result. Product-specific activation and checks depend on the actual HTTPS service.

Start with the service that handles HTTPS

HTTPS protects web traffic using TLS, or Transport Layer Security. A server certificate helps a client authenticate the server. It contains a public key and information about the names it covers, among other fields. The corresponding private key stays with the authorized server-side service or key-management system.

MDN's TLS guide explains that modern hosting services often manage certificates and configure HTTPS on your behalf. Before adding your own renewal job, check the provider's documentation and your service settings.

For a managed service, your work may be confirming that automatic renewal is enabled and finding the person responsible for alerts. For a self-managed server, you may also need a certificate client and a deployment procedure. A CDN, a load balancer, or a web server can be the component that handles the browser's TLS connection. A certificate on an application server behind it may cover a different connection.

1. Obtain the next certificate

Renewal normally means obtaining a new certificate before the old one becomes unusable. It does not change the expiry date printed inside the old certificate.

ACME, the Automated Certificate Management Environment protocol, lets a client automate certificate requests. In Let's Encrypt's explanation, the client proves control of the requested domain and asks the CA, or Certificate Authority, to issue a certificate. Issuance is one stage of the work. The details of domain validation depend on the client and deployment.

Record which names the certificate must cover and which client or provider is responsible. Also record where renewal failures are reported. A scheduled job without anyone receiving its failure notice is an incomplete handoff.

2. Make the HTTPS service use it

A new file on disk is useful only if the relevant HTTPS service loads it. The installation path and activation procedure depend on the product. Some services reload configuration, some use a managed upload or secret, and others handle this automatically.

Use the official procedure for your actual hosting platform. It should tell you which certificate chain and key format to supply, how to activate the change, and how to recover if activation fails. Do not assume a command from a different server product applies to yours.

An existing connection may continue under its previous TLS state. Checking a new connection matters when you want to see what the service now presents.

3. Check what the client receives

After activation, make a new connection to the public hostname using a client that performs normal certificate verification. Check the certificate it receives, including the intended names and validity period. Record the client, time, and hostname so another person can understand the observation.

The rules for certificate path validation and service names are described in RFC 5280 and RFC 9525. Finding the expected certificate fingerprint alone does not show that the client accepted its name and trust chain. Similarly, reading a local file does not show what a public endpoint serves.

If your hostname reaches several servers or regions, one successful connection is only one observation. Your deployment procedure should explain which destinations need checking. A certificate check also does not replace an application health check.

A worksheet for the next person

Question	Fill this in for one service
Who obtains the certificate?	Provider or client, responsible person, alert destination
What names must it cover?	The actual hostnames visitors use
Where does the browser's TLS connection end?	The CDN, load balancer, or web server and its service name
How does that component load a replacement?	Official procedure and activation step
What did a new client connection receive?	Hostname, client, time, certificate details and verification result
What remains unobserved?	Other destinations or checks still required by the deployment

This is a planning worksheet, not a report of a production test. Filling in the boxes helps you identify missing responsibilities before the next renewal. Keep private keys and account credentials out of the worksheet.

For a more detailed deployment flow and acceptance conditions, PKI Channel has a renewal and deployment guide in Japanese. Its diagrams separate obtaining, deploying, activating, and observing the replacement. Use it as an additional reference alongside the documentation for your platform.

AI was used for source review and drafting.

Design certificate rotation acceptance tests for every TLS termination point

PKI security — Fri, 02 Oct 2026 06:09:14 +0000

A renewal job exits successfully, the certificate file on disk changes, and one endpoint still serves the previous certificate. Those observations describe different parts of a deployment. Treat each part as an acceptance condition you can observe.

This article gives you a worksheet for testing certificate rotation across your own TLS termination points. The worksheet is an operational proposal. The measured example below covers one local NGINX instance, not a production CA, a CDN, or every environment in the table.

Define the target before defining success

Start with a hostname and the places that terminate TLS for it. A public load balancer, an ingress controller, and an upstream application may each hold different certificates. Decide which connection you intend to test, the expected leaf certificate, and the trust policy of the relevant client.

Observation	Evidence to retain	What it does not establish
New certificate obtained	Certificate identity, validity, issuance result	Deployment to a server
New certificate saved	File or secret version and configured reference	Loading by the running process
Reload requested	Configuration check, command exit, service log	Which leaf a new client receives
Expected leaf received	Endpoint, SNI, timestamp, SHA-256 fingerprint	Name, trust, validity or revocation acceptance
TLS verification passed	Expected name, trust configuration, time, result	Acceptance under every browser or device policy
All intended targets observed	A row for every defined target	Coverage of unspecified or unreachable targets

Certbot documents renewal hooks separately from renewal itself. NGINX also describes applying configuration changes as a process that can fail and retain the old configuration. Use the endpoint observation as a separate condition. Certbot hooks and NGINX control.

Make the observation scope explicit

Use a row for each target you can meaningfully select. Record IPv4 and IPv6 separately when both are used. If a managed edge service does not expose a stable way to select every node, record the sampling method and that limitation. A single successful request is not evidence for every edge node.

hostname, connect_address, port, sni, client_version, tls_backend,
trust_policy, expected_leaf_sha256, observed_leaf_sha256,
observed_at_utc, tls_result, coverage_limit, owner

unknown, unreachable, mismatch and verification_failed should remain distinct. This vocabulary is a suggested worksheet convention, not an ACME or TLS standard.

Probe a selected address without changing the expected name

The following Bash example uses OpenSSL 3.x. The address is illustrative. Replace it and the trust file with values approved for your own environment. timeout is a separate utility, typically supplied by GNU coreutils on Linux.

HOST='service.example.test'
ADDRESS='192.0.2.10:443'
timeout 12s openssl s_client \
  -connect "$ADDRESS" -servername "$HOST" \
  -verify_hostname "$HOST" -verify_return_error \
  -no-CApath -no-CAstore -CAfile trusted-root.pem \
  -showcerts </dev/null
rc=$?
printf 'probe_exit=%s\n' "$rc"

SNI requests a server name; it does not itself verify the certificate name. -showcerts displays the certificates sent by the server, rather than a verified path. Retain the verification result as well as the received leaf. This probe does not request online revocation checks or implement every browser policy. OpenSSL s_client.

Introduce failures at the boundary you want to test

Test	Evidence required	Acceptable operational response
Disk changes while the process still serves the old leaf	Different saved and served fingerprints	Identify the loading or deployment step
Configuration validation fails	Nonzero check result and diagnostics	Keep the known configuration and fix the error
One endpoint remains old	Endpoint-specific observations	Repair that target; do not request another certificate by default
Wrong SNI selects a default server	Received leaf and requested name	Correct the probe or virtual-host configuration
Target cannot be reached	Connection failure and observation scope	Mark coverage incomplete rather than comparing an empty fingerprint
Certificate matches but verification fails	Matching identity plus failed name/trust/time result	Investigate the failed verification condition

Test notification delivery and escalation separately. Having an error in a log does not prove the intended owner received it.

A measured local example

On October 2, 2026, we used Windows, NGINX 1.28.0 and OpenSSL 3.5.4 with a locally generated root, intermediate and leaf certificates. All connections went to loopback. We disabled NGINX SSL object inheritance explicitly for this fixture, so the reload test did not depend on cached file metadata.

We observed four deployment checks: replacing the certificate on disk left the old leaf in new TLS connections; a configuration pointing to a missing certificate failed validation; the corrected reload command returned zero; subsequent strictly verified connections received the new leaf fingerprint. The final observation was required even after the reload command succeeded.

The fixture did not issue a certificate through ACME, test production privileges, restart the OS, send alerts, or exercise a commercial load balancer. The scope is loading and observing a local TLS certificate.

For a more extensive worked example, PKI Channel, which we operate, has an NGINX and ACME lab with commands and recorded results (Japanese; local test CA). That material also states the conditions still needed before applying the workflow to a public environment.

Use the worksheet to define what you must observe next. Rotation is complete for the scope you tested when the expected certificate is being served, the intended client verification succeeds, and any unobserved targets have an explicit owner and follow-up decision.

AI was used for source review and drafting. The local experiments above are limited to the stated versions and conditions.

Build a PQC migration inventory that separates key exchange from certificate signatures

PKI security — Mon, 21 Sep 2026 05:58:59 +0000

A TLS service can negotiate a post-quantum hybrid key agreement while still authenticating with a traditional certificate chain. A single pqc_ready: true field cannot describe that state usefully.

Instead, give each connection two linked workstreams: key establishment and authentication. Then record what is specified, what the products support, what your tests observed, and what your trust policy accepts. Those are different kinds of evidence.

This article proposes an inventory you can take to a platform review. The sample service and all sample results below are fictional; this is a planning template, not a deployment or benchmark report.

Start with one connection, not one application

Consider a browser connecting to an edge gateway, which then opens another TLS connection to an origin API. The gateway-to-origin connection needs its own row. Success on the browser-facing connection does not establish anything about the second connection.

Use a connection ID that joins the inventory to an owner, a change record, and a test report. Add the relying-party population explicitly: “supported desktop browsers” and “partner Java clients” are different acceptance scopes. If you use mutual TLS, inventory client authentication as well as server authentication.

Field	What to record	Why it matters
`connection_id`	Client population, TLS terminator, destination, environment	Prevents evidence from one hop being reused for another
`protection_need`	Data class, required confidentiality period, applicable obligations	Helps prioritize the migration without inventing a universal deadline
`key_establishment`	Protocol, offered groups, observed negotiated group, fallback policy	Separates an enabled option from an observed connection
`authentication`	Leaf public-key algorithm, handshake signature, issuer signatures across the chain	A certificate’s subject key and its issuer’s signature are different dependencies
`implementation`	Client/server/library versions, build options, provider or HSM dependencies	Makes the claim reproducible and bounded
`trust_policy`	CA, trust-store owners, relying-party requirements, approval evidence	Cryptographic support alone does not establish acceptance
`evidence`	Test ID, date, versions, configuration, path, observations, limitations	Connects each result to the environment actually tested
`change_control`	Owner, rollback condition, exception expiry, retirement condition	Gives unresolved work a destination

Store references to secret-management records, not private keys or access tokens, in this inventory.

Keep standards evidence separate from deployment evidence

As checked on 21 September 2026, these documents describe different layers:

Layer	Primary source	What it supports
Key encapsulation algorithm	NIST FIPS 203	Specifies ML-KEM; this is not a signature algorithm
Digital signature algorithm	NIST FIPS 204	Specifies ML-DSA for generating and verifying signatures
TLS hybrid key agreement	RFC 10024	Defines X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 for TLS 1.3
X.509 representation	RFC 9881	Specifies identifiers and conventions for ML-DSA public keys and signatures in certificates and CRLs

RFC 10024 was published in August 2026. An old inventory that still calls this particular specification an Internet-Draft needs a version update. That update does not prove that an installed TLS stack supports it.

Likewise, RFC 9881 is not evidence that your issuing CA, browsers, trust stores, or operational tooling will accept a proposed certificate profile. Record each dependency against its own current documentation and actual tests. Include current errata when reviewing the standards; the NIST landing pages link to potential updates.

The inventory below is an engineering proposal. It is not a schema mandated by those standards. It follows the broader goal of changing cryptography while preserving security and service continuity described in NIST CSWP 39upd1 on crypto agility.

Use evidence states instead of a readiness checkbox

For each workstream, maintain separate fields for specification, implementation, lab evidence, and production evidence. Use explicit states such as unknown, documented, tested_pass, tested_fail, and not_applicable_with_reason.

Do not collapse them into an ordered score. A published specification and an unsupported client can coexist. A lab pass and a production failure can coexist. An empty field means unknown, never success.

Here is a deliberately incomplete fictional inventory record for a private API pilot:

{
  "schema_version": "1.0",
  "example_only": true,
  "connection_id": "partner-client-to-private-api",
  "environment": "planned_lab",
  "owner": "example-platform-team",
  "key_establishment": {
    "protocol_target": "TLS 1.3",
    "group_target": "X25519MLKEM768",
    "specification": "RFC 10024",
    "implementation_support": "unknown",
    "observed_group": null,
    "lab_evidence": "not_tested",
    "production_evidence": "not_tested"
  },
  "authentication": {
    "current_leaf_key": "unknown",
    "current_handshake_signature": "unknown",
    "current_chain_signatures": [],
    "migration_target": "not_selected",
    "ca_support": "unknown",
    "trust_policy_acceptance": "unknown",
    "lab_evidence": "not_tested",
    "production_evidence": "not_tested"
  },
  "evidence_refs": [],
  "fallback_policy": "requires_review",
  "rollback_trigger": "requires_review",
  "next_action": "Identify both TLS implementations and the relying parties"
}

Notice what is missing: an assertion that the API is quantum-safe. Selecting a target group is a planning decision. It produces no measured compatibility or security result.

Give the two workstreams different acceptance gates

For key establishment, propose a test matrix that includes supported and unsupported peers, the real network path, full handshakes and resumption, and the expected behavior when the target group cannot be used. Capture the negotiated group for the applicable handshake type, errors, and fallback decisions. Do not infer a fresh hybrid exchange from a resumed session without checking how that session established its keys. TLS 1.3 separates key exchange from authentication and permits different resumption modes; see RFC 8446, sections 2 and 4.2.9.

Measure handshake traffic, latency and resource usage against an explicitly defined baseline. Record sample size and conditions. Choose thresholds with the service owner; this article supplies no measured values or universal performance budget.

For authentication, identify the leaf key, handshake signature and each certificate-chain signature separately. Test the proposed profile through issuance, delivery, path validation, renewal and the applicable revocation checks. Include every relying-party class in scope. For mutual TLS, repeat this for client certificates and server-side validation.

Observation	State you may record	Claim it does not establish
A hybrid group is documented by the vendor	Implementation support is documented for the named version	Your deployed configuration negotiated that group
A lab handshake negotiated the target group	That test passed on that path and version	Certificate authentication migrated to PQ signatures
A private lab accepts an ML-DSA certificate chain	That validation test passed under that trust configuration	Public browsers or external partners accept it
A fallback connection succeeds	Availability behavior matched the test expectation	The fallback retained the target PQ property

Fallback and rollback deserve a recorded security consequence. A recovery path that restores service using traditional key establishment may be operationally useful, but it must remain visible as an exception to the target protection policy. Assign an owner, an expiry or review date, and a condition for removing it.

Make evidence expire when its assumptions change

A useful evidence reference points to a specific report with versions, configurations, client population, path, timestamp and limitations. Reopen affected acceptance gates when any of those assumptions changes. Examples include a TLS-inspection appliance added to the route, a library upgrade, or a new trust-store population.

Retirement is another gate. “The new group is available” is different from “the old mode is no longer used within the stated scope.” Keep a residual-use inventory and time-bounded exceptions before closing the migration item.

For the wider sequence from inventory through testing and retirement, our PKI Channel migration roadmap (Japanese) includes a stage diagram and completion criteria. It complements the connection-level worksheet here. PKI Channel is operated by the author account.

Start your next review with one connection and two questions: what was actually observed for key establishment, and what was actually accepted for authentication? If either answer has no bounded evidence, record the gap and its next owner.

AI disclosure: This draft was researched and written by an AI agent under the publisher’s direction. The inventory and fictional example are proposals, not reports of tests we performed. Primary references were checked on 21 September 2026. Independent human technical review is pending.