Certificate Services en Windows Server 2012 r2 Parte 2
Después de la introducción e instalación básica del anterior artículo, seguimos con servicios de certificados de Windows Server 2012 R2.
En la instalación básica, hemos instalado una entidad emisora de certificados raíz, ya que partíamos de la base de que nunca habíamos usado Certificate Services.
Hay que comprender la base de una infraestructura de clave pública o PKI, la confianza, para comprender todos los demás conceptos subyacentes. Cuando accedemos a un servidor HttpS(Secure) entre otras cosas, el certificado digital lo que hace es garantizar que ese servidor web es quien dice o parece ser, pero quien lo dice? La entidad emisora de certificados. Si la entidad emisora de certificados se llama Casa Real de la Moneda y Timbre de España, suena a serio. Si lo firma Verisign, también suena serio. Dentro de los limites de nuestra organización, los equipos y usuarios confiaran en los certificados emitidos por nuestra entidad emisora de certificados. Cuando un servicio ofrece un certificado como medida de autenticación, como es el caso de las comunicaciones cifradas con IPSEC, el cliente debe poseer un certificado válido de cliente, aparte del certificado válido de servidor, para que este confie en el cliente.
Imaginemos una infraestructura de empresa internacional, con sedes repartidas por todos los continentes. Podría existir una entidad emisora de certificados global para la empresa, por ejemplo CA.empresa.com pero por motivos de seguridad y disponibilidad se delegue la gestión de los certificados a una entidad emisora de certificados subordinada, que se hará cargo de todas las transacciones y validaciones de certificados, por ejemplo repartida por continentes. Una costumbre habitual es desconectar la entidad emisora de certificados raíz para preservar la seguridad de la clave privada raíz. Como veis en la imagen anterior del certificado para https de Google, existe una ruta de certificación que representa la jerarquía empleada por distintas entidades de certificación. La entidad emisora de certificados raíz será siempre la que posea en última instancia un servicio auto-firmado.También informa de la validez del certificado y su caducidad. Os suena la advertencia en los navegadores de esta página no es segura cuando intentamos entrar a un servicios https? Suele ser por la caducidad del certificado o la imposibilidad de validar la "confianza" de la entidad emisora de certificados que expidió el certificado.
Google +
En la instalación básica, hemos instalado una entidad emisora de certificados raíz, ya que partíamos de la base de que nunca habíamos usado Certificate Services.
Hay que comprender la base de una infraestructura de clave pública o PKI, la confianza, para comprender todos los demás conceptos subyacentes. Cuando accedemos a un servidor HttpS(Secure) entre otras cosas, el certificado digital lo que hace es garantizar que ese servidor web es quien dice o parece ser, pero quien lo dice? La entidad emisora de certificados. Si la entidad emisora de certificados se llama Casa Real de la Moneda y Timbre de España, suena a serio. Si lo firma Verisign, también suena serio. Dentro de los limites de nuestra organización, los equipos y usuarios confiaran en los certificados emitidos por nuestra entidad emisora de certificados. Cuando un servicio ofrece un certificado como medida de autenticación, como es el caso de las comunicaciones cifradas con IPSEC, el cliente debe poseer un certificado válido de cliente, aparte del certificado válido de servidor, para que este confie en el cliente.
Imaginemos una infraestructura de empresa internacional, con sedes repartidas por todos los continentes. Podría existir una entidad emisora de certificados global para la empresa, por ejemplo CA.empresa.com pero por motivos de seguridad y disponibilidad se delegue la gestión de los certificados a una entidad emisora de certificados subordinada, que se hará cargo de todas las transacciones y validaciones de certificados, por ejemplo repartida por continentes. Una costumbre habitual es desconectar la entidad emisora de certificados raíz para preservar la seguridad de la clave privada raíz. Como veis en la imagen anterior del certificado para https de Google, existe una ruta de certificación que representa la jerarquía empleada por distintas entidades de certificación. La entidad emisora de certificados raíz será siempre la que posea en última instancia un servicio auto-firmado.También informa de la validez del certificado y su caducidad. Os suena la advertencia en los navegadores de esta página no es segura cuando intentamos entrar a un servicios https? Suele ser por la caducidad del certificado o la imposibilidad de validar la "confianza" de la entidad emisora de certificados que expidió el certificado.
En este caso el problema es que Netgear firma su certificado, pero... quien es Netgear en el "world wide web" para que yo confíe en ellos?
En la instalación básica que hicimos en el primer artículo dejamos la ubicación por defecto para almacenar la clave privada de la CA. Para organizaciones complejas existe la posibilidad de utilizar proveedores criptrograficos externos, elementos hardware, para proporcionar el almacenaje de nuestra valiosa clave privada. Se denominan HSM. No solo almacenan la clave privada, sino que algunos son capaces de cifrar las comunicaciones que así lo requieran, para proporcionar un rendimiento superior al uso de CPU en un servidor corriendo ya un sistema. Un ejemplo de un appliance de Realsec.
Otro dato interesante a tener en cuenta en la ubicación que le demos a la clave privada es el rendimiento. Cuando hablamos de Certificate Services no solo hablamos de certificados, sino de todos los procesos de gestión asociados. Hay varios ficheros, a modo de base de datos (transacciones, datos, logs) implicados en la gestión, por lo que debemos planear la ubicación separada de los ficheros en discos duros rápidos para evitar cuellos de botella en este aspecto, como hacemos con los ficheros de nuestras bases de datos "Oracles, Sql Server y demás". La ubicación de estos ficheros la tenemos en la siguiente rama del registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
Los ficheros son:
- DBDirectory
- DBLogDirectory
- DBSystemDirectory
- DBTempDirectory
El proceso para cambiar la ubicación de los ficheros de la base de datos de Certificate Services implica copiar manualmente el fichero original a su nueva ubicación, detener el servicio, modificar la clave del registro e iniciar el servicio.
El nombre que le dimos a la CA de ejemplo fue modificado por una regla, no puede tener el mismo nombre NETBIOS ni DNS del servidor. No sé si es un problema con la resolución de nombres o una medida de seguridad extra, pero en el caso de que use una infraestructura PKI de otro fabricante o tecnología, no uses el mismo nombre FQDN para la entidad emisora de certificados para evitar dar más información a un supuesto atacante de la que debiera. Por ejemplo, si tu server se llama CA.miempresa.local la CA puede llamarse ENTIDAD CERTIFICADORA DE MIEMPRESA sin dar más datos.
Importante recordar una regla básica, si en el principio del artículo hablábamos de confianza, no podemos cambiarle el nombre al servidor que alberga los servicios de Certificate Server por las razones obvias que os imaginais: si yo confío en un certificado emitido para "servidor x" no es lo mimos que para "servidor y".
Cuando instalamos un servidor miembro ( no se recomienda instalar Certificate Services en un controlador de dominio) para ser la Raíz CA de la empresa, vamos a tener un problema si queremos mantener este servidor OFFLINE por seguridad. Simplemente el echo de tener más de 30 días el servidor miembro desconectado nos va a generar problemas por la caducidad automática de la clave de la cuenta de equipo dentro del dominio Active Directory. Podríamos instalar la entidad emisora de certificados raíz en un grupo de trabajo, pero no estaríamos usando la capacidades de Certificate Services integradas en Active Directory.
Por hoy es suficiente con Certificate Services en Windows Server 2012 R2. Por cierto, SI, trae botón de Inicio.
Como siempre gracias por leerme y espero que os guste. Atentos a próximas entregas.
***
He empezado la casa por la ventana, instalando el role en el servidor en el primer artículo para que la gente comprenda que se pueden hacer las cosas de varias maneras, leyendo, informándose y haciéndose la cosas medio bien, o haciendo Siguiente Siguiente Siguiente. He aquí la diferencia entre hacer las cosas mal, o medio bien xD
***
Google +
