[ARTICULO] Active Directory Certificate Services | Conceptos y Fundamentos

19 minutos de lectura

Last Updated on 22 agosto, 2017 by Pablo Ariel Di Loreto

Una Infraestructura de Clave Pública va más allá de un producto específico de Microsoft o un rol de Windows Server. Es un completo sistema que nos permite segurizar ciertas operaciones que se realizan en Internet e, incluso, en una Intranet.

En este artículo recorreremos los fundamentos más básicos de una Infraestructura de Clave Pública (PKI), como así también analizaremos sus componentes principales.

Posteriormente, veremos cómo estos componentes pueden ser implementados a través del rol Active Directory Certification Services en Windows Server.

Tabla de Contenidos

1 Introducción
2 Desarrollo
- 2.1 Infraestructura de Clave Pública (Public Key Infrastructure)
- 2.2 Active Directory Certification Services
3 Conclusiones
4 Referencias y Links
5 Publicaciones Relacionadas

Introducción

Objetivo y Alcance

El presente documento tiene como objetivo:

Explicar conceptos generales de Infraestructuras de Clave Pública.
Conocer como implementa Microsoft una Infraestructura de Clave Pública a través de Active Directory Domain Services.

El alcance de este artículo consiste en:

Recorrer los conceptos estándares de Infraestructuras PKI en alto nivel.
Conocer las posibilidades PKI de Active Directory Domain Services en Windows Server 2012 en alto nivel.

No obstante, muchos de los conceptos son aplicables a versions anteriores de Windows Server.

Audiencia

Este documento está dirigido a Consultores, Profesionales IT y personas que desarrollan tareas de Consultoría, Administración y Soporte o que simplemente están interesados en aprender nuevas cosas.

Comentarios y Corrección de Errores

Hemos realizado nuestro mejor esfuerzo para no cometer errores, pero al fin y al cabo somos seres humanos. Si deseás reportar algún error o darnos feedback de qué te pareció esta publicación, por favor no dejes de comunicarte con nosotros a través de correo electrónico a la siguiente dirección: info@tectimes.net.

Desarrollo

Infraestructura de Clave Pública (Public Key Infrastructure)

Introducción a Infraestructuras de Clave Pública

Por concepto, una Infraestructura de Clave Pública (o «Public Key Infrastructure» en inglés, o PKI como abreviatura) es un sistema que permite ejecutar con garantías ciertas operaciones criptográficas tales como: cifrado, firma digital y no repudio de las transacciones electrónicas.

Este «sistema» no es un software en particular o un rol específico de servidor. Involucra hardware, software, políticas y procedimientos de seguridad. Además, integra a diversas entidades sobre las cuales se soporta el sistema. Estas entidades, como veremos luego, tienen un rol fundamental.

Con el término «Infraestructura de Clave Pública» no queremos referirnos al uso de algoritmos de clave pública en comunicaciones electrónicas. En sí mismo, no es necesaria la existencia de métodos específicos de Infraestructura de Clave Pública para usar algoritmos de clave pública. Esta aclaración puede resultar confusa inicialmente, pensando que PKI y algoritmos de clave pública es lo mismo, pero un aspecto importante de la criptografía de clave pública es que seguridad de esta infraestructura debe descansar en la clave y no en el algoritmo en sí mismo que lo implemente. Por ello mismo, cuando hablamos de PKI nos estamos refiriendo a los componentes anteriormente mencionados, y no en sí mismo a un algoritmo de clave pública.

En esta introducción hemos dicho muchas palabras que quizás para algunos lectores sean nuevas o generen confusión: certificados digitales, entidades de certificación, autoridades de registro, criptografía, clave pública, etc. ¿Qué es cada una de estas cosas? No os preocupéis, lo veremos en breve. Por ahora concentrémonos en entender globalmente qué es una infraestructura PKI.

Usos de la tecnología PKI

Más allá de sus componentes y participantes, hoy en día el uso de Infraestructuras de Clave Pública (PKI) en nuestra tarea de administradores de sistemas es muy pero muy frecuente, aunque a veces no seamos conciente de ello.

En la Argentina, para dar un ejemplo puntual, el organismo público llamado AFIP (Administración Federal de Ingresos Públicos) utiliza Infraestructura de Clave Pública para autenticar, validar y segurizar muchas transacciones, como por ejemplo para interactuar con sistemas de facturación electrónica de los contribuyentes y generar facturas electrónicas on-line. Todo esto está soportado por hardware, software de distintos fabricantes, no exclusivamente Microsoft, y procesos varios dentro de una Public Key infrastructure.

Algunos productos de Microsoft que utilizan uno o varios (o todos!) componentes de una Public Key Infrastructure y que posiblemente utilizamos frecuentemente son, por ejemplo: Active Directory, Exchange, Lync, Windows Intune, etc.

