Trabajando con Certificados en Windows Server 2008 (2)

En una red Windows Server 2008 una CA es un servidor con el rol de AD CS instalado. Una CA puede emitir certificados, revocarlos y publicar la lista de certificados revocados (CRL) e información AIA (Authority Information Access) para que los certificados emitidos a usuarios, máquinas y servicios puedan ser validados.

Básicamente dentro de una implementación PKI contamos con dos tipos de CAs:

  • CA Raiz: Es el tipo de CA más confiable en la infraestructura PKI. Todos los certificados emitidos dependerán jerárquicamente del certificado de esta CA. Dispone de un certificado auto firmado y puede emitir certificados para otras CAs. Habitualmente esta CA suele usarse para emitir únicamente certificados a otras CAs dentro de la jerarquía.
  • CA subordinada: Este tipo de CA dispone de un certificado firmado por una CA Raiz y habitualmente es la que se utiliza para emitir certificados finales a usuarios, máquinas, equipos u otras CAs. En entornos de alta seguridad es habitual desplegar estructuras PKI con tres niveles jerárquicos o más. Es aconsejable implementar modelos jerárquicos ya que nos van a proveer un mayor grado de seguridad, flexibilidad y escalabilidad.

Escenarios de uso de CAs jerárquicas:

    

 

Como podemos ver en el gráfico podemos desplegar nuestra estructura PKI para acomodarla a nuestras necesidades. Podemos crear CAs dentro de una implementación PKI para distribuir certificados en base a ubicaciones, tipos de uso de los certificados, departamentos, etc…

Aunque el nombre de Active Directory Certificate Services puede hacernos pensar que solamente podemos instalar este rol si contamos con una implementación de Directorio Activo esto no es así. De hecho podemos instalar Enterprise CAs (integradas al directorio activo) o Stand-Alone CAs (sin integrarlas al directorio activo). Las Stand-Alone CAs se pueden implementar tanto en servidores que formen parte de un dominio como de un grupo de trabajo, sin embargo las Enterprise CAs solamente las podremos implementar sobre servidores que pertenezcan a un dominio de Directorio Activo). Una de las ventajas más importantes de implementar Enterprise CAs es que podremos gestionar muchos aspectos de la gestión de los certificados mediante las Group Policies y podremos sacar partido a las plantillas de certificados.

Uno de los aspectos más importantes cuando estamos desplegando una estructura PKI es la seguridad. Recordemos que vamos a usar los certificados para garantizar la identidad de servidores, usuarios y servicios por lo que la seguridad es primordial. Una recomendación importante es que la CA Raiz se implemente sobre un servidor que no pertenezca al dominio y como Stand-Alone CA. A continuación se instalarán las CAs Subordinadas como Enterprise CA pero con certificados emitidos por la Stand-Alone CA. Una vez  terminada toda la configuración inicial e instaladas las CAs subordinadas de primer nivel es conveniente mantener el servidor con la CA Raiz off-line. Una práctica para economizar costos es que el servidor con la CA Raiz se instale sobre un servidor virtual utilizando Hyper-V o Virtual Server, de esta forma podremos mantener este “servidor” en un lugar seguro.

También podemos implementar estructuras complejas donde creamos CAs que gestionan certificados cruzados para que los certificados emitidos por una CA en particular automáticamente se firmen por más de una CA como podemos ver en el siguiente gráfico.

  

 

El tipo de implementación que vayamos a hacer dependerá de la complejidad que necesitemos para gestionar la emisión de certificados.

Es importante resaltar que la implementación de una infraestructura PKI debe de estar precedida de una buena planificación, lo que conseguiremos mediante una consultoría adecuada. Siempre debemos de mantener enfocadas la necesidad de uso de la PKI y la seguridad. La primera establecerá las necesidades de uso de los certificados y su gestión y la segunda determinará la jerarquía y los controles de seguridad a implementar.

Veamos como implementar una CA para entornos reducidos de gestión de certificados:

