AC pública

Puedes usar Public Certificate Authority para aprovisionar e implementar certificados X.509 de confianza generalizada después de validar que el solicitante del certificado controla los dominios. Public CA te permite solicitar de forma directa y programática certificados TLS de confianza pública que ya están 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.

Public CA te permite administrar casos de uso de gran volumen que otras AC no pudieron admitir. Si eres cliente de Google Cloud , puedes solicitar certificados TLS para tus dominios directamente desde Public CA.

La mayoría de los problemas relacionados con los certificados se deben a errores humanos o descuidos, por lo que te recomendamos que automatices los ciclos de vida de los certificados. La Public CA usa el protocolo de entorno de administración de certificados automático (ACME) para el aprovisionamiento, la renovación y la revocación automáticos de certificados. La administración automática de certificados reduce el tiempo de inactividad que pueden causar los certificados vencidos y minimiza los costos operativos.

La Public CA aprovisiona certificados TLS para varios Google Cloud servicios, como App Engine, Cloud Shell, Google Kubernetes Engine y Cloud Load Balancing.

Quién debería usar Public CA

Puedes usar Public CA por los siguientes motivos:

  • Si buscas un proveedor de TLS con alta ubicuidad, escalabilidad, seguridad y confiabilidad.
  • Si deseas la mayoría, si no todos, los certificados TLS para tu infraestructura, incluidas las cargas de trabajo locales y las configuraciones de proveedores de varias nubes, desde un solo proveedor de servicios en la nube.
  • Si necesitas control y flexibilidad sobre la administración de certificados TLS para personalizarla según los requisitos de tu infraestructura.
  • Si deseas automatizar la administración de certificados TLS, pero no puedes usar certificados administrados en Google Cloud servicios como GKE o Cloud Load Balancing.

Te recomendamos que uses certificados de confianza pública solo cuando los requisitos de tu empresa no permitan otra opción. Debido al costo histórico y la complejidad de mantener las jerarquías de infraestructura de clave pública (PKI), muchas empresas usan jerarquías de PKI públicas, incluso cuando una jerarquía privada tiene más sentido.

El mantenimiento de jerarquías públicas y privadas se volvió mucho más simple con varias Google Cloud ofertas. Te recomendamos que elijas cuidadosamente el tipo correcto de PKI para tu caso de uso.

Para los requisitos de certificados no públicos, Google Cloud ofrece dos soluciones fáciles de administrar:

Beneficios de Public CA

Public CA proporciona los siguientes beneficios:

  • Automatización: Como los navegadores de Internet tienen como objetivo el tráfico completamente encriptado y la reducción de los períodos de validez de los certificados, existe el riesgo de usar certificados TLS vencidos. El vencimiento del certificado puede provocar errores en el sitio web y causar interrupciones del servicio. Public CA evita el problema del vencimiento del certificado, ya que te permite configurar tu servidor HTTPS para obtener y renovar automáticamente los certificados TLS necesarios desde nuestro extremo ACME.

  • Cumplimiento: Public CA se somete a auditorías independientes periódicas y rigurosas de los controles de seguridad, privacidad y cumplimiento. Los sellos de Webtrust otorgados como resultado de estas auditorías anuales demuestran la conformidad de Public CA con todos los estándares pertinentes de la industria.

  • Seguridad: La arquitectura y las operaciones de Public CA están diseñadas para el nivel más alto de estándares de seguridad y ejecutan evaluaciones independientes con regularidad para confirmar la seguridad de la infraestructura subyacente. La Public CA cumple o supera todos los controles, las prácticas operativas y las medidas de seguridad que se mencionan en el documento sobre seguridad de Google.

    El enfoque de Public CA en la seguridad se extiende a funciones como la validación de dominios de varias perspectivas. La infraestructura de Public CA se distribuye a nivel global. Por lo tanto, Public CA requiere un alto grado de acuerdo en perspectivas geográficamente diversas, lo que proporciona protección contra el secuestro del Protocolo de puerta de enlace de borde (BGP) y los ataques de secuestro del servidor de nombres de dominio (DNS).

  • Confiabilidad: El uso de la infraestructura técnica probada de Google hace que Public CA sea un servicio altamente disponible y escalable.

  • Ubicuidad: La fuerte ubicuidad del navegador de Google Trust Services ayuda a garantizar que los servicios que usan certificados que emite Public CA funcionen en la mayor cantidad posible de dispositivos y sistemas operativos.

  • Soluciones TLS optimizadas para configuraciones híbridas: Public CA te permite crear una solución de certificado TLS personalizada que usa la misma CA para diversos casos de uso y situaciones. Public CA sirve de manera eficaz los casos de uso en los que las cargas de trabajo se ejecutan de forma local o en un entorno de proveedor de varias nubes.

  • Escala: Los certificados suelen ser costosos de obtener y difíciles de aprovisionar y mantener. Al ofrecer acceso a grandes volúmenes de certificados, Public CA te permite usar y administrar certificados de formas que antes se consideraban poco prácticas.

