Puedes usar la autoridad de certificación pública para aprovisionar e implementar certificados X.509 de confianza generalizada después de validar que el solicitante del certificado controla los dominios. La AC pública te permite solicitar de forma directa y programática certificados TLS de confianza pública que ya se encuentran en la raíz de los almacenes de confianza que usan los principales navegadores, sistemas operativos y aplicaciones. Puedes usar estos certificados TLS para autenticar y encriptar el tráfico de Internet.
Las AC públicas te permiten gestionar casos prácticos de gran volumen que las AC tradicionales no han podido admitir. Si eres cliente de Google Cloud , puedes solicitar certificados TLS para tus dominios directamente a una autoridad de certificación pública.
La mayoría de los problemas relacionados con los certificados se deben a errores humanos o descuidos, por lo que recomendamos automatizar los ciclos de vida de los certificados. La AC pública usa el protocolo Automatic Certificate Management Environment (ACME) para aprovisionar, renovar y revocar certificados de forma automática. La gestión automatizada de certificados reduce el tiempo de inactividad que pueden provocar los certificados caducados y minimiza los costes operativos.
La AC pública proporciona certificados TLS para varios Google Cloud servicios, como App Engine, Cloud Shell, Google Kubernetes Engine y Cloud Load Balancing.
Quién debe usar una CA pública
Puedes usar una CA pública por los siguientes motivos:
- Si buscas un proveedor de TLS con alta ubicuidad, escalabilidad, seguridad y fiabilidad.
- Si quieres que la mayoría o todos los certificados TLS de tu infraestructura, incluidas las cargas de trabajo locales y las configuraciones de varios proveedores de servicios en la nube, procedan de un único proveedor de servicios en la nube.
- Si necesitas tener control y flexibilidad sobre la gestión de certificados TLS para personalizarlo según los requisitos de tu infraestructura.
- Si quieres automatizar la gestión de certificados TLS, pero no puedes usar certificados gestionados en servicios de Google Cloud , como GKE o Cloud Load Balancing.
Te recomendamos que solo utilices certificados de confianza pública cuando los requisitos de tu empresa no permitan otra opción. Dado el coste histórico y la complejidad de mantener las jerarquías de infraestructura de clave pública (PKI), muchas empresas utilizan jerarquías de PKI públicas incluso cuando una jerarquía privada tiene más sentido.
Mantener jerarquías públicas y privadas es mucho más sencillo con las múltiples Google Cloud ofertas. Te recomendamos que elijas cuidadosamente el tipo de infraestructura de clave pública (PKI) adecuado para tu caso práctico.
Para los requisitos de los certificados no públicos, Google Cloud ofrece dos soluciones fáciles de gestionar:
Anthos Service Mesh: Cloud Service Mesh incluye el aprovisionamiento de certificados mTLS totalmente automatizado para las cargas de trabajo que se ejecutan en GKE Enterprise mediante la autoridad de certificación de Cloud Service Mesh.
Servicio de Autoridades de Certificación: Servicio de Autoridades de Certificación te permite desplegar, gestionar y proteger autoridades de certificación privadas personalizadas de forma eficiente sin tener que gestionar ninguna infraestructura.
Ventajas de las AC públicas
Las AC públicas ofrecen las siguientes ventajas:
Automatización: como los navegadores de Internet tienen como objetivo que el tráfico esté totalmente cifrado y se reduzca el periodo de validez de los certificados, existe el riesgo de usar certificados TLS caducados. Si los certificados caducan, pueden producirse errores en los sitios web y cortes del servicio. La CA pública evita el problema de la caducidad de los certificados, ya que te permite configurar tu servidor HTTPS para que obtenga y renueve automáticamente los certificados TLS necesarios desde nuestro endpoint ACME.
Cumplimiento: la AC pública se somete periódicamente a rigurosas auditorías independientes de los controles de seguridad, privacidad y cumplimiento. Los sellos WebTrust que se conceden como resultado de estas auditorías anuales demuestran que la autoridad de certificación pública cumple todos los estándares del sector pertinentes.
Seguridad: la arquitectura y las operaciones de la AC pública se han diseñado para cumplir los estándares de seguridad más exigentes y se someten periódicamente a evaluaciones independientes para confirmar la seguridad de la infraestructura subyacente. La autoridad de certificación pública cumple o supera todos los controles, las prácticas operativas y las medidas de seguridad que se mencionan en el informe sobre seguridad de Google.
La seguridad es una prioridad para las autoridades de certificación públicas, por lo que ofrecen funciones como la validación de dominio desde múltiples perspectivas. La infraestructura de las AC públicas está distribuida por todo el mundo. Por lo tanto, una autoridad de certificación pública requiere un alto grado de acuerdo entre perspectivas geográficamente diversas, lo que proporciona protección frente a ataques de secuestro del protocolo de puerta de enlace de frontera (BGP) y secuestro del servidor de nombres de dominio (DNS).
Fiabilidad: el uso de la infraestructura técnica probada de Google convierte a la AC pública en un servicio altamente disponible y escalable.
Ubicuidad: la gran ubicuidad de Google Trust Services en los navegadores ayuda a asegurar que los servicios que usan certificados emitidos por CAs públicas funcionen en la mayor variedad posible de dispositivos y sistemas operativos.
Soluciones TLS optimizadas para configuraciones híbridas: la AC pública te permite crear una solución de certificado TLS personalizada que usa la misma AC en diferentes situaciones y casos prácticos. Una AC pública es eficaz en los casos prácticos en los que las cargas de trabajo se ejecutan on-premise o en un entorno de proveedor de varias nubes.
Escala: los certificados suelen ser caros de obtener y difíciles de aprovisionar y mantener. Al ofrecer acceso a grandes volúmenes de certificados, la AC pública te permite utilizar y gestionar certificados de formas que antes se consideraban poco prácticas.
Usar una AC pública con Gestor de certificados
Para usar la función de AC pública de Certificate Manager, debes conocer los siguientes conceptos:
Cliente ACME. Un cliente de entorno de gestión de certificados automatizado (ACME) es un cliente de gestión de certificados que usa el protocolo ACME. Tu cliente ACME debe admitir la vinculación de cuentas externas (EAB) para funcionar con una autoridad de certificación pública.
Vinculación de cuentas externas (EAB). Debes vincular cada cuenta ACME que utilices con la AC pública de Certificate Manager al proyecto de destino mediante la vinculación de cuentas externas. Google Cloud Para ello, debes registrar cada cuenta de ACME con un secreto vinculado a su proyecto de Google Cloud correspondiente. Para obtener más información, consulta el artículo sobre vincular cuentas externas.
Retos de las AC públicas
Cuando usas una AC pública para solicitar un certificado, Certificate Manager te pide que demuestres que tienes el control de los dominios que figuran en ese certificado. Puedes demostrar que controlas el dominio resolviendo retos. La autoridad de certificación pública autoriza los nombres de dominio después de que demuestres que tienes el control de los dominios de destino.
Una vez que hayas obtenido las autorizaciones necesarias, podrás solicitar certificados que solo sean válidos durante un periodo específico. Transcurrido ese tiempo, debes volver a validar el nombre de dominio resolviendo uno de los tres tipos de desafío para seguir solicitando certificados.
Tipos de verificación
Las AC públicas admiten los siguientes tipos de retos:
Reto HTTP. Este reto consiste en crear un archivo en una ubicación conocida de un servidor HTTP (puerto 80) para que la AC pública lo recupere y lo verifique. Para obtener más información, consulta Reto HTTP.
Reto de negociación de protocolo de capa de aplicación (ALPN) de TLS. Requiere que un servidor proporcione un certificado específico durante una negociación de TLS en el puerto 443 para demostrar que tiene el control de un dominio. Para obtener más información, consulta la extensión de desafío TLS-ALPN de ACME.
Reto de DNS. Requiere añadir un registro DNS específico en una ubicación definida para demostrar el control sobre un dominio. Para obtener más información, consulta Verificación de DNS.
Si usas el reto HTTP o el reto TLS-ALPN para validar un nombre de dominio, el cliente solo puede solicitar que se incluyan en un certificado los nombres de dominio validados. Si utilizas el reto de DNS, el cliente también puede solicitar que se incluyan subdominios de ese nombre de dominio en un certificado.
Por ejemplo, si valida *.myorg.example.com mediante el desafío de DNS, subdomain1.myorg.example.com y subdomain2.myorg.example.com se cubrirán automáticamente con el certificado comodín. Sin embargo, si valida myorg.example.com mediante un desafío HTTP o TLS-ALPN, el cliente solo puede solicitar que se incluya myorg.example.com en el certificado y no puede validar *.myorg.example.com mediante los desafíos que no son de DNS.
Lógica de solución del reto
La lógica de desafío de la CA pública es la siguiente:
- La AC pública proporciona un token aleatorio.
- El cliente pone el token a disposición en una ubicación bien definida. La ubicación depende del reto.
- El cliente indica a la AC pública que ha preparado el reto.
- La AC pública comprueba si el token presente en la ubicación esperada coincide con el valor esperado.
El nombre de dominio se autoriza una vez completado este proceso. El cliente puede solicitar un certificado con ese nombre de dominio. Solo tienes que resolver un desafío por nombre de dominio.