Skip to main content
Corrected the information in the answer: CloudFlare does not have public CA, only private CA
Source Link

CloudFlare nowadays has its own CA so they can fabricate any certificate they want. Their policy is to create certificates for only domains that are hosted on their DNS server but there are no and cannot be such technical limitations.

Correction: CloudFlare is running Origin CA but they are not a public CA. The "Origin CA" allows CloudFlare to sign newand revoke certificates for the connection between CloudFlare and the real origin host (usually not publicly known). These certificates do not have trust chain to commonly used user agentsagents' trust store. That means that certificates signed by "Origin CA" are not trusted by e.g. Firefox, Chrome or Safari. That's okay because the use case for these certificates are used is to secure connection between CloudFlare the front end server (technically HTTP reverse proxy with TLS support) and the real host backend server.

For all sites served through CloudFlare, they support Universal SSL which seems to be currently backed by public COMODO CA. Inspecting the certificates of a couple of sites running via CloudFlare suggests that they are getting "Domain Control Validated" certificates from COMODO where CN record points to actual CloudFlare controlled reverse proxy (e.g. sni9922.cloudflaressl.com) and Subject Alternative Names lists actual domains that are served via CloudFlare. Each certificate is used for a handful of domains.

I'm not sure why they have such and arrangement. They obviously need SNI to figure out which certificate to give to any new connection but they should be able to acquire a real certificate for any domain they control (that is, every certificate shouldcould have CN record pointing directly to actually hosted domain, not instead of something that looks like sni9922.cloudflaressl.com).

They are obviously able to get "Domain Control Validated" certificates for any host running via them because they control the DNS records (your DNS records must point to CloudFlare to use CloudFlare for your host) and any new HTTP (or HTTPS) connections go to their front end servers.

TL;DR: CloudFlare cannot provide a valid SSL/TLS certificate for domains not under its control. However, all clients of CloudFlare have to host their DNS records on CloudFlare and as a result, CloudFlare has domain control for all its clients.

CloudFlare nowadays has its own CA so they can fabricate any certificate they want. Their policy is to create certificates for only domains that are hosted on their DNS server but there are no and cannot be such technical limitations.

Correction: CloudFlare is running Origin CA but they are not public CA. The "Origin CA" allows CloudFlare to sign new certificates for the connection between CloudFlare and the real origin host (usually not publicly known). These certificates do not have trust chain to commonly used user agents trust store. That means that certificates signed by "Origin CA" are not trusted by e.g. Firefox, Chrome or Safari. That's okay because the use case these certificates are used is to secure connection between CloudFlare front end server and real host backend server.

For all sites served through CloudFlare, they support Universal SSL which seems to be backed by COMODO CA. Inspecting the certificates of a couple of sites running via CloudFlare suggests that they are getting "Domain Control Validated" certificates from COMODO where CN record points to actual CloudFlare controlled reverse proxy (e.g. sni9922.cloudflaressl.com) and Subject Alternative Names lists actual domains that are served via CloudFlare. Each certificate is used for a handful of domains.

I'm not sure why they have such and arrangement. They obviously need SNI to figure out which certificate to give to any new connection but they should be able to acquire a real certificate for any domain they control (that is, every certificate should have CN pointing to actually hosted domain, not something that looks like sni9922.cloudflaressl.com).

They are obviously able to get "Domain Control Validated" certificates for any host running via them because they control the DNS records (your DNS records must point to CloudFlare to use CloudFlare for your host).

CloudFlare nowadays has its own CA so they can fabricate any certificate they want. Their policy is to create certificates for only domains that are hosted on their DNS server but there are no and cannot be such technical limitations.

Correction: CloudFlare is running Origin CA but they are not a public CA. The "Origin CA" allows CloudFlare to sign and revoke certificates for the connection between CloudFlare and the real origin host (usually not publicly known). These certificates do not have trust chain to commonly used user agents' trust store. That means that certificates signed by "Origin CA" are not trusted by e.g. Firefox, Chrome or Safari. That's okay because the use case for these certificates is to secure connection between CloudFlare the front end server (technically HTTP reverse proxy with TLS support) and the real host backend server.

For all sites served through CloudFlare, they support Universal SSL which seems to be currently backed by public COMODO CA. Inspecting the certificates of a couple of sites running via CloudFlare suggests that they are getting "Domain Control Validated" certificates from COMODO where CN record points to actual CloudFlare controlled reverse proxy (e.g. sni9922.cloudflaressl.com) and Subject Alternative Names lists actual domains that are served via CloudFlare. Each certificate is used for a handful of domains.

