El parche de Chrome 58 levanta polémica y revuelo
Hace unos meses, Google lanzó un parche (v.58) para su navegador Chrome. El lanzamiento de este parche nos obligó a todos a cuestionar la forma en que estamos emitiendo certificados y rompió de forma retroactiva un montón de conexiones de navegador y servidor web simultáneamente.
Figura - 1
El equipo de soporte de Certified Security Solutions (CSS ) se ocupó de la afluencia de tickets y aconsejó a nuestros clientes sobre cómo tratar este tema candente en aquel momento. Tras observar la creciente necesidad de asistencia después de este parche, publicamos un artículo en nuestro blog en el que detallábamos cómo podíamos solucionar este problema a corto y largo plazo. La solución a largo plazo consistía en corregir las entradas del atributo Subject Alternative Names (SAN) en el entorno y adoptar algunas buenas prácticas en torno a la emisión de certificados. Esta sería, en última instancia, la mejor solución de cara al futuro, ya que el atributo "CommonName" (CN=Nombre de máquina) dejaría de ser compatible con el RFC 2818 (campo utilizado en un certificado para el cifrado TLS ) por sí solo para permitir el cifrado TLS y forzar al menos un atributo SAN del sistema de nombres de dominio (DNS) con el tiempo. Con estos esfuerzos como solución, y mientras se abordaban las interrupciones, se presentó otro problema.
Reestructuración organizativa sobre cumplimiento y expedición de certificados
Tanto los administradores como los responsables de certificados se enfrentarían ahora a nuevos retos a medida que avanzaran en la adopción de estas mejores prácticas en la organización. Durante muchos años se habían definido procesos previos y se había automatizado la emisión de certificados. Algunos de estos procesos adoptados se remontan a mayo de 2000, cuando todavía se aceptaba el atributo "CommonName" para el cifrado TLS . El equipo de soporte de CSS documentó varios casos de uso y procedimientos de clientes. El equipo de soporte de CSS documentó varios casos de uso y procedimientos del cliente. Gracias a los consejos del cliente, los expertos internos en infraestructura de clave pública (PKI) y los hallazgos del equipo de desarrollo, CSS pudo generar una solución viable en torno a los procesos de PKI y certificados existentes disponibles en la nueva versión de la plataforma de gestión de certificados digitales y PKI líder del sector, CMS 5.0.
Resolver sin problemas los problemas de emisión de certificados y cumplimiento de la normativa
Sin fisuras es realmente la palabra clave aquí. Con la infraestructura y las políticas de PKI existentes y de nueva creación, la necesidad de poder solucionar un problema sin tener que "arrancar y reemplazar" procesos o PKI durante mucho tiempo para solucionar un problema que ya se está hundiendo es primordial. ¿Cómo puede aprovecharse el CMS para remediar esta situación?
Cumplimiento forzoso en la inscripción de certificados
En la mayoría de los casos, para detener un problema en curso primero tenemos que darnos cuenta de dónde proviene el problema y dejar de alimentarlo. Con el parche de Chrome 58, se descubrió que el culpable era la inscripción inicial de certificados. Los equipos del servidor web y del administrador tendrían que dejar de inscribir y emitir certificados que no fueran reclamados. Suena bastante fácil de hacer cumplir, pero el desafío llegó con organizaciones más grandes donde los procesos y la automatización se habían definido durante años. También es fácil que se emitan certificados sin cumplir el nuevo requisito de atributos SAN. CSS ha colocado una opción en CMS 5.0 que no permitirá la inscripción para un certificado en ninguna autoridad de certificación (CA) en particular definida en cualquiera de sus portales CMSAdminEnroll (función de CMS 5.0 utilizada para emitir PFX y CSR).
Figura - 2
Esto crea un límite de conformidad sin fisuras utilizando el producto CMS 5.0 como un simple interruptor de encendido y apagado en una CA determinada a la que se delegan operaciones para la inscripción (CA definida en CMS para la inscripción). Así, si cualquier emisión se realiza a través del portal CMSAdminEnroll, CMS fallará cualquier intento de emitir ese certificado que no tenga al menos una entrada DNS SAN.
Emisión forzada de un certificado SAN mediante módulo de directivas
Para ir un paso más allá, CSS también ha creado un módulo de política de CA que añade automáticamente al menos una SAN a una solicitud de certificado.
Los módulos de directivas son programas que reciben solicitudes de los servicios de certificación, las evalúan y especifican propiedades opcionales de los certificados que se crean para satisfacer dichas solicitudes.
Figura - 3
Para ello, se instala el manejador de políticas RFC 2818 en la CA y luego se definen plantillas particulares en la configuración del manejador. Cuando se recibe una solicitud de certificado en la CA para esa plantilla en particular, se toma el atributo "CommonName" de la solicitud de certificado y se coloca como atributo SAN en DNS haciendo que el certificado sea compatible.
Figura - 4
Automatización perfecta de SAN Recapitulación de la conformidad
Abordamos algunos de los puntos problemáticos de la generación de atributos SAN y la integración perfecta que ayudaría a llevar las riendas de la emisión y el cumplimiento. También presentamos la última versión de CMS 5.0 (entradas de reclamaciones forzosas y módulo de políticas) que puede utilizarse para ayudar a hacer posible la realidad de resistir a las interrupciones y al tiempo de inactividad de las aplicaciones.
Otras grandes características y mejoras de CMS 5.0:
- flujos de trabajo de renovación de certificados más sólidos
- compatibilidad con la gestión de certificados NetScaler
- opciones mejoradas de protección de bases de datos
- planos de agentes
- web API (interfaz de programación de aplicaciones) PowerShell SDK
- revisión completa de la interfaz de usuario
Las nuevas funciones ayudan a hacer de la plataforma de gestión de certificados digitales y PKI de CSS, CMS, no sólo una necesidad, sino una potencia en cualquier organización o empresa.