El uso de Infraestructura de Clave Pública (PKI) tiene muchos objetivos, pero todos ellos están orientados a autenticar identidades, segurizar canales de comunicación o los mensajes en sí mismo. Veamos usos puntuales de una infraestructura PKI:

Autenticar la identidad (login).
Segurizar de canales de comunicación.
Cifrar datos digitales.
Firmar digitalmente datos.
Garantizar el no repudio.

Como podemos inferir, podría decirse que cualquier intento de segurización en Internet requiere de una Infraestructura de Clave Pública ó PKI en inglés. Una vez entendido este concepto global, vamos a intentar explicar los principales componentes de esta infraestructura y para qué sirven.

Componentes de una Infraestructura de Clave Pública

Vamos a recorrer rápidamente algunos de los elementos más comunes de una Infraestructura de Clave Pública (PKI), los cuales utilizaremos más adelante en este artículo cuando comencemos a describir los servicios de Windows Server que nos permiten dar soporte a Infraestructuras de Clave Pública propias. Estos elementos son:

Certificados de Identidad.
Autoridad de Certificación.
Autoridad de Registro.
Lista de Revocación de Certificados.

Certificados de Identidad o Digital (Digital Certificate)

Un certificado de identidad, o certificado digital es quizás el elemento que más fácilmente puede identificarse (por su visibilidad y utilización) por los administradores de sistemas. Un certificado digital es un es un documento en forma de archivo firmado electrónicamente por un prestador de servicios de certificación que confirma la identidad de una persona, servicio, servidor, etc.

Autoridad de Certificación (Certificate Authority)

Una Autoridad de Certificación (CA por sus siglas en inglés) es una entidad de confianza que es la responsable de emitir o revocar certificados digitales. Es una entidad que, a través de su confianza, da legitimidad a la relación entre una clave pública con la identidad de un usuario o un servicio.

Autoridad de Registro (Registration Authority)

Una Autoridad de Registro (RA por sus siglas en inglés) tiene la función de controlar la generación de certificados para los miembros de una Entidad. Es quién realiza la petición del certificado a la Autoridad de Certificación (CA).

Lista de Revocación de Certificados (Certificate Revocation List)

La Lista de Revocación de Certificados (CRL por sus siglas en Inglés) es un repositorio con los números de serie de los certificados que ya no son válidos y que alguna vez una Autoridad de Certificación emitió.

Ahora bien, en este ítem nos vamos a detener para explicarlo y ejemplificarlo. ¿Por qué son necesarias estas listas? Normalmente una CA (Certification Authority) emite certificados que tienen vigencias que van desde el año hasta los 10 años, en algunos casos y en base a algunas legislaciones. Cuando la fecha actual sobrepasa la fecha de vigencia, el certificado ya no es válido.

Ahora bien, en algunos casos es necesario que un certificado digital, que aún no venció, deje de ser válido. Por ejemplo:

Cambios en empresas: la empresa cambió de nombre o cerró.
Certificados que ya no son válidos porque contienen información errónea o que se ha modificado.
Robo de identidad.
Orden judicial.

En estos casos, ¿cómo se da cuenta al público que el certificado ya no es válido, si su fecha aún es válida y si supongamos sigue instalado en algún servidor? Muy bien, allí entran en escena las Listas de Revocación de Certificados (CRL). Cada Autoridad de Certificación debe publicar estas listas y dejarlas disponibles para las consultas de, por ejemplo, navegadores web, sistemas de información, etc.

Active Directory Certification Services

Introducción

Microsoft implementa la Infraestructura de Clave Pública (PKI) a través de «Active Directory Certificate Services». Esta implementación es un modelo jerárquico de entidades de certificación (conocido como «Hierarchical CA Model» desde un punto de vista más técnico). Esto significa que puede existir una entidad raíz y entidades subordinadas que emitan certificados, y la confianza en la entidad raíz significa confiar en todas las entidades subordinadas que ésta tenga.

Aquí explicaremos, en alto nivel, cómo Microsoft implementa esta solución y que servicios dentro del rol «ADCS» (viene de Active Directory Certificate Services) se incluyen. Como veremos a continuación, re-utilizaremos muchos conceptos ya explicados en la presentación general de infraestructuras PKI.

Jerarquías de Entidades de Certificación

Hemos explicado que la implementación de infraestructuras PKI de Microsoft es un modelo jerárquico de entidades de certificación (conocido como «Hierarchical CA Model»).

La implementación más simple tendrá una sola CA (Certification Authority). Sin embargo, existe la posibilidad de implementar soluciones escalables que contengan múltiples Cas definidas en roles principales e hijas.

