Verification keys are never stored in plain text
Every verification key is one-way hashed (argon2id) before it touches our database. Even we cannot retrieve or read the original key. Only the report itself can be matched against it.
Security & Privacy
Security you can check yourself
Independent testing only means something if the process around it can be trusted. Below is a plain, specific account of how submissions, reports, and communications are protected on this platform: no vague claims, just what is actually in place.
TLSon every connection
2FAfor staff sign-in
EUdatabase and servers
$ curl -sI https://convalencelabs.com HTTP/2 200 strict-transport-security: max-age=31536000; includeSubDomains content-security-policy: default-src 'self'; script-src 'self' 'nonce-…'; object-src 'none'; frame-ancestors 'self'; … x-content-type-options: nosniff referrer-policy: strict-origin-when-cross-origin
Anyone can run this command and see the same result.
Defence in depth
Follow a request from your screen to your certificate.
Encrypted from the first byte
- Every connection uses HTTPS/TLS, and HSTS tells browsers never to fall back to plain HTTP.
- A strict Content Security Policy only lets scripts carrying a one-time token run on our pages.
Tamper-evident certificates
Change one character. Watch the fingerprint break.
When we issue a certificate we record the SHA-256 fingerprint of the exact PDF. On the Verify page anyone can compare their copy against it, in their own browser, without uploading anything.
Verify a certificateLive demo · runs in your browser
Original fingerprint
Your fingerprint
Tiny edit → 0 of 64 characters changed. A tampered PDF can't match the fingerprint on record.
What is in place
Ten specific protections.
No reports sit in an open folder
Certificates are generated in server memory and uploaded directly to private cloud storage. There is no public directory of past reports. Each download link is signed and expires within minutes.
Rate-limited verification, on top of bot protection
The public verification page enforces a strict attempt limit per visitor, with escalating cool-down periods, in addition to Cloudflare Turnstile screening on every form.
Sample photos are stripped of hidden data
Every uploaded photo is automatically re-processed to remove EXIF metadata, including GPS location and device information, before it is stored or embedded in any certificate.
Two-factor sign-in for staff
The laboratory's admin panel requires a password and a time-based one-time code from an authenticator app, with attempt limits on both steps.
Servers locked to cryptographic keys
Server access uses SSH keys only; password logins for the administrator account are disabled, and only the ports each service needs are open.
Payments processed through our own Bitcoin infrastructure
We accept Bitcoin payments through our self-hosted, non-custodial payment server, hosted within the European Union. No third party ever holds or processes a payment on our behalf. We store only a payment reference linked to your order, never card or bank account details.
Authenticated email domain
Our domain is configured with SPF, DKIM, and DMARC, email authentication standards that make it far harder for anyone to send a convincing message impersonating Convalence Labs.
Database and servers inside the EU
Our database is hosted in Frankfurt (Germany) and our web and payment servers in Finland, in line with GDPR principles for data handling and residency.
Encrypted in transit, always
Every connection to convalencelabs.com, whether browsing, submitting a request, or downloading a certificate, is encrypted in transit (HTTPS/TLS), enforced site-wide.
Found a weakness? Tell us.
No system is unbreakable, and we would rather hear about a problem than have it exploited. Security reports go to [email protected], as published in our security.txt.