1. Las CA (Certification Authority) son los servidores que se encargan de emitir los certificados que luego se utilizarán como medios de identificación
2. La infraestructura de CAs de una organización se denomina PKI (Public Key Infrastructure)
3. Cuando se crea una CA, el software genera automáticamente un certificado raíz autofirmado

• Es el certificado más importante de una CA
• La clave privada de este certificado se utilizará para firmar cualquier otro certificado emitido por la CA

1. En una PKI puede haber varias CA organizadas jerárquicamente pero que dependan de una única CA raíz

Para que el sistema operativo confíe en un certificado se tiene que cumplir:

• Que el sistema confíe en la CA que emitió el certificado
• Que el nombre que figura en el certificado coincida con el nombre del sistema o la dirección de correo electrónico u otro parámetro en función del tipo de certificado
• Que el certificado no esté caducado ni haya sido revocado

CA pública

• Son PKI gestionadas por empresas privadas o gubernamentales que emiten certificados públicos
• Los certificados de estas CA suelen venir instalados de serie en los sistemas operativos
• Suelen tener un proceso de registro muy exhaustivo
• La emisión del certificado tiene un coste económico

CA privada o interna

• Es instalada por el administrador de sistemas para uso privado en su red
• Requiere que instalemos el certificado de la CA en todos los sistemas
• La emisión del certificado no tiene coste económico

En Windows Server 2008, una CA es un servidor con el rol “AD CS” instalado

Una CA puede emitir certificados, revocarlos, publicar la lista de certificados revocados (CRL) o la lista de información AIA (Authority Information Access) para que los certificados emitidos a usuarios, sistemas o servicios puedan ser validados

En las PKI de WS2K8 caben dos tipos de CA:

CA raíz: dispone de certificado autofirmado y puede emitir certificados para otra CA

CA subordinada: dispone de certificado firmado por otra CA raíz

Pueden estar o no integradas en el Directorio Activo

CA Stand-alone: no requiere Directorio Activo

CA Empresarial: se integra en un Directorio Activo y exige que el servidor forme parte de un Dominio de Directorio Activo

• La CA raíz de la PKI se implementa como stand-alone
• Las CAs subordinadas de la PKI son certificadas por la CA raíz, pero se recomienda que sean de tipo empresarial (integradas en el Directorio Activo)
• Una vez creadas las Enterprise-CAs subordinadas, se desconecta la CA raíz de la red o directamente se apaga el servidor

1. De este modo protegemos la clave privada de la CA raíz
2. La CA raíz sólo se encenderá cuando haya que certificar una nueva CA subordinada

Trabajaremos con dos servidores WS2K8 Enterprise Edition (tienen un rol de PKI más completo que la versión Standard)

La primera maquina se llamara SRV-RootCAseguido del numero de lista

Servidor stand-alone donde se instalará la CA raíz

El servidor está en un grupo de trabajo (GW-PKI)

La segunda maquina se llama DC1 en mi caso, en el vuestro las iniciales de vuestro nombre y apellidos

Controlador de dominio del dominio EMBOSA en vuestro caso ASIR

En él se instalará una CA subordinada e integrada en el Directorio Activo

También se usarán los servicios web de este servidor como rutas para publicar los AIA (Authority Information Access) y los RDP (Revocation List Distribution Point) de las dos CAs

Nota Una vez instalada una CA en un servidor, éste ya yo puede cambiar de nombre

comprobación inicial de nombres NetBIOS

Instalación de los servicios DS CA en SRV-RootCA

Instalación de los servicios web para la inscripción de certificados, lo que requerirá IIS

Comenzamos la configuración de la CA raiz (no está en dominio, sólo podemos elegir Independiente)

Elegimos CA raiz

Creamos una nueva clave privada

Definimos del CSP (Proveedor de Servicios de Cifrado) que utilizamos

Asignamos nombre a la CA raiz

Establece el periodo de validez del certificado de la CA raíz autofirmado

Definimos la ruta de la base de datos de certificados y del registro de emisión

Configuración por defecto propuesta de la instalación de IIS

Por seguridad, asegurar una copia de la clave privada de la CA raiz

Obtención del certificado público de la CA raíz para la distribución: accedemos http://localhost/certsrv

Descargamos el certificado de CA

• Debe instalarse en todos los sistemas que necesiten confiar en los certificados emitidos por la CA raíz y todas sus subordinadas
• En su instalación hay que incluirlo en el contenedor de Entidades de certificación raíz de confianza
• Puesto que finalmente se apagará la CA raíz habrá que publicar en algún servidor web las rutas de AIA (Authority Information Access) y CDP (o RDP o CRL, Certification-List Distribution Point)

Deben configurarse las rutas de publicación antes de emitir ningún certificado ya que la información se incluye en los certificados emitidos

