Encryption in transit
Use HTTPS for remote VeriProof connections. Each SDK preserves an explicit port and path prefix on the configured base URL.
Transport encryption protects a connection. It does not replace application authorization or verification of a callback’s sender and contents.
Plain HTTP is limited to the loopback hosts supported by the language SDK for local testing. It is not a private-network certificate bypass.
Validate each connection
| Connection | Checks |
|---|---|
| Application to VeriProof | HTTPS endpoint, certificate trust, application SDK key, timeout, and redirect rejection |
| Application to Edge Gateway | Loopback HTTP only for an explicit local path; HTTPS, access policy, and certificate trust for remote connections |
| Browser to customer API | HTTPS origin, secure authentication cookie, CORS, and redirect URLs |
| Service to database | Required transport encryption, server identity, credentials, and network path |
| Service to Key Vault or storage | Managed identity, private endpoint, DNS, and TLS |
| Review or outcome callback | HTTPS, exact signature verification, timestamp, replay defense, and idempotency |
| Proof provider | Approved Solana RPC or Azure SQL connection and verifier permissions |
| External integration | Allowed destination, secret header, certificate, and data classification |
Redirects and proxies
Do not forward authentication headers to an unexpected host. Check reverse-proxy and gateway behavior against the release’s redirect rules, including the destination and retained headers.
Local development
Use loopback HTTP only for an explicit local test. Never use the insecure-endpoint option for a remote host.
Certificate operations
Name the certificate owner and record expiry, renewal, private-key storage, trusted roots, and DNS dependencies. Test renewal before expiry and define how operators respond if trust validation fails.