Trabajando con Certificados en Windows Server 2008 (1)

Nunca fui muy dado a escribir pero creo que ya son horas de ponerse. Desde aquí vamos a tratar de dar luz a algunas de las funciones de los sistemas operativos de Microsoft.

Para empezar veremos las funcionalidades en cuanto a certificados que se incluyen con Windows Server 2008. Para todo el que no esté al día en cuanto a estas cuestiones pues deberíais de saber que los certificados hoy en día en lo que al mundo digital se refiere son fundamentales. Son las señas de identidad que nos permiten establecer conexiones seguras con los servidores dentro de las redes. Los que nos garantizan que los servidores a los que nos conectamos son los que creemos que son y no servidores que tratan de suplantar una identidad para hacerse con información confidencial de nuestra propiedad para luego usarla en contra de nuestros intereses. Pero los certificados no solamente sirven para identificar servidores, los certificados tienen muchas más aplicaciones. Por ejemplo podemos disponer de certificados digitales personales que nos permitan cifrar correo electrónico o archivos en nuestros discos duros. También nos sirven para firmar digitalmente esos mismos correos de manera que la persona que reciba nuestros correos pueda corroborar que nosotros (y solo nosotros) somos los remitentes de ese correo y que nadie pudo haber alterado el contenido del mismo. Otro uso muy común es el de identificación de usuarios en las redes mediante tarjetas inteligentes en las cuales se almacenan los certificados. Así mismo también sirven para firmar digitalmente software. la finalidad de la firma digital en el software (aplicaciones, drivers, etc.) es garantizar que ese software no sufrió modificaciones desde el momento en que se liberó al público y hasta que llegó a nosotros. Esto garantiza que él código que recibimos está libre de virus y de cualquier tipo de malware que algún desaprensivo nos haya querido colar en nuestra máquina. En fín… la cantidad de aplicaciones que tienen hoy en día los certificados digitales es muy variada y seguirá creciendo ya que es uno de los métodos más seguros para identificar servidores, usuarios, servicios e integridad de software, así como proteger información.

La seguridad que ofrecen los certificados digitales la provee el cifrado asimétrico mediante una clave pública y una clave privada que están relacionadas entre si de una forma que es prácticamente imposible descubrir esta relación – no es imposible del todo, pero se necesita una gran capacidad de cálculo y mucho tiempo para llegar a romper la seguridad de unas claves de este tipo – . Pues bien, cada certificado dispone de una clave pública (que se puede distribuir de forma libre y sin afectar a la seguridad) y una clave privada (que el propietario del certificado tiene que mantener a buen recaudo). El propietario de cada certificado debe de distribuir su certificado público para que se le pueda enviar información cifrada. El certificado público se puede distribuir de múltiples formas: publicarlo en una página web, anexarlo a los correos electrónicos formando parte de la firma, enviarlo por messenger, etc… Toda la información que se cifre con el certificado público de un usuario solamente se podrá descifrar con el certificado privado de ese mismo usuario. Por lo tanto solamente el usuario que posea el certificado privado de un certificado podrá acceder a la información. De ahí la importancia de mantener en lugar seguro y protegido nuestros certificados con la clave privada. También el propietario de un certificado podrá usar su certificado privado para firmar digitalmente cualquier tipo de información, de esta manera cualquier persona que tenga el certificado público de esa persona podrá comprobar la autenticidad de la firma y la integridad de la información.

¿Pero como sabemos que un certificado es de confianza? ¿Como podemos saber que el certificado de la persona que se está comunicando con nosotros o el certificado del servidor que estamos accediendo no es un certificado que se haya hecho para tratar de engañarnos? Pues todo es cuestión de confianza, es decir, de confiar en los certificados que emiten las CA (Certification Authority). Las CA son los servidores que se encargan de emitir los certificados que luego se usarán como medios de identificación. En el momento de instalar una CA el software de la CA se encarga de crear un certificado raíz auto firmado. Este es el certificado más importante en una implementación de Claves Públicas (PKI – Public Key Infrastructure). La clave privada de este certificado se usa para firmar digitalmente cualquier certificado que se emita desde esa CA. Dentro de una implementación de PKI puede haber múltiples CA organizadas jerárquicamente, es decir, podemos instalar varias CAs que dependan de la CA Raíz. Todas ellas podrán