• Se agregan rutas para CDP y para AIA que apunten al servidor en que se publicarán
• Ejemplo de ruta: http://dc1.embosa.com/certenroll/<Nombre DNS del Servidor>_<Nombre de CA><Nombre del Certificado>.crt

Hay que asegurarse de marcar las casillas inferiores de inclusión de certificados

Añadimos el resto de rutas

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

Nos qudarán las siguitentes publicaciones

Creación de una CA subordinada e integrada en el directorio activo

Configuramos el DNS para que los sistemas puedan encontrarse por su FQDN

Instalamos el rol de AD CS en el servidor sobre el que crearemos la CA subordinada

Como el servidor está en el dominio podemos elegir “Empresa” y subordinada

Generamos el certificados para esta nueva CA

Elegimos la criptografía y el nombre para la nueva CA

Solicitamos un certificado a la CA raíz

Generamos una solicitud de certificado que luego usaremos para que sea firmado por la CA raíz

Finalizamos el asistente

Nos conectamos a http://srv-rootca/certsrv y solicitamos el certificado para la CA subordinada con solicitud avanzada

Solicitamos el certificado desde el archivo con la petición que generamos anteriormente

Se copia el contenido del fichero en el bloc de notas y lo pegamos en la pagina

Se envia la solicitud

Entonces se genera la solicitud, que queda pendiente en la CA raíz para que podamos aprobarla manualmente

Seguidamente vamos a la CA raíz y aprobamos la solicitud de certificado de la CA subordinada

Para utilizar el certificado es necesario confiar en la CA raíz

Su certificado público debe estar en todos los sistemas que vayan a utilizar los certificados de ambas CA

Se pueden distribuir mediante directivas de grupo del dominio

Una vez importado, el directorio activo se encargará de distribuirlo a todos los sistemas del dominio

Descargamos el certificado de la CA subordinada y repetimos el proceso con el certificado que dejamos sin terminar y que está pendiente

Descargamos el certificado con la opción “Descargar cadena de Certificados”

Habilitamos la CA subordinada utilizando este certificado con la opción “Instalar el certificado de CA”

Ajuste de las rutas AIA y CPD de la CA subordinada

Instalación de un servidor OCSP (Online Certificate Status Protocol)

Los administradores de las CA pueden revocar los certificados

Se deben publicar CRL (Certificate Revocation List) con los certificados revocados Las CRL pueden ser:

• CRL completa (listados completos)
• CRL delta (listas diferenciales)

WS2K8 implementa el protocolo OCSP que sirve para consultar el estado de un certificado sin necesidad de descargar las listas CRL completas

• OCSP es un protocolo del tipo cliente-servidor
• En su funcionamiento se asemeja a un DNS, pero para certificados en vez de para direcciones IP

Habilitar el servicio OCSP

Habilitamos la ruta en donde se encontrará el servidor OCSP

51

El servicio OCSP se identifica con un certificado específico de OCSP

52

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”

53

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

54

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

55

Si no está instalado, hay que instalar el servicio OCSP desde el Server ManagerArrancamos la consola de Administrador del Servicio de Respuestas en Línea y agregamos una configuración de revocación

56

Asignamos un nombre descriptivo del servicio

57

El certificado para el OCSP nos lo emitirá la CA subordinada de empresa

58

Examinamos los certificados desde el Directorio Activo y permitimos que OCSP automáticamente use el certificado para firmar las respuestas enviadas a los clientes

59 60

El servidor OCSP

Un único servidor OCSP puede publicar múltiples CA de la misma o de distinta PKI ya que se trata de un servicio web El servidor OCSP se puede publicar en Internet si se desea que se pueda consultar desde el exterior

• En ese caso, conviene que sea un servicio protegido por un cortafuegos
• Es una configuración típica instalar el servidor OCSP en un DMZ

Publicación en OCSP de la CA raíz

Seleccionamos el certificado desde local ya que la CA raíz o está en el DA

61 62

Seleccionamos el certificado de la CA raíz y permitimos firmar con él las respuestas a los clientes

63 64

Para nuestra CA raíz no tendremos un proveedor de listas de revocación y eso lo solucionamos introduciéndolo manualmenteHacemos 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

65 66

Publicación de la CA raíz 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 mantiene 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 no hubiese contenido en el recurso compartido de la CA Raíz entonces tendremos que crear nuestra primera CRL

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

67

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 copiar el contenido desde el servidor CA Raíz hacia el servidor CA Subordinado

68

Agente de recuperación de claves KRA (Key Recovery Agent)

Tiene la capacidad de recuperar la clave privada de un certificado desde la base de datos de la CA que lo emitió

Puede solucionar problemas de pérdida o extravío de certificados

Debe asignarse a personas de muy alta confianza

Pasos previos para su implementación:

• Se crea un usuario especial “UsuarioKRA”
• Se crea un grupo global “AgentesKRA”
• Se integra al usuario UsuarioKRA en el grupo AgentesKRA

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