Vamos a partir de una instalación donde usaremos un servidor stand-alone para crear nuestra CA Raiz. Este tipo de implementaciones además de permitirnos almacenar de forma segura nuestra CA Raiz también nos da la flexibilidad de usar CAs Subordinadas tanto integradas al Directorio Activo (Enterprise) como Stand-Alone dependiendo de como queramos gestionar nuestros certificados. Una vez creada nuestra CA Raiz podríamos crear dos subordinadas, una para la emisión de certificados relacionados con el acceso al directorio activo y otra para emisión de certificados de uso público, como pueden ser los certificados para la publicación de servidores web seguros en internet.

Veamos como instalar el rol de AD CS en Windows Server 2008 para implementar nuestra CA Raiz:

Antes de comenzar con todo el proceso de implementación debemos de ser conscientes de tres puntos muy importantes: El primero es la distribución del certificado público de nuestra CA Raiz, el segundo es la publicación de las rutas AIA (Authority  information Access) y RDP (Revocation List Distribution Point), y el tercero pero no menos importante, como vamos a implementar los Agentes de Recuperación de Claves (KRA – Key Recovery Agent)

Antes de proceder a la instalación debemos de ser conscientes de que al servidor donde vayamos a habilitar el rol DS CA no le podremos cambiar ni su nombre ni podremos unirlo ni separarlo de un dominio después de habilitada la CA.

En este ejemplo de implementación utilizaremos dos servidores instalados con Windows Server 2008 – Enterpise Edition:

SRV-RootCA: Servidor stand-alone donde instalaremos la CA Raiz. Este servidor pertenece al grupo de trabajo GW-PKI

DC1: Controlador de dominio del dominio EMBOSA. En este servidor instalaremos una CA Subordinada integrada al Directorio Activo. También usaremos los servicios web de este servidor como rutas para publicar los AIA y los RDP de las dos CAs.

Pues manos a la obra:

En primer lugar asegurarnos de que los nombres del servidor y del grupo del trabajo son los que habíamos elegido y que también nos aseguramos de agregar el sufijo de dominio para el FQDN.

 

 

Comenzamos por instalar los servicios DS CA en el servidor SRV-RootCA, para ello haremos uso del Administrador del Servidor:

Seleccionamos la opción de Agregar Servicios de Certificate Services de Active Directory

En este servidor será necesario instalar los servicios web de la entidad emisora para poder hacer solicitudes de los certificados de las entidades subordinadas mediante esta interface, por lo tanto debemos de marcar la opción Inscripción Web de Entidad de Certificación.

 

Para que funcionen los servicios web de la CA es necesario instalar también el IIS y el asistente así nos lo hace saber. Simplemente hacemos clic sobre Agregar servicios de función Requeridos y automáticamente se instalará el IIS configurado con todos los componentes necesarios para que podamos usar los servicios web de la CA. Espectacular ¿no?

Bien, comencemos con la configuración inicial la CA Raiz. Como podemos ver al continuar con el asistente dado que este servidor no pertenece a un dominio solamente nos permite hacer una instalación Independiente (Stand-Alone)

La siguiente pregunta es el tipo de CA a implementar. Seleccionamos CA Raiz.

La siguiente cuestión hace referencia a el certificado que vamos a usar. Si es la primera vez que instalamos una CA tendremos que crear una nueva clave privada. Si por el contrario, ya disponemos de una clave privada anterior de nuestra CA y lo que estamos haciendo es restaurándola tendremos que usar la opción de usar una clave existente.

Y llegamos a la parte donde decidiremos los servicios criptográficos a utilizar. Para crear una clave privada es necesario definir el CSP (Proveedor de Servicios de Cifrado) que usaremos, así como la longitud de caracteres que tendrá la clave y el algoritmo de funciones de Hash. Nosotros usaremos los valores por defecto para el CSP y para el algoritmo de Hash, pero dado que este va a ser una CA Raíz vamos a cambiar la longitud de clave a 4096. Recordemos que cuanto mayor sea la clave a usar mayor seguridad estaremos implementando pero también mayor capacidad de cálculo necesitaremos para cifrar y descifrar. En las entidades raíz es conveniente agregar claves largas para sus certificados dado que habitualmente estos certificados suelen tener mayor vigencia que cualquier otro.

