En pocas palabras, el webmaster del sitio carga el certificado en CloudFlare.

Consulte este artículo para obtener más información .

El modo Sin llave no tiene este requisito. En su lugar, utiliza un servidor de claves local para proporcionar la clave privada del servidor. Vea el diagrama aquí para obtener detalles sobre cómo funciona esto.

Para cuentas gratuitas

Cloudflare estado en su blog :

  

Para todos los clientes, ahora suministraremos automáticamente un SSL   Certificado en la red de CloudFlare que aceptará conexiones HTTPS.   para el dominio y subdominios de un cliente. Esos certificados incluyen un   entrada para el dominio raíz (por ejemplo, example.com) así como un comodín   entrada para todos los subdominios de primer nivel (por ejemplo, www.ejemplo.com,   blog.example.com, etc.).

Cloudflare do controla el dominio, ya que el cliente le ha apuntado sus registros DNS, esto significa que pueden obtener un Certificado de dominio validado . Los procedimientos de validación del dominio no tienen por qué implicar el envío de un correo electrónico al dominio, lo que no sería posible que Cloudflare intercepte porque el registro MX no está reenviado. En su lugar, pueden probar que poseen el dominio al colocar un archivo de texto con un nombre aleatorio que contiene una clave aleatoria para que la CA realice una consulta para demostrar el control del dominio. La CA especificará el nombre y el contenido de este archivo que luego podrán verificar. Cloudflare podría entonces interceptar las solicitudes de la URL y mostrar el código de validación necesario.

¡Exactamente! Usted apunta su DNS a CloudFlare. Pero no le permite usar su propio certificado SSL si no tiene el plan de Negocios ($ 200 / mes) o Enterprise ($ 5000 / mes). Puede utilizar un certificado SSL flexible que proporcionan. Entonces, si desea usar su propio certificado EV-SSL, necesita planes. Recomiendo usar Incapsula Enterprise en su lugar. ¡Mucho mejor firewall de aplicaciones web con protección DDoS!

CloudFlare tiene actualmente su propia CA para que puedan fabricar cualquier certificado que deseen. Su política consiste en crear certificados solo para los dominios que están alojados en su servidor DNS, pero no existen y no pueden existir tales limitaciones técnicas.

Corrección: CloudFlare ejecuta Origin CA pero no lo están una CA pública. La "CA de origen" permite a CloudFlare firmar y revocar certificados para la conexión entre CloudFlare y el host de origen real (generalmente no se conoce públicamente). Estos certificados no tienen una cadena de confianza al almacén de confianza de los agentes de usuario de uso común. Eso significa que los certificados firmados por "Origin CA" no son de confianza, por ejemplo. Firefox, Chrome o Safari. Eso está bien porque el caso de uso de estos certificados es asegurar la conexión entre CloudFlare, el servidor front-end (técnicamente, proxy inverso HTTP con soporte TLS) y el servidor backend del servidor real.

Para todos los sitios servidos a través de CloudFlare, admiten SSL universal que parece Para ser respaldado actualmente por el público COMODO CA. La inspección de los certificados de un par de sitios que se ejecutan a través de CloudFlare sugiere que están obteniendo certificados "Domain Control Validated" de COMODO donde CN registra puntos al proxy inverso real controlado por CloudFlare (por ejemplo, sni9922.cloudflaressl.com ) y Subject Alternative Names enumera los dominios reales que se sirven a través de CloudFlare. Cada certificado se utiliza para un puñado de dominios.

No estoy seguro de por qué tienen tal y acuerdo. Obviamente necesitan SNI para averiguar qué certificado otorgar a cualquier nueva conexión, pero deberían poder adquirir un certificado real para cualquier dominio que controlen (es decir, cada certificado podría tener un registro CN que apunta directamente a un dominio realmente alojado en lugar de algo que se parece a sni9922.cloudflaressl.com ).

Obviamente, pueden obtener certificados de "Dominio Validado por Control" para cualquier host que se ejecute a través de ellos porque controlan los registros DNS (sus registros DNS deben apuntar a CloudFlare para usar CloudFlare para su host) y cualquier nuevo HTTP (o HTTPS) las conexiones van a sus servidores front-end.

TL; DR: CloudFlare no puede proporcionar un certificado SSL / TLS válido para dominios que no están bajo su control. Sin embargo, todos los clientes de CloudFlare tienen que alojar sus registros DNS en CloudFlare y, como resultado, CloudFlare tiene control de dominio para todos sus clientes.