OpenSign title matches show a signing surface without a product fingerprint

#zoomeye #esignature #documentsecurity

OpenSign title matches show a signing surface without a product fingerprint

Electronic signature platforms hold documents before, during, and after a decision that changes a business or legal process. A count-only ZoomEye query found 0 application matches for OpenSign and 90 title matches on 2026-11-04. The gap is a fingerprint observation, not evidence that the systems are unauthenticated.

Query scope

The two probes used app="OpenSign" and title="OpenSign" with sub_type=all, page 1, and pagesize 1. The observations were recorded at 07:49 Asia/Shanghai. The application query returned 0. The title query returned 90. These are global matches in the selected ZoomEye scope, and the page size does not limit the total count that the API reported.

OpenSign's official self-host documentation describes a Docker deployment. The API documentation states that requests use an x-api-token header, and the settings documentation notes that token generation depends on the product tier. These product facts explain why the signing boundary matters. They do not prove that any of the 90 title matches is a configured, reachable signing portal.

Documents and trust artifacts live together

A signing workflow contains more than the visible PDF. It can contain templates, recipient identity, audit events, signing certificates, private keys, webhook endpoints, and API tokens. The administrative console that manages the certificate pass phrase should not share a public route with a recipient's signing page if the application can separate them.

A title match can come from a marketing page, a customer-facing portal, or a login screen. The next step is to verify the organization and the route. Fetch the page from a controlled network and record the title, TLS certificate, response headers, and redirect chain. Do not attempt to infer approval status from a screenshots or a document identifier. Use an authenticated account on an owned instance to inspect the real configuration.

Review the API token path

Inventory every token, its owner, its creation time, and the routes it can call. The token header should travel only over a validated TLS connection. A token for document creation is not the same authority as a token for template administration or certificate configuration. If the self-hosted tier does not support API token generation, confirm that no alternate integration or shared account was added outside the supported path.

Protect signing keys and PFX files with filesystem permissions and a secret manager. Keep the pass phrase out of the container image and out of process arguments. Back up the signing state, but encrypt the backup and test restoration. Rotate a token after any suspected disclosure and review audit logs for document creation, recipient changes, and certificate updates.

Use the count as an inventory lead

The 90 title matches form a bounded research queue. The absence of an application fingerprint means that a title-only search may include pages that mention the product rather than instances of it. A defender should combine the result with certificate names, organizational ownership, and authenticated confirmation.

The useful conclusion is that ZoomEye observes a signing-related name at a small but non-zero scale while the product fingerprint remains absent. That is enough to justify an ownership review. It is not enough to claim that signing data is exposed.