A continuación asignamos un nombre por el cual queremos que se reconozca a nuestra CA.

y establecemos la duración del certificado. A mayor duración de un certificado mayor vulnerabilidad. Para los entornos de baja o media seguridad es suficiente con 10 años. Para entornos más sensibles es conveniente bajar esta duración. También debemos de ser conscientes de las fechas de renovación de estos certificados y también de que los certificados que emitan las CAs no tengan una vigencia mayor a la del certificado de la CA. Para que esto no suceda es recomendable renovar los certificados de las CAs cuando llegan al 50% de su vida útil.

asignamos la ruta donde queremos almacenar la base de datos y sus archivos log:

A continuación aceptamos los valores por defecto de la instalación del IIS y comenzamos con la instalación.

Una vez terminada la instalación ya dispondremos de nuestra CA Raíz operativa.

Primeras acciones a realizar una vez completado el proceso de instalación:

Respaldar la clave privada de nuestra CA: Esto nos permitirá recrear nuestra CA en caso de desastre.

Accedemos a la herramienta de administración de nuestra CA usando el complemento Certification Authority que encontraremos en las herramientas administrativas. haciendo clic con el botón derecho sobre el nombre de nuestra entidad y accediendo a Todas las Tareas del menú contextual seleccionamos Realizar copia de seguridad de la entidad de certificación.

haremos uso del asistente para hacer una copia de respaldo del certificado privado de nuestra CA: En este punto no haremos todavía copia de seguridad de la base de datos. Lo haremos una vez que se hayan emitido los certificados de las CAs subordinadas.

es importante que asignemos una contraseña al archivo:

El archivo generado debe de almacenarse en lugar seguro y separado del servidor. En caso de desastre de nuestro servidor podremos recrear nuestra CA mediante este certificado.

El siguiente paso será obtener el certificado público de nuestra CA para poder distribuirlo a todo el que quiera confiar en los certificados emitidos por nosotros. para ello accedemos a la página web de nuestra CA mediante el URL por defecto: http://localhost/certsrv

En esta página web usaremos el último link: Descargar un certificado de CA, cadena de certificados o lista de revocación.

Simplemente seleccionamos la opción de Descargar certificado de CA y lo almacenamos en un archivo:

Este certificado habrá que instalarlo en todas las máquinas que necesiten confiar en todos los certificados emitidos por esta CA y todas sus subordinadas. Para ello es necesario incluirlo en el contenedor de Entidades de certificación raíz de confianza.

Como ya comentamos al principio de esta serie de posts, este servidor lo vamos a mantener fuera de línea una vez que tengamos funcionando toda nuestra implementación por lo que tendremos que publicar las rutas AIA y CDP en algún servidor web que vaya a estar disponible permanentemente. Si vamos a hacer uso de nuestros certificados en internet tendremos ´que publicar ese servidor en internet y asegurarnos que incluimos rutas que se puedan acceder tanto desde nuestra intranet como desde internet, sobre todo cuando no coinciden  los nombres de nuestros dominios internos con el dominio o dominios que usamos en internet.

En este caso el dominio interno y el dominio de internet son iguales por lo que será suficiente incluir una sola ruta. Para los casos donde los dominios sean diferentes tendremos que incluir una ruta para cada uno de ellos.

Para agregar las rutas AIA y CDP es necesario que hayamos planificado de antemano en que servidor o servidores vamos a publicar esta información. En este ejemplo vamos a usar el servidor donde después instalaremos nuestra CA Subordinada. Podría ser cualquier otro servidor web, no es necesario que tenga instalados los servicios de CA.

Es necesario realizar este paso antes de emitir ningún certificado porque esta información se agrega a los certificados.

Modificación de las rutas AIA y CDP:

