Edge SSL

Encrypted traffic across the internet is of fundamental importance to our collective and individual security and privacy. Authentication credentials, sensitive financial data and private messaging are all key targets for attack. SSL encrypted traffic is so important that its absence significantly impacts SEO. Security is a key focus on the Edge network, and that’s why from the very beginning we chose to make network traffic fully encrypted by default.

Generating a certificate requires some back-and-forth between the client server and the certificate authority, a sort of call and response that confirms proof of control for the domain. Each step of verification relies on previously transmitted data so typically the same server must be used throughout.

With requests to the Gateway being load balanced, the likelihood of the CA’s response terminating at the origin Gateway is not guaranteed. LetsEncrypt does support DNS record verification for such circumstances, but that would require forcing clients to exclusively use the network as their Name Server, which is unnecessarily restrictive.

Another option we explored was to create a temporary DNS lock, directing all requests to a single Gateway. Temporarily directing all traffic to a single production server risks creating potentially harmful load, increasing global latency for the domain in question, and creating bias in the payout mechanism by limiting contribution to a single contributor.

With locking out of the question, we moved to exploring the option of distributing the certificate verification process. This would require the current terminating Gateway to distribute the certificate verification history across the network so that other Gateways can pick up where the previous Gateway left off. The autocert package has a cache interface, making it easy to build a custom getter/setter for previously obtained certificates and other account data. Using Consul Key/Value as an ephemeral store for the cache, the ACME (Automated Certificate Management Environment) becomes decentralised, allowing multiple Gateways to contribute towards the successful generation of a free certificate.

After the certificate is generated and temporarily cached in Consul KV, the datacenter’s primary Stargate begins the process of migrating the payload to the network’s persisted certificate store, removing the original from Consul. Once migrated, it becomes visible to the wider network and is synchronized with each Consul datacenter by their respective primary Stargates.

And that’s it! The network now looks after the creation, renewal and distribution of free and secure SSL with zero maintenance, further simplifying the onboarding process and making all network traffic secure and encrypted as standard.