I'm not sure why they have such and arrangement. They obviously need SNI to figure out which certificate to give to any new connection but they should be able to acquire a real certificate for any domain they control (that is, every certificate could have CN record pointing directly to actually hosted domain instead of something that looks like sni9922.cloudflaressl.com).

They are obviously able to get "Domain Control Validated" certificates for any host running via them because they control the DNS records (your DNS records must point to CloudFlare to use CloudFlare for your host) and any new HTTP (or HTTPS) connections go to their front end servers.

TL;DR: CloudFlare cannot provide a valid SSL/TLS certificate for domains not under its control. However, all clients of CloudFlare have to host their DNS records on CloudFlare and as a result, CloudFlare has domain control for all its clients.

Corrected the information in the answer: CloudFlare does not have public CA, only private CA
Source Link

CloudFlare nowadays has its own CA so they can fabricate any certificateCloudFlare nowadays has its own CA so they can fabricate any certificate they want. Their policy is to create certificates for only domains that are hosted on their DNS server but there are no and cannot be such technical limitations.

Correction: CloudFlare is running Origin CA but they wantare not public CA. TheirThe "Origin CA" allows CloudFlare to sign new certificates for the connection between CloudFlare and the real origin host (usually not publicly known). These certificates do not have trust chain to commonly used user agents trust store. That means that certificates signed by "Origin CA" are not trusted by e.g. Firefox, Chrome or Safari. That's okay because the use case these certificates are used is to secure connection between CloudFlare front end server and real host backend server.

For all sites served through CloudFlare, they support Universal SSL which policyseems is to createbe backed by COMODO CA. Inspecting the certificates for only domainsof a couple of sites running via CloudFlare suggests that they are hosted on their DNS server but theregetting "Domain Control Validated" certificates from COMODO where CN record points to actual CloudFlare controlled reverse proxy (e.g. sni9922.cloudflaressl.com) and Subject Alternative Names lists actual domains that are noserved via CloudFlare. Each certificate is used for a handful of domains.

I'm not sure why they have such and cannotarrangement. They obviously need SNI to figure out which certificate to give to any new connection but they should be such technical limitationsable to acquire a real certificate for any domain they control (that is, every certificate should have CN pointing to actually hosted domain, not something that looks like sni9922.cloudflaressl.com).

They are obviously able to get "Domain Control Validated" certificates for any host running via them because they control the DNS records (your DNS records must point to CloudFlare to use CloudFlare for your host).

CloudFlare nowadays has its own CA so they can fabricate any certificate they want. Their policy is to create certificates for only domains that are hosted on their DNS server but there are no and cannot be such technical limitations.

CloudFlare nowadays has its own CA so they can fabricate any certificate they want. Their policy is to create certificates for only domains that are hosted on their DNS server but there are no and cannot be such technical limitations.

Correction: CloudFlare is running Origin CA but they are not public CA. The "Origin CA" allows CloudFlare to sign new certificates for the connection between CloudFlare and the real origin host (usually not publicly known). These certificates do not have trust chain to commonly used user agents trust store. That means that certificates signed by "Origin CA" are not trusted by e.g. Firefox, Chrome or Safari. That's okay because the use case these certificates are used is to secure connection between CloudFlare front end server and real host backend server.

For all sites served through CloudFlare, they support Universal SSL which seems to be backed by COMODO CA. Inspecting the certificates of a couple of sites running via CloudFlare suggests that they are getting "Domain Control Validated" certificates from COMODO where CN record points to actual CloudFlare controlled reverse proxy (e.g. sni9922.cloudflaressl.com) and Subject Alternative Names lists actual domains that are served via CloudFlare. Each certificate is used for a handful of domains.

I'm not sure why they have such and arrangement. They obviously need SNI to figure out which certificate to give to any new connection but they should be able to acquire a real certificate for any domain they control (that is, every certificate should have CN pointing to actually hosted domain, not something that looks like sni9922.cloudflaressl.com).

They are obviously able to get "Domain Control Validated" certificates for any host running via them because they control the DNS records (your DNS records must point to CloudFlare to use CloudFlare for your host).

Source Link

CloudFlare nowadays has its own CA so they can fabricate any certificate they want. Their policy is to create certificates for only domains that are hosted on their DNS server but there are no and cannot be such technical limitations.