Entidades de Certificación Raíz (Root Certification Authority)

En lo alto de la jerarquía se encuentra la Entidad de Certificación Raíz, o Root CA. Es el mayor nivel de confianza dentro de una Infraestructura de Clave Pública dentro de la organización. Si ésta se encuentra comprometida en la seguridad, todas las Entidades «subordinadas» lo estarán.

Los certificados que emite una Entidad de Certificación Raíz pueden ser usadas para muchos fines. Sin embargo, en una infraestructura donde existen muchas otras CAs «subordinadas» (como veremos en breve), las Root CA se suelen utilizar casi exclusivamente para emitir certificados para las otras CAs.

Entidades de Certificación Subordinadas (Subordinate Certification Authority)

Realmente éstos son los «caballitos de batalla» de la infraestructura PKI. Las Entidades de Certificación Subordinadas son las que realizan la emisión de certificados para la gran mayoría de necesidades del usuario final. Por ejemplo: protección del correo electrónico, certificados para páginas web, certificados para servidores externos a la infraestructura PKI, etc.

Tipos de Entidades de Certificación

El rol de Active Directory Certificate Services permite la implementación de dos tipos de Entidades de Certificación: independientes y empresariales. Realizaremos una breve reseña para cada una.

Entidades de certificación independientes (Stand-Alone Certification Authorities)

Una Entidad de Certificación Independiente, para comenzar, no requiere de Active Directory Domain Services (ADDS). Se puede utilizar una CA independiente para los siguientes propósitos:

Firmas Digitales
Correo Electrónico protegido mediante S/MIME (extensiones seguras multi-propósito).
Autenticación de Servidor Web Seguro mediante SSL o TLS.

Algunas de las características de una CA independiente son:

Todas las solicitudes de certificados enviadas a la CA se establecen como pendientes, hasta que el administrador de la CA lo aprueba. Este comportamiento es el predeterminado, y no se recomienda cambiarlo. Esto generaría un posible agujero de seguridad.
No se usan plantillas de certificado.
El administrador de la CA debe distribuir explícitamente el certificado de la CA independiente en el almacén raíz de confianza del usuario.

Si bien una CA Independiente no requiere de Active Directory Domain Services, puede instalarse dentro de un dominio. En dicho caso, se tendrán las siguientes funcionalidades extras:

Un administrador de dominio o administrador con derechos necesarios podría publicar el certificado de la CA independiente en el repositorio «Trusted Root Certification Authorities» para todos los usuarios y equipos del dominio.
Una CA Independiente también publicará su certificado y la lista de revocación de certificados (CRL) de Active Directory Domain Services, si es instalado por un administrador de dominio o una cuenta con derechos suficientes de escritura en Active Directory.

Entidades de certificación empresarial (Enterprise Certification Authorities)

Estas entidades están vinculadas y trabajan con Active Directory Domain Services (ADDS). Además de los propósitos que puede usarse una CA Independiente, una CA Empresarial puede utilizarse para:

Firmas Digitales.
Protección de Correo Electrónico mediante S/MIME.
Autenticación de Servidor Seguro mediante SSL y TLS.
Inicio de sesión en dominio utilizando tarjetas inteligentes (Smart Card).

Para instalar una CA Empresarial es necesario tener acceso a Active Directory Domain Services con un usuario que sea miembro del grupo «Administradores de Dominio» o con derechos de escritura en Active Directory.

Algunas de las características de una CA Empresarial son:

Permite exigir la comprobación de credenciales de los usuarios durante el proceso de solicitud de certificado.
Se pueden hacer uso de plantillas.
Cada plantilla de certificados puede tener permisos establecidos en Active Directory para determinar si el solicitante tiene autorización para recibir dicho tipo de certificado que está intentando pedir.
El nombre del sujeto del certificado se puede generar automáticamente a partir de la información de AD DS o puede ser suministrado explícitamente por el solicitante.
Se minimiza la cantidad de información que el usuario debe proporcionar para recibir el certificado solicitado.
Se puede hacer uso de inscripción automática de certificados (autoenrollment).

Adicionalmente, se puede propagar un certificado al almacén de certificados «Trusted Root Certification Authorities» de todos los usuarios y equipos del dominio a través de directivas de grupo (GPOs). Por último, una CA Empresarial permite publicar certificados de usuarios y listas de revocación de certificados (CRL) en Active Directory Domain Services.

Componentes de Active Directory Certificate Services

El rol «Active Directory Certificate Services» tiene ciertos componentes o servicios, a través de los cuales se da vida a la Infraestructura de Clave Pública en Windows Server. Vamos a recorrer rápidamente cada uno de estos servicios basándonos en la versión 2012 de Windows Server.

