Encryption in Transit
All communication — between the SDK and the ingest API, between internal services, and between portals and their backend APIs — is encrypted in transit using TLS. This page documents the TLS configuration at each boundary.
SDK to Ingest API
The VeriProof SDK communicates with the Ingest API over HTTPS (TLS 1.2 minimum, TLS 1.3 preferred):
| Boundary | Protocol | Certificate |
|---|---|---|
SDK → ingest.veriproof.app | TLS 1.2 / 1.3 | Azure-managed certificate + Azure Front Door CDN |
| SDK → Enterprise endpoint (self-hosted) | TLS 1.2 / 1.3 | Customer-provided certificate |
The SDK does not skip certificate validation. The AllowInsecureEndpoint option in the .NET SDK and the equivalent in Python/TypeScript is provided only for private VNET scenarios where the enterprise endpoint uses an internal CA. It must never be set to true for public endpoints.
Customer Portal and Staff Portal
Portal web applications are served exclusively over HTTPS:
- HTTP requests are redirected to HTTPS at the Azure Front Door / CDN layer before they reach the application
- HSTS (HTTP Strict Transport Security) is set with a 1-year max-age
API calls from the portal frontend to the Customer Portal Functions backend travel over HTTPS. The JWT authentication cookie is set with Secure and HttpOnly flags, ensuring it is never transmitted over unencrypted connections or accessible to JavaScript.
Internal service-to-service communication
All communication between internal Azure Functions apps uses:
- HTTPS with Azure-managed certificates
- Managed Identity authentication (no shared secrets on the wire)
- Network-level restriction via Azure VNet integration (production environments)
The Blockchain Functions service communicates with the Solana RPC endpoint over HTTPS. Enterprise deployments can configure a private Solana RPC node if required.
Database connections
| Connection | Encryption |
|---|---|
| Application → PostgreSQL | TLS required (ssl=true); certificate validation enabled |
| Background workers → PostgreSQL | TLS required |
| Staff Portal → PostgreSQL (staff_role) | TLS required |
Connection strings are not stored in environment variables or application settings. They are fetched from Azure Key Vault at startup using Managed Identity and cached in memory. No unencrypted credentials appear in logs, configuration files, or version control.
Enterprise Tier — Confidential Notary
For Enterprise Tier deployments, the SDK communicates with the Confidential Notary inside the customer’s subscription. The connection from the SDK to the notary endpoint is TLS-encrypted. Additionally:
- The notary generates an ephemeral TLS key pair inside the TEE on startup
- The public key is bound to the AMD SEV-SNP attestation report
- Clients can verify that the TLS session terminates inside the TEE (not at a load balancer or proxy)
This provides end-to-end confidentiality from the SDK to the hardware-protected processing environment.
Webhook delivery
Outbound webhook calls (alert notifications, compliance summaries) are sent over HTTPS only. Plain HTTP webhook URLs are rejected at configuration time. Webhook payloads are signed with HMAC-SHA256 and include an X-VeriProof-Signature header so your receiver can verify authenticity.
TLS version policy
| TLS version | Support |
|---|---|
| TLS 1.3 | ✅ Preferred |
| TLS 1.2 | ✅ Supported |
| TLS 1.1 | ❌ Disabled |
| TLS 1.0 / SSL 3.0 | ❌ Disabled |
Cipher suite selection follows Azure Front Door and Azure App Service’s current best-practice defaults, prioritizing forward-secrecy suites (ECDHE) and rejecting RC4 and export-grade ciphers.
Next steps
- Encryption at Rest — how stored data is encrypted
- Azure Key Vault & HMAC Signing — managing certificates and signing keys
- API Authentication — how API keys are transmitted and validated