Usa la CA pública con el Administrador de certificados

Para usar la función de Public CA del Administrador de certificados, debes estar familiarizado con los siguientes conceptos:

  • Cliente ACME. Un cliente de entorno de administración de certificados automático (ACME) es un cliente de administración de certificados que usa el protocolo ACME. Tu cliente ACME debe admitir la vinculación de cuentas externas (EAB) para trabajar con Public CA.

  • Vinculación de cuentas externas (EAB). Debes vincular cada cuenta ACME que uses con Public CA del Administrador de certificados al proyecto de destino Google Cloud con la vinculación de cuentas externas. Para ello, debes registrar cada cuenta ACME con un secreto vinculado a su proyecto correspondiente Google Cloud . Para obtener más información, consulta Vinculación de cuentas externas.

Desafíos de Public CA

Cuando usas Public CA para solicitar un certificado, el Administrador de certificados te pide que demuestres tu control sobre los dominios que aparecen en ese certificado. Puedes demostrar el control del dominio resolviendo desafíos. Public CA autoriza los nombres de dominio después de que demuestras tu control de los dominios de destino.

Después de obtener las autorizaciones necesarias, puedes solicitar certificados que sean válidos solo por un período específico. Después de este período, debes volver a validar el nombre de dominio resolviendo uno de los tres tipos de desafíos para seguir solicitando certificados.

Tipos de desafíos

Public CA admite los siguientes tipos de desafíos:

  • Desafío HTTP. Este desafío implica crear un archivo en una ubicación conocida en un servidor HTTP (puerto 80) para que Public CA lo recupere y verifique. Para obtener más información, consulta Desafío HTTP.

  • Desafío de negociación de protocolo de la capa de aplicación TLS (ALPN). Requiere que un servidor proporcione un certificado específico durante una negociación de TLS en el puerto 443 para demostrar el control sobre un dominio. Para obtener más información, consulta Extensión de desafío ACME TLS-ALPN.

  • Desafío DNS. Requiere agregar un registro DNS específico en una ubicación definida para demostrar el control sobre un dominio. Para obtener más información, consulta Desafío DNS.

Si usas el desafío HTTP o el desafío TLS-ALPN para validar un nombre de dominio, el cliente solo puede solicitar que los nombres de dominio validados se incluyan en un certificado. Si usas el desafío DNS, el cliente también puede solicitar que los subdominios de ese nombre de dominio se incluyan en un certificado.

Por ejemplo, si validas *.myorg.example.com con el desafío DNS, subdomain1.myorg.example.com y subdomain2.myorg.example.com se incluyen automáticamente en el certificado comodín. Sin embargo, si validas myorg.example.com con un desafío HTTP o TLS-ALPN, el cliente solo puede solicitar que se incluya myorg.example.com en el certificado y no puedes validar *.myorg.example.com con los desafíos que no son de DNS.

Lógica de solución de desafíos

La lógica de desafío de la CA pública es la siguiente:

  1. Public CA proporciona un token aleatorio.
  2. El cliente pone el token a disposición en una ubicación bien definida. La ubicación depende del desafío.
  3. El cliente le indica a Public CA que preparó el desafío.
  4. Public CA verifica si el token presente en la ubicación esperada coincide con el valor esperado.

El nombre de dominio se autoriza después de que se completa este proceso. El cliente puede solicitar un certificado con ese nombre de dominio. Solo debes resolver un desafío por nombre de dominio.

¿Qué sigue?