Certification Authorities

Este servicio posee Entidades Raíz y Subordinadas. Es utilizado para generar certificados a usuarios, computadoras y servicios. Además, es utilizado para administrar la validez de los certificados.

Web Enrollment

Este servicio permite a los usuarios conectarse a un Certification Authority mediante un navegador web para solicitar certificados y recibir las listas de revocación de certificados (CRL).

Online Responder

Este servicio brinda el status de una solicitud de certificado, evalúa el estado de los certificados y envía una respuesta firmada que contiene la información de estado de dicho certificado.

Network Device Enrollment Service

Este servicio (conocido como «NDES») permite a routers u otros dispositivos de red que no tienen una cuenta de dominio, obtener un certificado válido.

Certificate Enrollment Policy Web Service

Este servicio permite a usuarios y computadoras obtener información sobre políticas de inscripción de certificados.

Certificate Enrollment Web Service

Este servicio habilita a usuarios y computadoras a realizar un requerimiento e inscripción utilizando protocolo HTTPS. Cuando se utiliza en conjunto con el servicio «Certificate Enrollment Policy Web Service» se habilitan las inscripciones basadas en políticas para:

Computadoras miembros del dominio no conectadas al dominio.
Computadoras que no son miembros del dominio.

Conclusiones

El concepto de Infraestructura de Clave Pública no engloba un software en particular o un servicio de Windows Server, sino que es mucho más que eso. Es un sistema completo que nos da la posibilidad de ejecutar con garantías ciertas operaciones criptográficas.

A través de este artículo, se ha buscado introducir al lector a los conceptos fundamentales de este tipo de infraestructuras. Si bien este apartado es simplemente una introducción al tema, se puede obtener más información sobre diseño de una PKI y el uso de la criptografía de clave pública a través del National Institute of Standards and Technology (NIST) y del PKIX Working Group perteneciente al Grupo de trabajo de ingeniería de Internet (IETF). Los vínculos a estos recursos de información están en «Referencias y Links» al pie de este artículo.

Microsoft implementa la infraestructura PKI a través del rol «Active Directory Domain Services». Este rol nos provee de una serie de servicios, los cuales hemos repasado brevemente casi al final, que nos brindan la posibilidad de implementar una completa infraestructura de clave pública en ambientes con dominio y sin dominio de Active Directory.

Proporcionaremos, durante las próximas semanas, una serie de tutoriales para ejemplificar la implementación de Active Directory Certificate Services, de modo tal de ir ganando skills sobre esta tecnología.

Referencias y Links

Public Key Infrastructures – Federal PKI: http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/index.html
Public-Key Infrastructure (X.509) (pkix): http://datatracker.ietf.org/wg/pkix/charter/
Public Key Infrastructures: http://technet.microsoft.com/en-us/library/cc725593.aspx
Types of Certification Authorities: http://technet.microsoft.com/en-us/library/cc732368.aspx
Active Directory Certificate Services Overview: http://technet.microsoft.com/en-us/library/hh831740.aspx
Active Directory Certificate Services Role: http://technet.microsoft.com/library/cc753254(v=ws.10).aspx
Active Directory Certificate Services: http://technet.microsoft.com/en-us/windowsserver/dd448615.aspx

Acerca de
Últimas entradas

Pablo Ariel Di Loreto

Director en TecTimes

Mi nombre es Pablo Ariel Di Loreto, nací en Mayo de 1981 y soy oriundo de la Ciudad de Berazategui, Buenos Aires, Argentina.

Mis lazos con la informática comenzaron en el año 1998, cuando tenía 16 años, y comencé a aprender como administrar servidores bajo la plataforma Microsoft (Windows Server, Exchange Server, IIS, y otros) y a realizar desarrollos de software con tecnologías ASP y PHP. Un tiempo más tarde comencé a trabajar ya en forma productiva en la administración de plataformas y desarrollo de software.

Desde hace varios años he tenido una intensa actividad en las comunidades profesionales, a través de eventos, webcasts, foros y publicaciones diversas. En Abril de 2014 fui reconocido como Most Valuable Professional (MVP) por parte de Microsoft, estando hoy reconocido en las especialidades "Windows and Devices for IT" y "Microsoft Azure".

En la actualidad me desarrollo como Service Delivery Manager en Algeiba (http://www.algeiba.com), una compañía que brinda soluciones y servicios tecnológicos, dirigiendo un Equipo de Trabajo de más de 20 personas. También soy el Director de TecTimes, un Portal de Tecnología que nació en el año 2012 como parte de un proyecto personal de contribución a la comunidad tecnológica en español.

Últimas entradas de Pablo Ariel Di Loreto (ver todo)