1

emitir certificados pero la cadena de confianza de certificados siempre dependerá del certificado de la CA Raíz. Por lo tanto para que nuestro sistema operativo confíe en un certificado se tienen que cumplir tres condiciones:

En primer lugar que nuestra máquina confíe en el la CA que haya emitido ese certificado

En segundo lugar que el nombre que figura en el certificado coincida con el nombre del servidor o la dirección de correo del usuario dependiendo de a quien corresponda ese certificado

y en tercer lugar que el certificado no haya caducado o no haya sido revocado

Existen dos tipos de CAs: las CAs Públicas y las CAs Privadas:

Las CAs Públicas son implementaciones PKI gestionadas habitualmente por empresas privadas (www.verisign.com, http://www.thawte.com/, www.entrust.com, etc.) aunque también existen algunas gubernamentales (http://www.fnmt.es/). Los certificados públicos de estas CAs habitualmente ya vienen incluidos con los sistemas operativos de serie, esto quiere decir que de forma automática nuestro sistema operativo confiará en todos los certificados emitidos por estas CAs. ¿Y son confiables los certificados emitidos por estas empresas? Pues si. Todas ellas tienen procesos rigurosos de emisión de certificados. Antes de que nos emitan un certificado para personas o servidores es necesario que acreditemos de alguna forma que somos la persona o la empresa que estamos legitimados a usar esa identidad digital. Habitualmente los certificados emitidos por estas CAs tienen un costo dependiendo del certificado que estemos solicitando.

Las CAs privadas son CAs que nosotros podremos instalar en nuestras redes corporativas para poder emitir certificados de forma autónoma y sin tener que abonar un costo por ellos. Nosotros implementaremos nuestra infraestructura PKI interna que nos permitirá utilizar certificados como herramienta de autentificación de nuestros servidores, servicios y usuarios. El inconveniente de estos certificados es que en principio solamente serán confiables para las máquinas en las que instalemos el certificado público de nuestra CA Raíz. Por lo tanto será necesario proveer todo lo necesario para que quien quiera confiar en nuestros certificados pueda hacerlo. Distribuir e instalar un certificado raíz en una red corporativa gestionada mediante el Directorio Activo de Windows Server 2008 será muy sencillo, pero para las máquinas que no pertenezcan a la red corporativa tendremos que disponer de algún método para ello. Podremos colgar el certificado en uno de nuestros servidores web para que se pueda descargar e instalarlo manualmente o incluso podremos diseñar un control ActiveX que instale automáticamente el certificado en la máquina de los usuarios que así lo deseen.

Bueno, pues en próximos post veremos como implementar nuestra propia infraestructura de PKI. Hablaremos de las distintas implementaciones y veremos como podemos ir empezando a trabajar con esta tecnología.

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:

2

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.

3

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.

4

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

5

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

6

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.

7

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. 8

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:

9

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

10

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:

11

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.

12

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

13

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:

14

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.

15

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. 16

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.

13:46 | Agregar un comentario | Vínculo permanente | Agregar al blog | PKI

Trabajando con Certificados en Windows Server 2008 (3)

Pues en el post anterior vimos como implementar una CA Raiz Independiente y en este trataremos de ver como implementar una CA Subordinada integrada al Directorio Activo.

Para ello vamos a instalar los servicios de CA sobre un servidor dentro de nuestra implementación del Directorio Activo. En nuestro caso vamos a usar el controlador de dominio sobre el que estamos trabajando.

Antes de comenzar todo el proceso es necesario que agreguemos el registro de nuestra máquina al servidor DNS para que pueda ser localizada por su FQDN. Para hacer esto arrancamos el administrador del servicio DNS en el controlador de dominio y agregamos un registro tipo A con el nombre del servidor donde tenemos instalada la CA Raíz y lo asociamos a su IP:

Para ello y mediante la consola Administrador del Servidor vamos a agregar el rol de AD CS:

Seguimos el asistente tal cual lo hicimos para la instalación del servidor raiz, pero en este caso vamos a agregar una funcionalidad más, el Servicio de Respuesta en Línea. En este ejemplo vamos a implementar esta función en el mismo servidor donde tenemos nuestra CA pero para efectos prácticos esto debe de instalarse en un servidor diferente. En el servidor donde agreguemos esta función será donde publiquemos nuestras CRL (listas de revocación) de todas nuestras CA. En otros post veremos como implementar esto. El servicio de respuesta en línea permitirá consultar los certificados revocados sin necesidad de descargar las listas de revocación completa por parte de los clientes lo que facilita su consulta. Lamentablemente solamente los sistemas operativos posteriores a Vista están preparados para sacar provecho a esta funcionalidad.

17

Bien, pues en este caso tendremos que seleccionar la opción de Empresa para que nuestra CA se integre al Directorio Activo.

Y también seleccionamos la opción de CA Subordinada.

18

Igual que en la instalación anterior generamos un nuevo certificado para esta CA:

Conservamos también los valores por defecto de la criptografía, incluida la longitud de clave.

19

Elegimos un nombre para nuestra CA:

y llegamos a la parte donde tendremos que solicitar un certificado a una entidad superior, en nuestro caso nuestra entidad raíz. Para ello generaremos un archivo de solicitud de certificado que luego usaremos para llevarlo a nuestra CA y emitir el certificado correspondiente para esta CA subordinada.

20

Ya podemos seguir el asistente hasta el final como hicimos en la instalación anterior.

El siguiente paso es obtener el certificado de nuestra entidad emisora raíz para poder instalarlo en esta subordinada. Vamos allá:

Nos conectamos a la página web de la CA Raiz para solicitar nuestro certificado: http://srv-rootca/certsrv

Necesitamos usar la opción de Solicitar un Certificado

21

Y a continuación elegimos Solicitud avanzada de certificado

Ya disponemos de un archivo donde tenemos nuestra solicitud, así que seleccionamos Enviar una solicitud de …..

22

En este paso tendremos que abrir nuestro archivo con el bloc de notas y copiar todo su contenido para pegarlo en el cuadro Guardar Solicitud como podemos ver en la captura anterior y hacemos clic en Enviar. Esto genera una solicitud que se queda pendiente en el servidor CA Raíz y que tendremos que aprobar manualmente.

A continuación debemos de aprobar el certificado y una vez aprobado instalarlo en la CA Subordinada:

Para aprobar el certificado solicitado debemos acceder al servidor de la CA Raíz y autorizar la emisión del certificado. Para ello abrimos la herramienta de administración de la CA que encontramos en las herramientas administrativas:

23

En Solicitudes Pendientes veremos la solicitud que acabamos de hacer y que debemos de autorizar. Para ello usamos el menú contextual para emitir el certificado.

Comprobamos que el certificado figura en el contenedor de Certificados Emitidos.

Para poder usar el certificado emitido por la CA Raíz como un certificado de confianza es necesario que confiemos en esa CA. Para ello debemos de distribuir el certificado público de la CA Raíz a todas las máquinas del dominio. Para ello podemos usar las Directivas de Grupo.

En primer lugar tenemos que hacernos con el certificado público de nuestra CA Raíz. El método más sencillo es conectarnos al sitio web de la CA Raíz y descargar el certificado. Lo descargamos y lo guardamos en nuestro disco.

A continuación abrimos el administrador de directivas de grupo desde las herramientas administrativas, para editar la directiva Default Domain Policy

24

En el editor de la directiva de grupo accedemos a Configuración del equipo – Directivas – Configuración de Windows – Configuración de Seguridad – Directivas de clave pública – Entidades de Certificación raíz de confianza, y usamos el menú contextual para importar el certificado la CA Raíz.

Una vez tengamos importado en este contenedor el certificado el directorio activo se encargará de distribuirlo a todas las máquinas en el dominio, de esta forma nuestra entidad CA Raíz será de confianza dentro de todo el dominio. Podremos agregar tantos certificados a este contenedor de entidades emisoras como necesitemos.

25

Instalemos pues el certificado de nuestra entidad subordinada:

Volvemos al servidor donde estábamos instalando nuestra entidad subordinada y descargamos el certificado ya emitido. Para ello nos conectamos de nuevo al servidor web del servidor CA Raíz

Seleccionamos la opción de ver estado de una solicitud de certificado pendiente

Seleccionamos nuestra solicitud

26

y descargamos el certificado usando la opción de Descargar cadena de Certificados y guardándolo en el disco.

A continuación tendremos que habilitar nuestra CA Subordinada utilizando este certificado:

Arrancamos la herramienta de administración de nuestra CA Subordinada desde las herramientas administrativas

Usando el menú contextual accedemos a todas las tareas y seleccionamos Instalar el certificado de CA. Seguimos el asistente para indicar donde tenemos el archivo de nuestro certificado.

A continuación volvemos a usar el menú contextual para arrancar el servicio.

27

Y listo. Ya tenemos nuestra estructura PKI lista para comenzar a emitir certificados. Pero antes de ponernos a distribuir certificados como locos tendremos que hacer algunos ajustes más que veremos en próximos posts.

Siguiendo estos mismos pasos podremos habilitar tantas CAs Subordinadas como necesitemos, tanto Independientes (Stand-Alone) como de Empresa (Enterprise). Por ejemplo podríamos habilitar una CA Subordinada Independiente para emitir certificados nos relacionados con el Directorio Activo. No es que esto sea necesario ya que la CA del Directorio Activo puede emitir todo tipo de certificados y para cualquier uso, el objetivo de mantener dos CAs Subordinadas separadas sería para administrar de forma independiente los certificados internos y externos.

20:21 | Agregar un comentario | Vínculo permanente | Agregar al blog

Trabajando con Certificados en Windows Server 2008 (4)

En el post anterior instalamos nuestra CA de Empresa Subordinada. Vamos a hacerle algunos ajustes antes de empezar a distribuir certificados.

Una de las primeras cosas que debemos de ajustar son las rutas AIA y CDP tal y como hicimos en el servidor CA Raíz. En el caso de este servidor solamente debemos de agregar nuevas rutas en caso de que el nombre del servidor y/o del dominio que vayamos a publicar en Internet sean diferentes a los nombres que estamos usando internamente. Si los nombres tanto de servidor como de dominio son los mismos no tendremos que hacer nada. Pero en nuestro caso y como vamos a usar el protocolo OCSP (que mas adelante explicaremos en que consiste) tenemos que asegurarnos de que la ruta HTTP de AIA tiene marcada la opción de incluir la información del servidor OCSP en los certificados, como vemos en la siguiente captura:

28

Instalación de un servidor OCSP:

Comentamos ya en los anteriores Post que para que los certificados sean confiables deben de estar firmados por entidades de confianza, de que el nombre del certificado tiene que corresponder al objeto que están identificando (ya sea un servidor, una persona, un servicio o lo que sea) y que se encuentre dentro de las fechas de emisión y caducidad. Pero además también es necesario que las aplicaciones que están diseñadas para trabajar con implementaciones PKI también necesitan verificar que el certificado no haya sido revocado. Revocar un certificado significa anular su validez antes de que llegue la fecha de expiración del mismo. Puede haber diversos motivos por los cuales revocar un certificado: Ya no existe el objeto que identificaba, se comprometió la seguridad de la clave privada, se perdió la clave privada, se robó un la máquina donde se almacenaba ese certificado, etc…

Los certificados se revocan por parte de los administradores en la consola de gestión de la CA y es necesario publicar la lista de los certificados revocados para que las aplicaciones puedan consultar estas listas para comprobar si un certificado es válido o no. Estas listas se conocen como CRL (Certificate Revocation List). Se pueden crear de forma manual o automática y existen CRL Completas o CRL Delta. Las primeras incluyen toda la lista de certificados revocados hasta la fecha de su creación y las listas delta son simplemente diferenciales que se crean a partir de las listas completas. En entornos donde se gestione un número muy elevado de certificados es posible que estas listas tengan un tamaño desmesurado y por lo tanto su consulta pueda resultar lenta para algunas aplicaciones. Con la llegada de Windows Server 2008 podemos implementar el protocolo OCSP (Online Certificate Status Protocol), un protocolo cliente servidor para consultar el estado de un certificado sin necesidad de descargar a la máquina cliente las listas CRL completas. Es decir, que el OCSP viene a proveer a las consultas de revocación de certificados mediante CRL lo que el servicio DNS proveyó en su momento a la resolución de nombres en las redes basadas en archivos hosts: un sistema de consultas cliente-servidor que es mucho más lógico visto los días que corren.

¿Esto quiere decir que ya no tendremos que seguir creando listas de revocación? NO. Las listas de revocación tendremos que crearlas igualmente dado que este protocolo genera sus respuestas después de haber consultado las

29

CRL que vayan creando las CAs. La buena noticia es que un solo servidor OCSP puede dar servicio a múltiples CAs. Además este protocolo solamente lo podrán usar sistemas operativos Vista o posteriores, lo que significa que otros sistemas operativos necesitan seguir accediendo a las CRL para hacer sus consultas.

Veamos como habilitar un servidor OCSP:

Lo primero que vamos a hacer es agregar a nuestros servidores la ruta donde se encontrará el servidor OCSP en la información de rutas AIA igual que hicimos en ejercicios anteriores:

Agregamos una ruta http y nos acordamos de marcar las casillas correspondientes para que se agregue esta información a los certificados. Esto tendremos que hacerlo en todas y cada una de nuestras CAs. Y recordemos que si estamos usando rutas diferentes en la red interna y en internet tendremos que agregar ambas rutas.

Para implementar un servidor OCSP es necesario asignarle a ese servidor un certificado que lo identifique como tal. Para ello tenemos una plantilla de certificado específica en nuestra CA:

Abrimos la herramienta de administración de nuestra CA de Empresa Subordinada hacemos clic con el botón derecho sobre Plantillas de certificado y seleccionamos Administrar del menú contextual.

30

Localizamos en la lista de plantillas la plantilla de certificado “Firma de Respuesta de OCSP” y hacemos doble clic para acceder a sus propiedades. En la pestaña de Seguridad seleccionamos en la DACL a usuarios autentificados y le asignamos el permiso “Inscribirse”.

A continuación cerramos la consola de las plantillas de certificados y desde la herramienta de administración de la CA seleccionamos la plantilla que acabamos de modificar para que el servidor pueda usarla a la hora de generar certificados.

Para ello haciendo clic con el botón derecho sobre Plantillas de certificados y usando las opciones de “Nuevo/Plantilla de certificado que se va a emitir”. En la lista seleccionamos nuestra plantilla: Firma de respuesta de OCSP. Debería de quedarnos algo como esto:

31

Pues ya tenemos el certificado necesario para implementar una OCSP. Pasemos a configurarlo. En nuestro servidor ya tenemos el servicio OCSP instalado, si no lo tuviésemos tendríamos que instalarlo mediante el Server Manager. El servicio OCSP podremos instalarlo en cualquier servidor, no es necesario que esté en la misma máquina que la CA.

Nos vamos a las herramientas administrativas y arrancamos Administrador del Servicio de Respuestas en Línea. Usando el menú contextual agregaremos una configuración de revocación:

Vamos a seguir el asistente para crear esta configuración. En primer lugar tendremos que asignar un nombre descriptivo del servicio:

El certificado para nuestro OCSP nos lo emitirá nuestra CA de Empresa, así que…:

32

Como vamos a usar nuestra CA del directorio activo para este caso podremos usar el botón examinar para localizar el certificado de nuestra CA de Empresa.

Dejaremos que de forma automática el servicio OCSP use el certificado adecuado para firmar las respuestas enviadas a los clientes (la plantilla que configuramos anteriormente)

33

Terminamos el asistente hasta el final y ya tenemos listo nuestro servidor OCSP. Si queremos que este servidor ofrezca servicios en Internet podríamos publicarlo con un ISA Server de forma segura.

Podremos agregar tantas CAs como queramos gestionar desde nuestro servidor OCSP. Veamos como agregar nuestra CA Raiz.

Arrancamos de nuevo el asistente e igual que antes asignamos un nombre descriptivo

Nuestra CA Raiz no es una CA de Empresa así que tendremos que seleccionar el certificado de nuestro almacén local. Recordemos que ya creamos una GPO en el Directorio Activo para que este certificado se distribuyese automáticamente a todas las máquinas del dominio.

34

Hacemos clic en siguiente y seleccionamos el certificado de nuestra CA Raíz mediante el botón examinar.

Para la firma de las respuestas usamos la misma configuración anterior:

35

Para nuestra CA Root no tendremos un proveedor de listas de revocación y eso lo solucionamos introduciéndolo manualmente.

hacemos clic en aceptar y luego mediante el botón de Proveedor introducimos la ruta a la lista de revocación de nuestra CA Raíz:

Debería de quedarnos algo así:

36

Hacemos clic en Aceptar terminamos el asistente y ya lo tenemos listo.

En este punto es necesario hacer un inciso. Aunque nosotros asignamos esta ruta en nuestra CA Raíz, en realidad la lista de revocación no figura en esa ruta porque nosotros debemos de proveer el mecanismo por el cual el servidor con la CA Raíz pueda escribir en esa carpeta la lista de revocación. Dado que nuestra CA se mantener off-line, que el servidor no pertenece al dominio y que la cantidad de revocaciones que se van a hacer en este servidor van a ser mínimas lo más adecuado es copiar los archivos de forma manual. Para hacerlo seguimos los siguientes pasos:

Nos conectamos al recurso compartido donde la CA Raíz publica sus CRLs: \\srv-rootca\certenroll

Copiamos el contenido de esa carpeta y lo pegamos en el recurso compartido de la CA subordinada: \\dc1\certenroll

Si acaso no hubiese contenido en el recurso compartido de la CA Raíz entonces tendremos que crear nuestra primera CRL. Para hacerlo seguimos los siguientes pasos:

Desde el servidor que alberga nuestra CA Raíz arrancamos la herramienta de administración de la CA:

37

Usando el menú contextual del contenedor Certificados revocados publicamos nuestra primera CRL. Obviamente esta CRL estará vacía a menos que hayamos revocado algún certificado.

Cada vez que generemos una nueva lista de revocación debemos de copiar el contenido desde el servidor CA Raíz hacia el servidor CA Subordinado.

12:22 | Agregar un comentario | Vínculo permanente | Agregar al blog

16 marzo

Trabajando con Certificados en Windows Server 2008 (5)

Pues vamos terminar de poner a punto nuestra CA para poder comenzar con la distribución de certificados en nuestra red.

Un punto muy importante cuando estamos trabajando con certificados es la posibilidad de recuperar certificados que se hayan perdido o que se hayan estropeado por algún motivo. Cuando usamos certificados de usuario para cifrar información, ya sea en el disco duro o ya sea en el correo electrónico siempre necesitaremos esos mismos certificados para seguir accediendo a esa información. Si por algún motivo perdemos los certificados con los que ciframos contenido esa información será irrecuperable. Un certificado se puede perder por haber formateado un disco, o porque nos robaron el portátil, o simplemente por un mal uso del certificado. Cada usuario debería de ser el responsable de crear una copia de seguridad de su certificado privado y mantenerla a buen recaudo. Pero sabemos de sobra que no podemos dejar esa responsabilidad a los usuarios. Por lo tanto tendremos que proveer las herramientas necesarias para las situaciones donde los usuarios puedan llegar a no disponer de su certificado por un motivo o por otro. Cuando estamos usando CA de Empresa tenemos la posibilidad de usar lo que se denominan Agentes de Recuperación de Claves (KRA – Key Recovery Agent). Estos agentes tienen la capacidad de recuperar la clave privada de un certificado de la base de datos de la CA para situaciones de perdida o extravío de certificados. De más está decir que las personas a las que otorguemos esta funcionalidad deben de ser personas de total confianza dado que podrán recuperar cualquier certificado y en cualquier momento. Deben de establecerse procedimientos de como se deben de usar los usuarios que dispongan de la funcionalidad de KRA. En algunos entornos se suele crear un usuario específico para realizar tareas de KRA y la contraseña de ese usuario está compartida por al menos dos personas, es decir, una de ellas conoce la primera mitad de la contraseña y la otra persona conoce la segunda mitad. Esto obliga a que por lo menos siempre haya dos personas presentes en los procesos de recuperación de claves y garantiza de alguna manera que no se hace un uso inadecuado de esta funcionalidad.

38

Veamos como implementar un Agente de Recuperación de Claves:

En primer lugar vamos a crear un usuario que vamos a usar exclusivamente para las tareas de recuperación de claves, lo llamaremos UsuarioKRA.

Creamos también un grupo global que llamaremos Agentes KRA y agregaremos al usuario UsuarioKRA a este grupo.

En la herramienta de administración de la CA abriremos el editor de plantillas usando el menú contextual de la carpeta Plantillas de Certificados

En el administrador de plantillas localizamos la plantilla Agente de recuperación de claves y hacemos doble clic sobre ella para acceder a sus propiedades. En la pestaña Seguridad agregamos al grupo Agentes KRA y le asignamos el permiso de Inscribirse y el de lectura.

39

Para que no sea necesario que un administrador autorice la emisión de estos certificados podemos quitar la marca que hay en la casilla Aprobación del administrador de certificados de entidad de certificación en la pestaña Requisitos de Emisión. En entornos de alta seguridad podría ser conveniente dejar esta marca activada para que la emisión de estos certificados estuviese controlada por los administradores.

Aceptamos los cambios y cerramos la ventana de edición de las plantillas

A continuación tenemos que permitir la emisión de esta plantilla. Para ello en el menú contextual de la carpeta de certificados elegimos nuevo – Plantilla de certificado que se va a emitir y seleccionamos la plantilla del Agente de Recuperación de Claves

A continuación debemos de solicitar el certificado de KRA para el usuario que le corresponda. Por lo tanto iniciamos una sesión con el usuario KRA desde cualquier máquina en el dominio. Si lo vamos a hacer desde el controlador de dominio debemos de recordar que los usuarios básicos no pueden iniciar sesión en este tipo de servidores.

Para solicitar el certificado KRA para este usuario vamos a usar la consola MMC. Por lo tanto desde una sesión de ese usuario arrancamos una consola MMC en blanco y agregamos el complemento de certificados. Si se nos solicita a

40

que tipo de contenedor de certificados queremos acceder seleccionamos el de usuario. Si tenemos activado el control de cuentas en el sistema operativo tendremos que ingresar de nuevo la contraseña de nuestro usuario para confirmar el uso de la consola MMC.

Desde la consola MMC accederemos al menú contextual del contenedor Personal para llegar a la opción de Solicitar un nuevo certificado.

En el asistente seleccionaremos el certificado Agente de Recuperación de claves

Si vamos a utilizar más de un KRA debemos de repetir este proceso para cada uno de ellos.

A continuación debemos de configurar nuestra CA para que almacene las claves privadas de los certificados emitidos en la base de datos de la CA.

41

Arrancamos la herramienta de administración de nuestra CA de Empresa y accedemos a sus propiedades haciendo clic con el botón derecho sobre el nombre de la CA. En la pestaña Agentes de Recuperación activamos el botón de Archivar la Clave y agregamos el certificado o los certificados correspondientes a todos los agentes de recuperación que hayamos designado. En este punto veremos que certificado se marca con una aspa roja y que en su estado figura “no cargado”. Esto es porque necesitamos reiniciar los servicios de la CA. Hacemos clic en Aceptar y reiniciamos los servicios.

Una vez reiniciado el servicio podremos volver a consultar esta pestaña para ver que ahora los certificados están activos.

Por último es necesario definir a que tipo de certificados se les almacenará la clave privada en la base de datos de la CA. Normalmente se define una plantilla de usuario o varias, dependiendo del uso que se le vaya a dar a cada una de ellas y tambien debemos de definir en cada una de esas plantillas a cuales les queremos respaldar su clave privada.

Para crear una plantilla de usuario preparada para archivar su clave privada:

Volvemos al editor de plantillas de nuestra CA haciendo uso del menú contextual de la carpeta de plantillas. Desde este editor vamos a hacer clic con el botón derecho sobre la plantilla que se llama Usuario y seleccionamos la opción de plantilla duplicada. Con esto conseguimos una copia de esa plantilla que nosotros vamos a adaptar a nuestras necesidades sin modificar la original. Seleccionamos la opción de Windows Server 2088 al crear la nueva plantilla. Automáticamente se nos abren las propiedades de la nueva plantilla.

Para empezar vamos a asignarle un nombre. En este caso usaremos Usuario Corporativo (Clave Archivada)

42

A continuación en la pestaña Tratamiento de la Solicitud tendremos que activar la casilla: Archivar clave privada de cifrado de sujeto. Esta opción es la que permitirá archivar la clave privada del certificado.

43

También tendremos que modificar sus permisos para que se puedan distribuir los certificados basados en esta plantilla de forma automática mediante Directivas de Grupo. Para ello asignamos al grupo Usuarios Autentificados los permisos de lectura, inscribirse e inscripción automática. También podríamos restringir estos permisos a grupos más reducidos dependiendo de como queremos asignar certificados a nuestros usuarios.

A continuación solo resta publicar la plantilla en la CA mediante el menú contextual de la carpeta Plantillas de certificados. Nuestra CA de Empresa debería de tener un aspecto similar al siguiente:

Llegados a este punto sería conveniente quitar nuestra CA Raíz de línea dado que ya no la necesitaremos. Para ello simplemente apagamos la máquina virtual y la guardamos en algún medio seguro. Por ejemplo, sería aconsejable estamparla en tres o cuatro DVDs para disponer de varias copias por si alguno falla cuando se vaya a restaurar.

Con esto ya disponemos de un entorno de PKI de seguridad media para gestionar la emisión de certificados por parte de nuestra CA Corporativa.

12:50 | Agregar un comentario | Vínculo permanente | Agregar al blog

44

Trabajando con Certificados en Windows Server 2008 (…y 6)

Distribuir certificados a los usuarios

Pues con esto ya tenemos lista nuestra CA para poder comenzar a distribuir certificados. El siguiente paso sería crear una GPO en el directorio activo que se encargue de distribuir los certificados.

Simplemente abrimos la herramienta de administración de las directivas de grupo dentro de las herramientas administrativas y creamos una GPO a nivel de dominio o al nivel de las OUs donde queremos distribuir certificados.

Editamos la directiva que acabamos de crear y nos vamos a: Configuración de Usuario – directivas – Configuración de Windows – Configuración de Seguridad – Directivas de clave pública

Aquí hacemos clic sobre Cliente de Servicios de Certificate Server – Inscripción Automática

Lo habilitamos y activamos las casillas de renovaciones automáticas y actualizaciones de plantillas.

45

Aceptamos los cambios y solo resta probar.

Creamos un usuario para probarlo e iniciaremos una sesión en alguna de las máquinas del dominio.

19:18 | Agregar un comentario | Vínculo permanente | Agregar al blog

25 marzo

46

¡Hola!

hemos SubCA en Windows 2003. Esta CA no puede iniciar debido a este error. Después de modifzing CA \ LogLevel a 2, es capaz de iniciar, pero certs no se han concedido a causa de este error. He probado con validez certutil de CA raíz CRL, pasa. CRL de la CA raíz es V1 - puede ser esto un problema. ¿Qué puedo hacer? Gracias

Saludos cordiales, RM

certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

 

It returns as follows:

==============

C:\>certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\SEASUB01\CRLFlags

Old Value:

CRLFlags REG_DWORD = 2

CRLF_DELETE_EXPIRED_CRLS -- 2

New Value:

CRLFlags REG_DWORD = a (10)

CRLF_DELETE_EXPIRED_CRLS -- 2

CRLF_REVCHECK_IGNORE_OFFLINE -- 8

CertUtil: -setreg command completed successfully.

==============

Then restart the CA.

47