Si accedemos a las propiedades de nuestra CA y hacemos clic sobre la pestaña Extensiones podremos ver que ya existen unas rutas de publicación para esta información generada en base a variables pero todas apuntando a la máquina local.

Vamos a agregar una ruta http para CDP y otra para AIA pero apuntándolas al servidor web que tenemos en el otro servidor. Para ello podemos servirnos de la información que tenemos de otras rutas que estén creadas y del uso de las variables. Por ejemplo, empecemos por la ruta AIA. Desde esta misma pantalla de propiedades y en la pestaña extensiones, En el cuadro Seleccionar Extensión elegimos Acceso a la Información de Entidad (AIA). Podremos copiar la ruta http que ya existe para crear la nuestra, que quedaría así: hacemos clic en agregar y en Ubicación escribimos: http://dc1.embosa.com/certenroll/, ahora para completar la ruta vamos a hacer uso de las variables: en la lista Variables buscamos <Nombre DNS del Servidor> y hacemos clic en Insertar y en la ruta después de haber insertado la variable del nombre de servidor incluimos un guión bajo “_”. A continuación insertaremos dos variables seguidas: <Nombre de CA><Nombre de Certificado> y terminamos la línea agregando la extensión del archivo .crt.

Debería de quedarnos una ruta tal que:

http://dc1.embosa.com/certenroll/<Nombre DNS del Servidor>_<Nombre de CA><Nombre del Certificado>.crt

En este caso estamos usando las rutas por defecto que utiliza la CA pero si nosotros queremos publicar esta información en una ruta diferente no hay inconveniente.

Cuando lo tengamos hacemos clic en Aceptar

De nuevo en la ventana de propiedades y con nuestra ruta seleccionada nos aseguramos de marcar las casillas que incluyen la ruta en los certificados.

Ya también vamos a hacer uso de un servidor OCSP (que explicaremos más adelante) conviene tambien agregar una ruta nueva HTTP a la información de AIA. En nuestro la ruta a agregar será: HTTP://dc1.embosa.com/ocsp

Repetimos el proceso para la ruta CDP. En la pestaña Extensiones seleccionamos esta vez Puntos de Distribución de lista de revocación de certificados (CDP) y hacemos clic en agregar.

Usando la misma técnica anterior tendremos que construir una ruta tal que:

http://dc1.embosa.com/certenroll/<nombre de CA><Sufijo de nombre de lista CRL><Diferencias entre listas CRL permitidas>.crl

Y de nuevo, con la ruta seleccionada nos aseguramos de que están marcadas las casillas que incluyen esta ruta en los certificados:

Haciendo clic en Aceptar se nos pedirá reiniciar los servicios de la CA. Aceptamos para asumir los cambios.

Pues ya tenemos nuestra entidad emisora raíz lista y funcionando. El siguiente paso será crear una entidad emisora subordinada integrada al Directorio Activo, pero eso lo veremos en el próximo post.

About these ads
Esta entrada fue publicada en PKI. Guarda el enlace permanente.

5 respuestas a Trabajando con Certificados en Windows Server 2008 (2)

  1. Juan Perez dijo:

    excelente aporte!! gracias.

  2. Paqui dijo:

    Muy bueno, gracias.

  3. Omar dijo:

    Que tal, muchas gracias por tu aporte, no entiendo como hacer para realizar esto: “Para ello es necesario incluirlo en el contenedor de Entidades de certificación raíz de confianza” Podras ayudarme? Gracias.

    • jbouzada dijo:

      Omar,
      Debes de abrir una consola MMC con privilegios de administrador, cargas el complemento de los certificados. Cuando se te pida indicas que quieres administrar los certificados de la cuenta de máquina. Una vez cargado el complemento verás un contenedor que se llama “Entidades de certificación raíz de confianza”. Ahí es donde debes de importarlo.

      Saludos.

  4. juan dijo:

    Excelente! Lo estoy siguiendo paso a paso y tambien sirve para Windows server 2012.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s