In the case of Cloudflare, there also is option C, "Keyless-SSL", where you control the key. (https://www.cloudflare.com/ssl/keyless-ssl/ https://www.cloudflare

In the case of Cloudflare, there also is option C, "Keyless-SSL", where you control the key. (https://www.cloudflare.com/ssl/keyless-ssl/ https://www.cloudflare.com/ssl/keyless-ssl/) But that is irrelevant in our case. We opted to use Cloudflare Spectrum to facilitate our change. There is no way to mix Spectrum and non-Spectrum on one hostname, but Spectrum allows us to choose between TCP, HTTP, and HTTPS pipelines. While we intend to TCP proxy port 22 on gitlab.com and 443 on altssh.gitlab.com, this also allows us to use Cloudflare's HTTP(s) content processing pipeline on ports 80 and 443 on gitlab.com. In the latter case Cloudflare will be terminating TLS, performing WAF, CDN and Workers duty, then re-encrypt and send the request to our origin. You can look at some visualization of this here: https://gitlab.com/gitlab-com/gl-infra/readiness/tree/master/cloudflare#architecture https://gitlab.com/gitlab-com/gl-infra/readiness/tree/master...