Está en la página 1de 47

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 da en cuanto a estas cuestiones pues deberais de saber que los certificados hoy en da en lo que al mundo digital se refiere son fundamentales. Son las seas 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 informacin 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 ms aplicaciones. Por ejemplo podemos disponer de certificados digitales personales que nos permitan cifrar correo electrnico o archivos en nuestros discos duros. Tambin 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 comn es el de identificacin de usuarios en las redes mediante tarjetas inteligentes en las cuales se almacenan los certificados. As mismo tambin 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 pblico y hasta que lleg a nosotros. Esto garantiza que l cdigo que recibimos est libre de virus y de cualquier tipo de malware que algn desaprensivo nos haya querido colar en nuestra mquina. En fn la cantidad de aplicaciones que tienen hoy en da los certificados digitales es muy variada y seguir creciendo ya que es uno de los mtodos ms seguros para identificar servidores, usuarios, servicios e integridad de software, as como proteger informacin. La seguridad que ofrecen los certificados digitales la provee el cifrado asimtrico mediante una clave pblica y una clave privada que estn relacionadas entre si de una forma que es prcticamente imposible descubrir esta relacin no es imposible del todo, pero se necesita una gran capacidad de clculo y mucho tiempo para llegar a romper la seguridad de unas claves de este tipo . Pues bien, cada certificado dispone de una clave pblica (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 pblico para que se le pueda enviar informacin cifrada. El certificado pblico se puede distribuir de mltiples formas: publicarlo en una pgina web, anexarlo a los correos electrnicos formando parte de la firma, enviarlo por messenger, etc Toda la informacin que se cifre con el certificado pblico 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 informacin. De ah la importancia de mantener en lugar seguro y protegido nuestros certificados con la clave privada. Tambin el propietario de un certificado podr usar su certificado privado para firmar digitalmente cualquier tipo de informacin, de esta manera cualquier persona que tenga el certificado pblico de esa persona podr comprobar la autenticidad de la firma y la integridad de la informacin. 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 engaarnos? Pues todo es cuestin 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 usarn como medios de identificacin. En el momento de instalar una CA el software de la CA se encarga de crear un certificado raz auto firmado. Este es el certificado ms importante en una implementacin de Claves Pblicas (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 implementacin de PKI puede haber mltiples CA organizadas jerrquicamente, es decir, podemos instalar varias CAs que dependan de la CA Raz. Todas ellas podrn 1

emitir certificados pero la cadena de confianza de certificados siempre depender del certificado de la CA Raz. Por lo tanto para que nuestro sistema operativo confe en un certificado se tienen que cumplir tres condiciones: En primer lugar que nuestra mquina confe 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 direccin 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 Pblicas y las CAs Privadas: Las CAs Pblicas son implementaciones PKI gestionadas habitualmente por empresas privadas (www.verisign.com, http://www.thawte.com/, www.entrust.com, etc.) aunque tambin existen algunas gubernamentales (http://www.fnmt.es/). Los certificados pblicos de estas CAs habitualmente ya vienen incluidos con los sistemas operativos de serie, esto quiere decir que de forma automtica 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 emisin 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 autnoma y sin tener que abonar un costo por ellos. Nosotros implementaremos nuestra infraestructura PKI interna que nos permitir utilizar certificados como herramienta de autentificacin de nuestros servidores, servicios y usuarios. El inconveniente de estos certificados es que en principio solamente sern confiables para las mquinas en las que instalemos el certificado pblico de nuestra CA Raz. Por lo tanto ser necesario proveer todo lo necesario para que quien quiera confiar en nuestros certificados pueda hacerlo. Distribuir e instalar un certificado raz en una red corporativa gestionada mediante el Directorio Activo de Windows Server 2008 ser muy sencillo, pero para las mquinas que no pertenezcan a la red corporativa tendremos que disponer de algn mtodo para ello. Podremos colgar el certificado en uno de nuestros servidores web para que se pueda descargar e instalarlo manualmente o incluso podremos disear un control ActiveX que instale automticamente el certificado en la mquina de los usuarios que as lo deseen. Bueno, pues en prximos post veremos como implementar nuestra propia infraestructura de PKI. Hablaremos de las distintas implementaciones y veremos como podemos ir empezando a trabajar con esta tecnologa.

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 informacin AIA (Authority Information Access) para que los certificados emitidos a usuarios, mquinas y servicios puedan ser validados. Bsicamente dentro de una implementacin PKI contamos con dos tipos de CAs: 2

CA Raiz: Es el tipo de CA ms confiable en la infraestructura PKI. Todos los certificados emitidos dependern jerrquicamente 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 jerarqua. 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, mquinas, equipos u otras CAs. En entornos de alta seguridad es habitual desplegar estructuras PKI con tres niveles jerrquicos o ms. Es aconsejable implementar modelos jerrquicos ya que nos van a proveer un mayor grado de seguridad, flexibilidad y escalabilidad. Escenarios de uso de CAs jerrquicas:

Como podemos ver en el grfico podemos desplegar nuestra estructura PKI para acomodarla a nuestras necesidades. Podemos crear CAs dentro de una implementacin 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 implementacin 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 StandAlone 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 ms importantes de implementar Enterprise CAs es que podremos gestionar muchos aspectos de la gestin de los certificados mediante las Group Policies y podremos sacar partido a las plantillas de certificados. Uno de los aspectos ms 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 recomendacin importante es que la CA Raiz se implemente sobre un servidor que no pertenezca al dominio y como Stand-Alone CA. A continuacin se instalarn las CAs Subordinadas como Enterprise CA pero con certificados emitidos por la Stand-Alone CA. Una vez terminada toda la configuracin inicial e instaladas las CAs subordinadas de primer nivel es conveniente mantener el servidor con la CA Raiz off-line. Una prctica 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. Tambin podemos implementar estructuras complejas donde creamos CAs que gestionan certificados cruzados para que los certificados emitidos por una CA en particular automticamente se firmen por ms de una CA como podemos ver en el siguiente grfico. 3

El tipo de implementacin que vayamos a hacer depender de la complejidad que necesitemos para gestionar la emisin de certificados. Es importante resaltar que la implementacin de una infraestructura PKI debe de estar precedida de una buena planificacin, lo que conseguiremos mediante una consultora 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 gestin y la segunda determinar la jerarqua y los controles de seguridad a implementar. Veamos como implementar una CA para entornos reducidos de gestin de certificados: Vamos a partir de una instalacin donde usaremos un servidor stand-alone para crear nuestra CA Raiz. Este tipo de implementaciones adems de permitirnos almacenar de forma segura nuestra CA Raiz tambin 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 podramos crear dos subordinadas, una para la emisin de certificados relacionados con el acceso al directorio activo y otra para emisin de certificados de uso pblico, como pueden ser los certificados para la publicacin 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 implementacin debemos de ser conscientes de tres puntos muy importantes: El primero es la distribucin del certificado pblico de nuestra CA Raiz, el segundo es la publicacin 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 Recuperacin de Claves (KRA Key Recovery Agent) Antes de proceder a la instalacin 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 despus de habilitada la CA. En este ejemplo de implementacin 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 GWPKI DC1: Controlador de dominio del dominio EMBOSA. En este servidor instalaremos una CA Subordinada integrada al Directorio Activo. Tambin 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 habamos elegido y que tambin 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 opcin 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 opcin Inscripcin Web de Entidad de Certificacin.

Para que funcionen los servicios web de la CA es necesario instalar tambin el IIS y el asistente as nos lo hace saber. Simplemente hacemos clic sobre Agregar servicios de funcin Requeridos y automticamente 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 configuracin 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 instalacin Independiente (Stand-Alone)

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

La siguiente cuestin 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 restaurndola tendremos que usar la opcin de usar una clave existente.

Y llegamos a la parte donde decidiremos los servicios criptogrficos 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 Raz vamos a cambiar la longitud de clave a 4096. Recordemos que cuanto mayor sea la clave a usar mayor seguridad estaremos implementando pero tambin mayor capacidad de clculo necesitaremos para cifrar y descifrar. En las entidades raz es conveniente agregar claves largas para sus certificados dado que habitualmente estos certificados suelen tener mayor vigencia que cualquier otro.

A continuacin asignamos un nombre por el cual queremos que se reconozca a nuestra CA. 8

y establecemos la duracin del certificado. A mayor duracin de un certificado mayor vulnerabilidad. Para los entornos de baja o media seguridad es suficiente con 10 aos. Para entornos ms sensibles es conveniente bajar esta duracin. Tambin debemos de ser conscientes de las fechas de renovacin de estos certificados y tambin 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 continuacin aceptamos los valores por defecto de la instalacin del IIS y comenzamos con la instalacin.

Una vez terminada la instalacin ya dispondremos de nuestra CA Raz operativa. Primeras acciones a realizar una vez completado el proceso de instalacin: Respaldar la clave privada de nuestra CA: Esto nos permitir recrear nuestra CA en caso de desastre. Accedemos a la herramienta de administracin de nuestra CA usando el complemento Certification Authority que encontraremos en las herramientas administrativas. haciendo clic con el botn 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 certificacin.

haremos uso del asistente para hacer una copia de respaldo del certificado privado de nuestra CA: En este punto no haremos todava 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 contrasea 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 pblico de nuestra CA para poder distribuirlo a todo el que quiera confiar en los certificados emitidos por nosotros. para ello accedemos a la pgina web de nuestra CA mediante el URL por defecto: http://localhost/certsrv

En esta pgina web usaremos el ltimo link: Descargar un certificado de CA, cadena de certificados o lista de revocacin.

12

Simplemente seleccionamos la opcin de Descargar certificado de CA y lo almacenamos en un archivo:

Este certificado habr que instalarlo en todas las mquinas 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 certificacin raz de confianza. Como ya comentamos al principio de esta serie de posts, este servidor lo vamos a mantener fuera de lnea una vez que tengamos funcionando toda nuestra implementacin por lo que tendremos que publicar las rutas AIA y CDP en algn 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 informacin. En este ejemplo vamos a usar el servidor donde despus instalaremos nuestra CA Subordinada. Podra ser cualquier otro servidor web, no es necesario que tenga instalados los servicios de CA. Es necesario realizar este paso antes de emitir ningn certificado porque esta informacin se agrega a los certificados. Modificacin de las rutas AIA y CDP: Si accedemos a las propiedades de nuestra CA y hacemos clic sobre la pestaa Extensiones podremos ver que ya existen unas rutas de publicacin para esta informacin generada en base a variables pero todas apuntando a la mquina local.

Vamos a agregar una ruta http para CDP y otra para AIA pero apuntndolas al servidor web que tenemos en el otro servidor. Para ello podemos servirnos de la informacin que tenemos de otras rutas que estn creadas y del uso de las variables. Por ejemplo, empecemos por la ruta AIA. Desde esta misma pantalla de propiedades y en la pestaa extensiones, En el cuadro Seleccionar Extensin elegimos Acceso a la Informacin de Entidad (AIA). Podremos copiar la ruta http que ya existe para crear la nuestra, que quedara as: hacemos clic en agregar y en Ubicacin 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 despus de haber insertado la variable del nombre de servidor incluimos un guin bajo _. A continuacin insertaremos dos variables seguidas: <Nombre de CA><Nombre de Certificado> y terminamos la lnea agregando la extensin del archivo .crt. Debera 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 informacin 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 tambin vamos a hacer uso de un servidor OCSP (que explicaremos ms adelante) conviene tambien agregar una ruta nueva HTTP a la informacin de AIA. En nuestro la ruta a agregar ser: HTTP://dc1.embosa.com/ocsp Repetimos el proceso para la ruta CDP. En la pestaa Extensiones seleccionamos esta vez Puntos de Distribucin de lista de revocacin de certificados (CDP) y hacemos clic en agregar.

Usando la misma tcnica 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 estn 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 raz lista y funcionando. El siguiente paso ser crear una entidad emisora subordinada integrada al Directorio Activo, pero eso lo veremos en el prximo post. 13:46 | Agregar un comentario | Vnculo 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 implementacin 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 mquina 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 Raz 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 instalacin del servidor raiz, pero en este caso vamos a agregar una funcionalidad ms, el Servicio de Respuesta en Lnea. En este ejemplo vamos a implementar esta funcin en el mismo servidor donde tenemos nuestra CA pero para efectos prcticos esto debe de instalarse en un servidor diferente. En el servidor donde agreguemos esta funcin ser donde publiquemos nuestras CRL (listas de revocacin) de todas nuestras CA. En otros post veremos como implementar esto. El servicio de respuesta en lnea permitir consultar los certificados revocados sin necesidad de descargar las listas de revocacin completa por parte de los clientes lo que facilita su consulta. Lamentablemente solamente los sistemas operativos posteriores a Vista estn preparados para sacar provecho a esta funcionalidad.

17

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

Y tambin seleccionamos la opcin de CA Subordinada.

18

Igual que en la instalacin anterior generamos un nuevo certificado para esta CA:

Conservamos tambin los valores por defecto de la criptografa, 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 raz. 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 instalacin anterior. El siguiente paso es obtener el certificado de nuestra entidad emisora raz para poder instalarlo en esta subordinada. Vamos all:

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

Necesitamos usar la opcin de Solicitar un Certificado 21

Y a continuacin 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 Raz y que tendremos que aprobar manualmente.

A continuacin 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 Raz y autorizar la emisin del certificado. Para ello abrimos la herramienta de administracin 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 Raz como un certificado de confianza es necesario que confiemos en esa CA. Para ello debemos de distribuir el certificado pblico de la CA Raz a todas las mquinas del dominio. Para ello podemos usar las Directivas de Grupo. En primer lugar tenemos que hacernos con el certificado pblico de nuestra CA Raz. El mtodo ms sencillo es conectarnos al sitio web de la CA Raz y descargar el certificado. Lo descargamos y lo guardamos en nuestro disco. A continuacin 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 Configuracin del equipo Directivas Configuracin de Windows Configuracin de Seguridad Directivas de clave pblica Entidades de Certificacin raz de confianza, y usamos el men contextual para importar el certificado la CA Raz.

Una vez tengamos importado en este contenedor el certificado el directorio activo se encargar de distribuirlo a todas las mquinas en el dominio, de esta forma nuestra entidad CA Raz 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 estbamos instalando nuestra entidad subordinada y descargamos el certificado ya emitido. Para ello nos conectamos de nuevo al servidor web del servidor CA Raz

Seleccionamos la opcin de ver estado de una solicitud de certificado pendiente

Seleccionamos nuestra solicitud

26

y descargamos el certificado usando la opcin de Descargar cadena de Certificados y guardndolo en el disco. A continuacin tendremos que habilitar nuestra CA Subordinada utilizando este certificado: Arrancamos la herramienta de administracin 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 continuacin 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 ms que veremos en prximos posts. Siguiendo estos mismos pasos podremos habilitar tantas CAs Subordinadas como necesitemos, tanto Independientes (Stand-Alone) como de Empresa (Enterprise). Por ejemplo podramos 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 sera para administrar de forma independiente los certificados internos y externos. 20:21 | Agregar un comentario | Vnculo 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 Raz. 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 opcin de incluir la informacin del servidor OCSP en los certificados, como vemos en la siguiente captura:

28

Instalacin 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 estn identificando (ya sea un servidor, una persona, un servicio o lo que sea) y que se encuentre dentro de las fechas de emisin y caducidad. Pero adems tambin es necesario que las aplicaciones que estn diseadas para trabajar con implementaciones PKI tambin necesitan verificar que el certificado no haya sido revocado. Revocar un certificado significa anular su validez antes de que llegue la fecha de expiracin 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 mquina donde se almacenaba ese certificado, etc Los certificados se revocan por parte de los administradores en la consola de gestin 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 vlido o no. Estas listas se conocen como CRL (Certificate Revocation List). Se pueden crear de forma manual o automtica y existen CRL Completas o CRL Delta. Las primeras incluyen toda la lista de certificados revocados hasta la fecha de su creacin y las listas delta son simplemente diferenciales que se crean a partir de las listas completas. En entornos donde se gestione un nmero muy elevado de certificados es posible que estas listas tengan un tamao 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 mquina cliente las listas CRL completas. Es decir, que el OCSP viene a proveer a las consultas de revocacin de certificados mediante CRL lo que el servicio DNS provey en su momento a la resolucin de nombres en las redes basadas en archivos hosts: un sistema de consultas cliente-servidor que es mucho ms lgico visto los das que corren. Esto quiere decir que ya no tendremos que seguir creando listas de revocacin? NO. Las listas de revocacin tendremos que crearlas igualmente dado que este protocolo genera sus respuestas despus de haber consultado las 29

CRL que vayan creando las CAs. La buena noticia es que un solo servidor OCSP puede dar servicio a mltiples CAs. Adems este protocolo solamente lo podrn 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 informacin 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 informacin 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 especfica en nuestra CA: Abrimos la herramienta de administracin de nuestra CA de Empresa Subordinada hacemos clic con el botn 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 pestaa de Seguridad seleccionamos en la DACL a usuarios autentificados y le asignamos el permiso Inscribirse.

A continuacin cerramos la consola de las plantillas de certificados y desde la herramienta de administracin 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 botn 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. Debera 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 tuvisemos tendramos que instalarlo mediante el Server Manager. El servicio OCSP podremos instalarlo en cualquier servidor, no es necesario que est en la misma mquina que la CA. Nos vamos a las herramientas administrativas y arrancamos Administrador del Servicio de Respuestas en Lnea. Usando el men contextual agregaremos una configuracin de revocacin:

Vamos a seguir el asistente para crear esta configuracin. 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 botn examinar para localizar el certificado de nuestra CA de Empresa.

Dejaremos que de forma automtica 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 podramos 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 almacn local. Recordemos que ya creamos una GPO en el Directorio Activo para que este certificado se distribuyese automticamente a todas las mquinas del dominio.

34

Hacemos clic en siguiente y seleccionamos el certificado de nuestra CA Raz mediante el botn examinar.

Para la firma de las respuestas usamos la misma configuracin anterior:

35

Para nuestra CA Root no tendremos un proveedor de listas de revocacin y eso lo solucionamos introducindolo manualmente.

hacemos clic en aceptar y luego mediante el botn de Proveedor introducimos la ruta a la lista de revocacin de nuestra CA Raz: Debera 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 Raz, en realidad la lista de revocacin no figura en esa ruta porque nosotros debemos de proveer el mecanismo por el cual el servidor con la CA Raz pueda escribir en esa carpeta la lista de revocacin. 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 mnimas lo ms adecuado es copiar los archivos de forma manual. Para hacerlo seguimos los siguientes pasos: Nos conectamos al recurso compartido donde la CA Raz 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 Raz entonces tendremos que crear nuestra primera CRL. Para hacerlo seguimos los siguientes pasos: Desde el servidor que alberga nuestra CA Raz arrancamos la herramienta de administracin de la CA:

37

Usando el men contextual del contenedor Certificados revocados publicamos nuestra primera CRL. Obviamente esta CRL estar vaca a menos que hayamos revocado algn certificado.

Cada vez que generemos una nueva lista de revocacin debemos de copiar el contenido desde el servidor CA Raz hacia el servidor CA Subordinado. 12:22 | Agregar un comentario | Vnculo 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 distribucin 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 algn motivo. Cuando usamos certificados de usuario para cifrar informacin, ya sea en el disco duro o ya sea en el correo electrnico siempre necesitaremos esos mismos certificados para seguir accediendo a esa informacin. Si por algn motivo perdemos los certificados con los que ciframos contenido esa informacin ser irrecuperable. Un certificado se puede perder por haber formateado un disco, o porque nos robaron el porttil, o simplemente por un mal uso del certificado. Cada usuario debera 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 Recuperacin 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 extravo de certificados. De ms est decir que las personas a las que otorguemos esta funcionalidad deben de ser personas de total confianza dado que podrn 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 especfico para realizar tareas de KRA y la contrasea de ese usuario est compartida por al menos dos personas, es decir, una de ellas conoce la primera mitad de la contrasea y la otra persona conoce la segunda mitad. Esto obliga a que por lo menos siempre haya dos personas presentes en los procesos de recuperacin de claves y garantiza de alguna manera que no se hace un uso inadecuado de esta funcionalidad. 38

Veamos como implementar un Agente de Recuperacin de Claves: En primer lugar vamos a crear un usuario que vamos a usar exclusivamente para las tareas de recuperacin de claves, lo llamaremos UsuarioKRA. Creamos tambin un grupo global que llamaremos Agentes KRA y agregaremos al usuario UsuarioKRA a este grupo. En la herramienta de administracin 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 recuperacin de claves y hacemos doble clic sobre ella para acceder a sus propiedades. En la pestaa 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 emisin de estos certificados podemos quitar la marca que hay en la casilla Aprobacin del administrador de certificados de entidad de certificacin en la pestaa Requisitos de Emisin. En entornos de alta seguridad podra ser conveniente dejar esta marca activada para que la emisin de estos certificados estuviese controlada por los administradores.

Aceptamos los cambios y cerramos la ventana de edicin de las plantillas A continuacin tenemos que permitir la emisin 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 Recuperacin de Claves

A continuacin debemos de solicitar el certificado de KRA para el usuario que le corresponda. Por lo tanto iniciamos una sesin con el usuario KRA desde cualquier mquina en el dominio. Si lo vamos a hacer desde el controlador de dominio debemos de recordar que los usuarios bsicos no pueden iniciar sesin en este tipo de servidores. Para solicitar el certificado KRA para este usuario vamos a usar la consola MMC. Por lo tanto desde una sesin 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 contrasea 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 opcin de Solicitar un nuevo certificado.

En el asistente seleccionaremos el certificado Agente de Recuperacin de claves

Si vamos a utilizar ms de un KRA debemos de repetir este proceso para cada uno de ellos. A continuacin 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 administracin de nuestra CA de Empresa y accedemos a sus propiedades haciendo clic con el botn derecho sobre el nombre de la CA. En la pestaa Agentes de Recuperacin activamos el botn de Archivar la Clave y agregamos el certificado o los certificados correspondientes a todos los agentes de recuperacin 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 pestaa para ver que ahora los certificados estn 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 botn derecho sobre la plantilla que se llama Usuario y seleccionamos la opcin 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 opcin de Windows Server 2088 al crear la nueva plantilla. Automticamente 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 continuacin en la pestaa Tratamiento de la Solicitud tendremos que activar la casilla: Archivar clave privada de cifrado de sujeto. Esta opcin es la que permitir archivar la clave privada del certificado.

43

Tambin tendremos que modificar sus permisos para que se puedan distribuir los certificados basados en esta plantilla de forma automtica mediante Directivas de Grupo. Para ello asignamos al grupo Usuarios Autentificados los permisos de lectura, inscribirse e inscripcin automtica. Tambin podramos restringir estos permisos a grupos ms reducidos dependiendo de como queremos asignar certificados a nuestros usuarios.

A continuacin solo resta publicar la plantilla en la CA mediante el men contextual de la carpeta Plantillas de certificados. Nuestra CA de Empresa debera de tener un aspecto similar al siguiente:

Llegados a este punto sera conveniente quitar nuestra CA Raz de lnea dado que ya no la necesitaremos. Para ello simplemente apagamos la mquina virtual y la guardamos en algn medio seguro. Por ejemplo, sera 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 emisin de certificados por parte de nuestra CA Corporativa. 12:50 | Agregar un comentario | Vnculo 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 sera crear una GPO en el directorio activo que se encargue de distribuir los certificados. Simplemente abrimos la herramienta de administracin 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: Configuracin de Usuario directivas Configuracin de Windows Configuracin de Seguridad Directivas de clave pblica Aqu hacemos clic sobre Cliente de Servicios de Certificate Server Inscripcin Automtica

Lo habilitamos y activamos las casillas de renovaciones automticas y actualizaciones de plantillas.

45

Aceptamos los cambios y solo resta probar. Creamos un usuario para probarlo e iniciaremos una sesin en alguna de las mquinas del dominio. 19:18 | Agregar un comentario | Vnculo permanente | Agregar al blog 25 marzo

46

Hola! hemos SubCA en Windows 2003. Esta CA no puede iniciar debido a este error. Despus 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 raz CRL, pasa. CRL de la CA raz 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

También podría gustarte